Montag, 9. Mai 2016

Redaktions- und Content Management-Systeme erfolgreich einführen - Interview mit Christian Kohl

Projekte zur Einführung vom Redaktions- und Content Management-Systemen starten mit großen Hoffnungen und vielen Erwartungen. Doch oft kommt das berühmte "Tal der Tränen", wenn die versprochenen Effizienzgewinne ausbleiben oder crossmediale Möglichkeiten doch nicht "auf Knopfdruck" funktionieren. Was ist dann schief gelaufen? Und wie können solche Projektkrisen vermieden werden? Christian Kohl, Berater, Projektmanager und Referent auf dem nächsten CrossMediaForum, gibt im folgenden Interview Antworten auf diese Fragen. Sein Fazit: "Bei Projektstart muss klar definiert sein, was die Ziele sind, welche Geschäftsmodelle damit zum Erfolg geführt werden sollen und dass es ein gemeinsames Verständnis dieser Zielsetzung im Management und in den beteiligten Abteilungen geben muss."

Projekte zur Einführung von Content Management- und Redaktionssystemen starten oft mit sehr gegensätzlichen Erwartungen: Die einen erwarten Wunder, andere lehnen Veränderungen ab. Wie kann ich als Projektverantwortlicher hier einen für alle akzeptablen Kurs steuern?
Christian Kohl: Es müssen zuerst die Ziele und Erwartungen der verschiedenen Stakeholder über alle Hierarchieebenen hinweg erfasst werden und anschließend die Zielkonflikte identifiziert werden. Erst wenn dieses Bild gezeichnet ist, kann der Kurs definiert werden. Leider ist es nicht ungewöhnlich, dass es unauflösbare Zielkonflikte gibt, in diesen Fällen muss zunächst Einigkeit auf der Geschäftsleitungsebene erzielt werden und diese Vorgabe muss dann auch „von oben“ kommuniziert werden. Im weiteren Projektverlauf gilt es dann darauf zu achten, dass sich die diversen Personen auf der Entscheider-Ebene nicht wieder auseinanderdividieren lassen. Die Ziele und Erwartungen aller Beteiligten sollten zudem transparent gemacht werden – Loyalität und Akzeptanz schafft man meiner Erfahrung nach mit Ehrlichkeit und Transparenz, „secret agendas“ bleiben nicht lange geheim und bewirken genau das Gegenteil. Genau so sollte stets klar kommuniziert werden, was nicht möglich ist und auch nicht umgesetzt werden wird, um keine falschen Hoffnungen zu wecken. Dies immer mit Bezug zu den ausgegebenen und gemeinsam verabschiedeten Zielen, damit klar ist, warum etwas nicht oder anders umgesetzt wird. Weiterhin gilt es unrealistische und überzogene Erwartungen klar als solche zu benennen, den Entscheidern dies zu erklären und Alternativen zu präsentieren. Das ist manchmal für externe Beteiligte leichter als für Mitarbeiter.
Wird im Verlag bereits ein CMS oder Redaktionssystem (oder sogar mehrere) eingesetzt, kommt eine zusätzliche Dimension hinzu, der „alt vs neu“ Vergleich. Der spielt sich idR auf zwei Ebenen ab: Zum einen bei den Usern hinsichtlich Benutzerfreundlichkeit, Bequemlichkeit, Effizienz und zum anderen auf der Entscheiderebene, meist mit Fokus auf Kosten und Prozesslaufzeiten. Auch hier muss stets die Rückbesinnung auf die Projektziele erfolgen – ein Nachbau eines Altsystems wird selten erfolgreich sein. Hier gilt es vielmehr zu überzeugen, welche Vorteile dem Unternehmen durch Veränderungen in Prozessen und Arbeitsweisen entstehen, teilweise gilt es auch Ängste vor neuen, unbekannten Technologien abzubauen. Ein Testsystem/Prototyp oder Gespräche mit anderen Nutzern, die das System bereits einsetzen, kann helfen, diese Barrieren zu überwinden oder zumindest ein besseres Verständnis zu schaffen.
Viele Projekte haben Probleme, weil sich Verlage nicht gut genug auf eine Systemauswahl und –implentierung vorbereiten – von unklaren Geschäftsmodellvorstellungen bis zu nicht detailliert genug aufgenommenen Nutzeranforderungen.  Wie viel Vorbereitung ist notwendig, um sich gut vorzubereiten?
Christian Kohl: Leider ist bei dieser Art von Projekten viel Vorbereitung nötig. Es geht hier idR um abteilungsübergreifende Arbeitsprozesse, die sich fast durch das ganze Unternehmen ziehen. Änderungen an einer Stelle haben oft (unerwartete) Auswirkungen an anderen Stellen, Prozessveränderungen können interne Machtgefüge durcheinanderbringen. Was auf jeden Fall so gut wie irgendwie möglich definiert und modelliert sein muss sind die Geschäftsmodelle und die Arbeitsprozesse. Wichtig ist hier die Reihenfolge: Ein Geschäftsprozess ist kein Selbstzweck, er existiert, um das Geschäftsmodell möglichst effizient und effektiv umsetzen zu können, er folgt also gewissermaßen aus dem Geschäftsmodell. Und alle Anforderungen sollten demnach auch aus dem Geschäftsmodell und weiteren Projektzielen abgeleitet werden. Man kann das ein wenig mit einem Fundament beim Hausbau vergleichen: Ist das Fundament nicht sauber erbaut, nützt mir eine Luxusküche recht wenig, wenn das Gebäude leider absackt oder der Strom ständig ausfällt. Neben der Definition der Geschäftsmodelle und der Ableitung der benötigten/gewünschten Arbeitsprozesse macht in vielen Situationen auch eine Konkurrenzanalyse oder Benchmarking Sinn – man muss nicht immer das Rad neu erfinden und kann ggf. best practices von anderen Verlagen übernehmen. Das sind gewissermaßen die Hausaufgaben, auf die dann die eigentliche Anforderungsanalyse aufsetzt.
Das klassische Instrument zur Formulierung von Anforderungen ist das Pflichtenheft. In seinem Anspruch auf Vollständigkeit und seiner Starrheit scheint es jedoch für dynamische Geschäftsmodelle kein passendes Instrument mehr zu sein. Eine agile Vorgehensweise bietet jedoch keinen sicheren Projektrahmen. Wie kann ich dieses Dilemma lösen?
Christian Kohl: In dem man ganz ehrlich die Vollkosten vergangener „Pflichtenheft“-Projekte betrachtet. Auch bei sehr wohldefinierten „Festpreis“-Projekten gibt es idR nachträgliche Anpassungen. Eben weil die Prozesse sich ändern, die Geschäftsmodelle, Inhaltsstrukturen usw. im Fluss sind. Insofern ist auch in diesen Szenarien ein Festpreis selten ein echter Festpreis, sondern es gibt „nachträgliche Anpassungen“, „kundenindividuelle Verfahren“ o.s.ä., die nach Projektabschluss dann umgesetzt werden. Es ist in den seltensten Fällen sinnvoll und praktikabel, den kompletten Funktionsumfang a priori vollständig und detailliert zu definieren – genau das ist aber die einzig sinnvolle Grundlage für ein ehrliches Festpreisangebot.
Umgekehrt muss eine agile Vorgehensweise nicht komplett in der Luft schweben. Hier lassen sich beispielsweise Mischformen finden, in denen die Basisfunktionen über einen Festpreis abgedeckt werden und nur kundenindividuelle Anforderungen nach Aufwand anfallen. Zudem bedeutet „agile Vorgehensweise“ ja auch nicht „unbegrenztes Budget“, es gibt Modelle mit Ober- und Untergrenzen, mit denen sich die Risiken für Auftraggeber und Auftragnehmer kapseln lassen.  Das reduziert die Unsicherheit ein wenig. Zudem sollte eine sauber umgesetzte agile Methodik das Projekt so steuern, dass mit dem vorhandenen Budget zuerst die wertvollsten / wertschöpfendsten Funktionen umgesetzt werden. Aber dies erfordert einerseits Vertrauen in den Dienstleister, andererseits Bereitschaft im eigenen Haus, entsprechend agil zu arbeiten, d.h. schnelle Entscheidungen ohne lange Gremiumsdiskussionen. Das kann und will nicht jeder.
Insofern bleibt es jedem Unternehmen selbst überlassen, an welcher Stelle sie das Risiko tragen möchten. Klar sollte aber sein, dass es keine Systemeinführung oder –migration ohne Risiken gibt. Und Modelle, in denen sämtliche Risiken einseitig einem Dienstleister aufgebürdet werden, der dann noch preislich „an die Wand verhandelt“ wird, sind nicht nachhaltig. Das ist ein Trugschluss, man mag sich anfangs über den niedrigen Preis freuen, im weiteren Projektverlauf oder Regelbetrieb verfliegt diese Freude allerdings häufig recht schnell.
Woran erkenne ich, dass ein CMS-Projekt in die falsche Richtung läuft und zentrale Anforderungen nicht oder nur unzureichend umgesetzt werden können? Was sind Frühindikatoren?
Christian Kohl: Ein Frühindikator vor Umsetzungsbeginn ist, wenn in der Spezifikationsphase nur schwer oder gar kein Konsens über Standardisierungen erzielt werden kann und immer wieder „Sonderlocken“ gefordert werden. Oder wenn Aussagen und Handlungen der Entscheider nicht kongruent sind. Wird beispielsweise als oberstes Ziel „Kostensenkung“ ausgegeben, dann aber ständig gegen Standardisierung und für Individualisierung entschieden, dann sollten die Alarmglocken schrillen.
Während der Umsetzung ist ein Warnzeichen, wenn die absoluten Basics wie bspw. Inhalte erstellen oder bearbeiten, einfache Workflows einrichten, Standardformate exportieren, Nutzer anlegen, Berechtigungen zuweisen nach den ersten Sprints / Iterationszyklen nicht funktionieren. Das zeugt entweder von falscher Priorisierung in den Sprints/Releases, von technischen Mängeln im Produkt oder von beidem zusammen. Es ist verlockend zu sagen: „Wir kümmern uns um Sonderfunktion X, die ist spannend und macht Stakeholder Y glücklich. Um die Basics müssen sie sich keine Sorgen machen, das konfigurieren wir dann flott in den letzten zwei Wochen.“ Und dann entdeckt man die Abhängigkeiten und Lücken … . Grundsätzlich sollte immer gelten, dass am Ende eines Sprints/Releases ein benutzbares System steht, dass dann Stück für Stück mit Zusatzfunktionen angereichert wird. Ein weiterer Grundsatz ist „do the hard stuff first“: komplizierte Features gehören in frühen Sprints umgesetzt, sofern sie wichtig genug sind. Werden solche Funktionalitäten ständig aufgeschoben, kann dies ebenfalls ein Warnzeichen sein (muss aber nicht).

Ein weiterer Indikator ist die Zeit, die für wertschöpfende Funktionen oder Prozesse aufgewendet wird vs die Zeit, die für Marginalien, obskure Details und selten gebrauchte Sonderfunktionen verwendet wird. Wenn der Zeitaufwand für letzteres überwiegt, sollten die Alarmglocken läuten (es sei denn, der Rest funktioniert schon einwandfrei und es ist noch Budget übrig … ).
Schließlich noch ein vierter Punkt, der nicht für alle Projekte zutrifft. Handelt es sich um eine Migration und wird erwartet, dass das Altsystem mehr oder weniger 1:1 abgebildet wird, ist das ebenfalls ein Warnsignal. Denn die beste Version des Altsystems ist das Altsystem selbst, ein anderes System wird unweigerlich in veschiedenen Aspekten anders, besser und schlechter sein, aber niemals 1:1 dem Altsystem entsprechen.
Wie manage ich eine solche Projektkrise am besten?
Hier gibt es etliche Ansatzpunkte, je nachdem, wie weit der Prozess fortgeschritten ist. Es gibt gewisse Faustregeln. Zuerst einmal die Vorbedingungen überprüfen: Sind Stakeholder, Rollen, Personas, Geschäftsmodelle, Ziele, Arbeitsprozesse klar definiert, die Definitionen akzeptiert und transparent kommuniziert? Wenn nein, dann wäre dies der allererste Schritt. Haben sich vielleicht Ziele oder Geschäftsmodelle verändert – dann müssen die Auswirkungen dieser Veränderungen auf Anforderungen und damit ggf. auf Budget und Zeitplan ermittelt werden. Während des Umsetzungsprojekts ist es meiner Ansicht nach unabdingbar, dass der Auftraggeber ausreichend Ressourcen vorhält, um aktiv das Projekt kontrollieren und steuern zu können. Das bedeutet vor allem, ständig zusammen mit dem Dienstleister (oder den internen Entwicklern) die Iterationen zu planen, Prioritäten festzulegen, Entscheidungen zu treffen.
Steckt die Entwicklung in einer Sackgasse, weil ein Featurewunsch nicht lösbar ist, hilft es häufig, einen Schritt zurück zu treten und sich an den Zielen zu orientieren. Häufig muss es gar nicht das Feature an sich sein, sondern das Ziel kann auch auf andere Art und Weise erreicht werden. Auch Methoden aus dem agilen Baukasten helfen, in dem komplexe Themen bspw. durch User Stories „atomisiert“ und damit besser greifbar gemacht werden.
Vor allem aber sollte jede Anforderung, jedes Epic, jede User Story darauf überprüft werden, welchen Wert sie schafft, wie sie zum Erreichen der Ziele, zum Erfolg des Geschäftsmodells beiträgt. Und dann muss daran ausgerichtet priorisiert werden.

Dein Vortrag auf dem nächsten CrossMediaForum lautet: „Unklarheiten überall, oder: Warum CMS-Projekte ihre Ziele verfehlen (und wie Sie das verhindern können)“. Was wird die zentrale Botschaft sein?
Christian Kohl: Die zentrale Botschaft wird sein, dass vor Projektstart klar definiert sein muss, was die Ziele sind, welche Geschäftsmodelle damit zum Erfolg geführt werden sollen und dass es ein gemeinsames Verständnis dieser Zielsetzung im Management und in den beteiligten Abteilungen geben muss. Dass im weiteren Verlauf ein „Product Owner“ o.ä. anhand und im Rahmen dieser Vorgaben und Ziele eigenständig und schnell Entscheidungen treffen und Priorisierungen vornehmen können sollte. Und schließlich: Dass es keine Wunder gibt. Billig, maximum flexibel und super individuell auf die eigenen Bedürfnisse angepasst, das ist eine Utopie. Die bittere Pille, die es zu schlucken gilt: Wenn ich nicht bereit bin, zu standardisieren, dann wird es wahrscheinlich etwas teurer … . Und wenn Standardisierung nur ein Lippenbekenntnis ist, dann rächt sich das im Projektverlauf bitter, weil das Fundament nicht stimmt.

Keine Kommentare: