Intranet Projekt: Stolperfallen & Tricks für die Analysephase

Im Rahmen einer mehrteiligen Blog-Reihe möchte ich gerne auf die einzelnen Phasen eines Intranet Projektes eingehen. Dabei soll es in erster Linie um meine Erfahrungen in Form von Best Practices gehen. Letztlich handelt es sich bei der Einführung oder einem Relaunch eines Intranet um ein klassisches (IT)Projekt mit den Phasen

  • Analyse,
  • Konzeption,
  • Realisierung und
  • Roll-Out.

Dazu kommen allerdings noch die Phasen „Content & Migration“ und der Betrieb nach erfolgter Einführung des ersten Release. Also insgesamt sechs Phasen und damit auch eine sechsteilige Blog-Reihe.

Umso besser ein Projekt startet, desto erfolgreicher ist dessen Ergebnis

Ich habe im Laufe meiner Projekte bestimmte Fragestellungen, Vorgehensweisen und ähnliches gesammelt und dokumentiert. Diese dienen mir und meinem Team als eine Art Checkliste und den Kunden als gute erste Orientierung. Gerade am Anfang eines Projektes ist eine solche Orientierung sehr wichtig, da es hier i.d.R. noch kein gefestigtes Bild vom zukünftigen Intranet gibt. Jede Erfahrung (positiv und negativ) kann hier sehr hilfreich sein. Folgende Arbeitspakete schlage ich dabei in der Regel vor:

  • Projektdefinition und -planung
  • Inventarisierung der Anwendungs-/Systemlandschaft
  • Aufnahme der Anforderungen
  • Fokusbestimmung, Portal-Strategie
  • Priorisierung der Anforderungen
  • Strategie und Roadmap

Projektdefinition und -planung

Man kann sagen, dass dieses Arbeitspaket vor den eigentlichen Start des Projekts gehört, aber meistens steht zumindest der Entschluss bereits fest, dass ein solches Projekt gestartet werden sollte (muss). Leider auch die Vorstellungen über Budget und Projektende … aber das ist eine andere Geschichte.

Mein Ziel ist es, dass man sich für das Projekt (mindestens) auf folgende Punkte einigt und diese in Form einer Präsentation oder eines Dokuments festhält:

  • Was ist die Ausgangssituation? Warum muss ein Intranet eingeführt oder aktualisiert werden?
  • Was wird wahrscheinlich der Fokus (Informationen, Inhalte, Zusammenarbeit, Prozesse) des Intranets sein? Lassen sich bereits jetzt erste Ziele und eine Vision formulieren?
  • Gibt es bereits Vorgaben für eine technische Lösung oder muss diese erst noch ausgewählt werden?
  • Gibt es bereits andere Vorgaben? Zu nennen sind hier z.B. Umgang mit Mehrsprachigkeit, Organisation der Redaktion, etc.
  • Wie sollen die Anforderungen der Anwender erhoben werden? Möglich wären hier Workshops, Interviews und Fragebögen, welche auch entsprechend kombiniert werden können.
  • Wie werden die notwendigen (kulturellen) Änderungen im Unternehmen eingeschätzt? Ist hier bei der Einführung und Kommunikation ein entsprechendes Augenmerk notwendig?
  • Gibt es evtl. parallele/konkurrierende Lösungen, Plattformen und Projekte?
  • Wie soll die Projektorganisation sein? Soll mit Teilprojekten gearbeitet werden und stehen hierfür ausreichend Kapazitäten zur Verfügung?
  • Kann/sollte bereits jetzt eine Abgrenzung vorgenommen werden? D.h., was soll mit dem zukünftigen Intranet explizit nicht gemacht werden?
  • Kann das gesamte Projektvorgehen bereits skizziert werden?

Die Erfahrung zeigt, dass man hier mit ein paar Tagen Brainstorming und Diskussion der Projektleitung zu einem guten Ergebnis kommt. Dieses Ergebnis sollte dann so sein, dass dieses sowohl als Grundlage für ein Kick-Off dient, aber auch in Teilen für die Projektkommunikation genutzt werden kann.

Inventarisierung Anwendungs-/Systemlandschaft

Die Ist-Aufnahme der aktuellen Intranet-Systemlandschaft und möglicher Anwendungen inkl. einer ersten Bewertung, ist letztlich ein typisches Arbeitspaket der IT. Insbesondere bei komplexeren Portalen mit Anforderungen im Bereich „Single Point of Entry“, „Single Sign-On“ und „Anwendungs- und Prozessportal“ kann eine solche Inventarisierung sehr komplex und aufwendig werden. Diese bildet aber eine wichtige Grundlage für die Konzeption und bereitet die IT sehr gut auf die Aufgabenstellung vor.

Aufnahme der Anforderungen

Kernaufgabe der Analyse-Phase ist die Aufnahme der fachlichen Anforderungen an das zukünftige Intranet.

Hier gilt es als erstes zu bestimmen, welche Zielgruppen ich auf welche Art einbinde. Grob bieten sich bei der Methodik folgende Arten an, welche von sehr strukturiert bis sehr offen gehen:

  • Technisch (rein technische Analyse der bisherigen Kommunikation, z.B. Email-Aufkommen, Zugriff auf Inhalte des aktuellen Intranets, etc.)
  • Fragebogen (online/offline, evtl. anonym)
  • Interviews (fester Block mit Fragen, aber auch offene Diskussion)
  • Workshops (moderiert mit sehr offener Diskussion)

Die Auswahl der Methodik ist letztlich abhängig von:

  • Zeit (Vorfeld, Teilnehmer)
  • Vorhandenem Wissen (Anforderungen, Teilnehmer)
  • Grad der (notwendigen) Nachweisbarkeit
  • Vergleichbarkeit
  • Zugeständnis für Freiheitsgrade („Wünsch Dir was“)

Die genannten Methoden können natürlich auch kombiniert werden und erfolgen dabei oft in zeitlicher Abfolge.

Screen Shot 2015-04-24 at 13.32.26

Bei den Zielgruppen, geht es nun um die Frage „Wer soll befragt werden?“. Typische Zielgruppen sind hier z.B.:

  • Fokusgruppen
  • Fachabteilungen
  • Kernteam
  • Repräsentative Vertreter
  • Typische Empfänger/Sender
  • etc.

Bei einer kombinierten Methodik werden oft unterschiedliche Zielgruppen mit unterschiedlichen Methoden angesprochen. Beispiel: Repräsentative Vertreter mit Interviews und Fachabteilungen mittels Workshops.

Priorisierung der Anforderungen, Fokus-Bestimmung, Portal-Strategie

Aus den Ergebnissen der Anforderungsaufnahme muss letztlich eine Portal-Strategie entwickelt werden. Ziel ist die Bestimmung und Festlegung der kurz- bis langfristigen Strategie des „Neuen Portals“ und Scoping des Projektumfangs und evtl. nachfolgender Ausbaustufen. Wesentliche Grundlage ist hier die Priorisierung der in Workshops und Gesprächen aufgenommenen Anforderungen und ggf. Aufteilung in verschiedene Phasen. Je strukturierter die gewählte Methodik, desto einfacher kann hier eine i.d.R. notwendige Priorisierung erfolgen.

Digital Workplace Haus

Ich arbeite hier gerne mit einer Gewichtung nach „Portal Clustern“ und als Darstellung kann hier sehr gut das Namic Digital Workplace Haus mit seinen Säulen dienen:

  1. Communication & News (klassisches Intranet)
  2. Managed Content (strukturierte Informationen, wie Reports),
  3. Self-Services / Processes (Workflows, Anwendungen, Single Sign-On, etc.),
  4. Structured Collaboration (Wiki, etc.)
  5. Social Collaboration (Chat, etc.)
  6. Unified Communication (Zusammenführungen mit anderen Kommunikationskanälen)

Anforderungen, verdichtet in Use Cases (Anwendungsfällen), lassen sich hier i.d.R. den jeweiligen Clustern zuordnen und man kann so eine erste Gewichtung vornehmen. Dieses kann dann argumentativ zur Formulierung einer Strategie und Roadmap verwendet werden.

Fazit

Der nächste Teil der Blog-Reihe soll dann zeigen, wie man die Anforderungen der Analyse nun weiter konkretisieren und greifbarer werden lassen kann.

Dieser Beitrag wurde unter Digital Workplace, Intranet & DWP Projekte abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Über Thomas Renken

Schwerpunkte seiner branchenübergreifenden Beratungstätigkeit liegen bei der digitalen Unterstützung der internen Zusammenarbeit, Prozesse und Kommunikation. Thomas Renken ist seit mehreren Jahren in diesem Umfeld tätig und besitzt durch seine langjährige Projekterfahrung einen praxisorientierten Überblick über die Lösungsansätze und Technologien. Bei Namics berät er Unternehmen insbesondere zum zielgerichteten und sinnvollen Einsatz von Digital Workplaces im weiten Sinne (Intranet, Extranet, Wikis, Social Intranets, etc.).

Ein Gedanke zu “Intranet Projekt: Stolperfallen & Tricks für die Analysephase

  1. Pingback: Intranet Projekt: Intranet-Realisierung – Wie erkläre ich es den Entwicklern? – 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>