Intranet Projekt: Intranet-Realisierung – Wie erkläre ich es den Entwicklern?

Im Rahmen unserer Blog-Reihe zu Best Practices typischer Intranet Projekte und deren Phasen, konnten wir uns bereits der Analyse und der Konzeption widmen. Im Grunde sollten jetzt alle Anforderungen klar sein, so dass diese „nur noch“ umgesetzt werden müssen. Alles sauber festgehalten in einem „IT Blueprint“, welches man dann einfach der IT, den Entwicklern und Administratoren übergibt. Leider ist dieses i.d.R. nicht ganz so perfekt und es reicht erfahrungsgemäß auch nicht aus. Und es gibt zudem noch viele Aufgaben während dieser Phase zu tun, welche überhaupt nicht technisch sind.

Intranet Projekt Phasen

Den Elefanten in Scheiben schneiden

Schon allein die Laufzeit eines solchen Projektes macht es notwendig, dass man frühzeitig erste Ergebnisse bereitstellt und sich dadurch Feedback von den Anwendern abholt. Wurde bereits in der Konzeption mit Wireframes und Prototypen gearbeitet, sollte man dieses möglichst fortführen und hier sehr schnell eine erste Lösung präsentieren. Ich arbeite hier gerne mit Releases, d.h. mit klar benannten Vorabversionen, welche einen bestimmten Funktionsumfang und Zweck haben. Typische Releases sind:

  • Release 0.1 – Prototyp zur Präsentation und Kommunikation
  • Release 0.5 – Schulungsrelease, welches alle Basiskomponenten bereitstellt um frühzeitig Schulungen durchführen zu können
  • Release 0.8 – Integrations- und Migrationsrelease, mit dem zum ersten Mal das Zusammenspiel aller technischen Komponenten geprüft und gezeigt werden kann. Weiter kann eine solche Version für eine Migration genutzt werden.
  • Release 1.0 – Release für Going-Live, wobei dieses ggf. nur für erste Wellen (Länder, Standorte, o.ä.) genutzt wird
  • Release 1.1 – Release „mit Feinschliff“ und ggf. kleineren Änderungen für einen vollständigen Rollout (alle Länder, Standorte, Sprachen, o.ä.).

Man kann sich hier natürlich noch weitere Versionen, wie z.B. für den Piloten einer Teilfunktion vorstellen. Hier ist aber zu bedenken, dass jedes Teilrelease zu zusätzlichen Aufwenden für die Bereitstellung, die Tests und die Betreuung führt. Weniger ist hier oftmals mehr und man sollte ein Release auch wirklich verwenden, so dass der Aufwand gerechtfertigt ist. Ungenutzte, unnütze Releases führen auch mal zu Frust bei den Entwicklern.

Wie sage ich es meinen Entwicklern?

Sagen wir mal, wir haben einen „IT Blueprint“ mit Skizzen der Anforderungen, welche mal konkret und mal weniger konkret sind. Ein wenig Unschärfe ist hier gar nicht so schlimm, wenn dieses bei der anschließenden Kommunikation berücksichtigt wird. Die Kommunikation sollte möglichst eng und in hoher Frequenz sein. Das bedeutet, mit den Entwicklern für Layout, Templates, Workflows, Funktionen etc. sollte man wirklich regelmäßig Rücksprache halten und immer wieder die jeweilige Vorstellung einer Anforderung abgleichen. Und dran denken: jeder Entwickler ist anders. Der eine entwickelt lieber goldene Wasserhähne und der andere nur genau das, was ihm schriftlich vorgegeben wurde.

Bei der Kommunikation helfen natürlich Instrumente wie ein Wiki zur Kommunikation oder ein System wie Jira zum Bündeln und Steuern der Einzelaufgaben. Wesentlich ist aber die direkte „face to face“ Kommunikation. Ich arbeite hier gerne mit Projektbüros, d.h. dem Zusammensetzen aller Beteiligten eines Projektes für einen bestimmten Zeitraum. Allein der Umstand, dass alle in einem Raum arbeiten (also keinen Workshop oder ein Meeting haben), bringt enorm viel für die Kommunikation und ein gemeinsames Verständnis für das Projekt.

Vorbereitung der „Content & Migration“ Phase

Laut unserer Releaseplanung kann bereits mit der Version 0.5 geschult werden. Dadurch lässt sich die Phase „Content & Migration“ früher und parallel zur Realisierung durchführen. Weiter fließen Feedback und evtl. Change Requests noch direkt in die Entwicklung ein und können hier ggf. noch berücksichtigt werden. Die Schulungen sollten auf jeden Fall sehr früh konzipiert und konkret geplant werden. Sollen Präsenzschulungen durchgeführt werden, sind Termine, Räumlichkeiten, Teilnehmer, etc. zu organisieren, was man nicht unterschätzen sollte. Gerade die Redakteure sind später entscheidend für das neue Intranet und der erste Eindruck zählt für eine perfekte Akzeptanz.

Neben der Schulung gibt es fachlich noch weitere Punkte abzustimmen und aus der Konzeption abzuschließen. Ein Punkt, welcher gerne länger dauert ist die z.B. die Navigationsstruktur, bei der man in der Konzeption oft nur bis Ebene 2 gekommen ist. Hierfür kann aber auch wieder ein allererstes Release 0.1 genutzt werden, welches die Navigation transparent macht und viel besser als eine Excel Tabelle wirkt.

Mit Puzzeln zum perfekten Template Katalog

Möchte man bereits sehr früh mit einzelnen Fachbereichen über deren Inhalte sprechen und auch ein Verständnis für die Templates schaffen, bietet sich ein Papier-Prototyp an. Ein Kunde ist hier so vorgegangen, dass er die Wireframes der einzelnen Templates mehrfach ausgedruckt und dann einzeln laminiert hat. Es entstand daraus eine Art Puzzle, welches in Workshops mit den zukünftigen Redakteuren Anwendung fand. Man konnte hiermit sehr einfach und spielerisch z.B. eine Abteilungsseite bauen und evtl. noch notwendige Templates identifizieren.

Zusammenfassend kann ich sagen, dass auch die Realisierungsphase eines Intranets zentral durch eine gute Kommunikation geprägt sein sollte. Kommunikation im Projekt, aber auch zu den zukünftigen Anwendern. Hier gibt es Instrumente, welche man nutzen sollte und nicht den Fehler machen auf das Endergebnis der Entwicklung zu warten. Das gilt für jedes IT Projekt und man sollte es auch bei einem Intranet Vorhaben beherzigen.

Fazit

Im nächsten Teil der Reihe dreht es sich dann um Motivation meiner Intranet-Redakteure im Rahmen Phase der „Content & Migration“. Gar nicht technisch und auch wieder jede Menge Kommunikation.

Ein Gedanke zu “Intranet Projekt: Intranet-Realisierung – Wie erkläre ich es den Entwicklern?

  1. Pingback: Intranet Projekt: Auf, auf, Ihr Intranet-Redakteure! – Intranet

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>