IT-Projekte richtig planen.
Anforderungen an IT-Systeme definieren

IT-ManagementIT-ProjekteKarriereNetzwerk-ManagementNetzwerke

Wenn IT-Projekte nicht wie gewünscht laufen, wurden oft Fehler bei der Spezifikation gemacht. Denn beim Definieren der Anforderungen an ein neues IT-System wird auch die Basis für eine erfolgreiche Kooperation zwischen den Fachbereichen und der IT gelegt.

Selten Begeisterung für It-Projeke

Haben Sie schon einmal ein IT-Projekt erlebt, von dem alle Beteiligten in Nachhinein begeistert waren? In der betrieblichen Praxis begegnet man  solchen Projekten selten. Viel häufiger vernimmt man, wenn die Beteiligten ein Projekt vor ihrem geistigen Auge Revue passieren lassen, Klagen wie »Die Kommunikation zwischen Fachbereich und IT war schlecht.« Oder: »Die Ziele waren stets unklar.« Oder: »Wir erhielten vom Top-Management nie die nötige Unterstützung.« Oder: »Irgendwie stimmte die Chemie nicht.«

Die Beteiligten beklagen also, dass in dem Projekt der Wurm steckte.Vom  Anfang an »flutschte« es nicht richtig. Immer wieder kam es zu Irritationen  und Reibereien – aus den unterschiedlichsten Gründen. Und dies schlug sich auch in den Projektergebnissen nieder.

Analysiert man die Ursachen, zeigt sich meist: Die Weichen für den unbefriedigenden Projektverlauf wurden bereits bei der IT-Spezifikation gestellt – also beim gemeinsamen Versuch von Fachbereich und IT, sich darauf zu verständigen,

–    was das neue System können soll und
–    wie es konzipiert sein sollte, damit es einerseits die Anforderungen der künftigen Nutzer erfüllt und andererseits bezahlbar bleibt.

Wie dieser (Kommunikations-)Prozess gestaltet wird, bestimmt oft den  Verlauf und somit auch Erfolg eines Projekts. Hiervon hängt ab, –    wie vertrauensvoll und kooperativ Fachbereich und IT in dem Projekt zusammenarbeiten und wie flexibel sowie verständnisvoll sie auf (Änderungs-)Wünsche der jeweils anderen Seite reagieren.


Die künftige Arbeit gedanklich vorweg nehmen

Um diesen (Kommunikations-)Prozess erfolgreich zu gestalten, ist es wichtig, sich bewusst zu machen, vor welchen speziellen Herausforderungen dieBeteiligten bei der IT-Spezifikation stehen. Denn diese sind immer wieder die Ursache von Konflikten.

IT-Spezifikationen beschäftigen sich zumeist mit einem (zunächst) abstrakten, wenig greifbaren Gegenstand. Das heißt, in ihnen werden Problemlösungen skizziert, die im Betrieb noch nicht existieren und die gedanklich oft künftige Arbeitsprozesse vorwegnehmen. Entsprechend schwer ist es, eine Einigung über die Anforderungen an das künftige System (nicht nur zwischen Fachbereich und IT) zu erzielen. Und selbst wenn diese scheinbar existiert, ist noch nicht garantiert, dass das gelieferte IT-System den Vorstellungen der Fachabteilung entspricht (»So haben wir uns das nicht vorgestellt.«).

IT-Spezifikationen bilden in der Regel die subjektive Wahrnehmung der direkt beteiligten Personen ab. Das heißt, sie lassen sich beim Definieren der Anforderungen an das neue System weitgehend von ihren Einschätzungen leiten, was aufgrund ihrer Erfahrung zum Beispiel betriebswirtschaftlich sinnvoll ist. Diese persönlichen Einschätzungen decken sich meist nur teilweise. Deshalb gibt es bei fast jedem Projekt direkt oder indirekt Betroffene, die ihre Erfahrungen und Bedürfnisse in der IT-Spezifikation nicht  ausreichend berücksichtigt sehen. (»Bei uns läuft das anders.«).

Entsprechend schwierig ist es oft, sich projekt- sowie firmenintern auf eineIT-Spezifikation zu verständigen, zumal meist auch die Interessen von Fachbereich und IT divergieren. So erhofft sich der Fachbereich von dem IT-System in der Regel eine bestmögliche Unterstützung der Abläufe und ihrer Varianten. Die IT hingegen favorisiert eine möglichst standardisierte Unterstützung ohne allzu viele Varianten, damit das IT-System nicht zukomplex wird und der Programmieraufwand überschaubar bleibt (»Ihr wollt uns doch nur eure Standardsoftware unterjubeln.«, »Mit euren Sonderwünschen sprengt ihr das Projektbudget.«). Die IT ist zudem daran interessiert, möglichst früh zu einer stabilen IT-Spezifikation zu kommen (»Legt euch doch endlich fest.«). Der Fachbereich hingegen möchte neue Erkenntnisse auch noch im Projektverlauf in das IT-System einbringen (»Wir wissen jetzt noch nicht, wie unsere Prozesse in zwei Jahren aussehen.«).


Reflektieren, was nötig und realisierbar ist

Auch an anderen Punkten sind die Interessen von Fachbereich und IT im Projektalltag häufig verschieden. So sind die Projektmitarbeiter beim Erstellen und Umsetzen der IT-Spezifikation zum Beispiel meist auf die Expertise der Spezialisten aus den Fachbereichen angewiesen. Deren Einbindung in das Projekt darf aber nicht so weit gehen, dass ihr Wissen im operativen Geschäft fehlt und die Fachbereiche handlungsunfähig werden.

Mit den genannten Grundkonflikten kämpfen Fachabteilung und IT beim Erstellen von IT-Spezifikationen immer wieder. Deshalb sollte dieser Prozess nicht mechanisch, sondern dynamisch und interaktiv gestaltet werden. Die Praxis zeigt: Hervorragende Methodenkenntnisse reichen für die IT-Spezifikation nicht aus. Im Gegenteil: Konzentriert man sich zu sehr auf die Methoden statt auf den Prozess, entsteht meist eine Spezifikation, die haarscharf an den eigentlichen Bedürfnissen der Fachseite vorbeigeht.

Fördern Sie deshalb einen regelmäßigen Informationsaustausch zwischen Fachabteilung und IT (zum Beispiel in Form von Workshops, in denen die Arbeitsprozesse gemeinsam visualisiert werden), damit ein wechselseitiges Verständnis entsteht. Sonst besteht die Gefahr, dass die IT nur ahnt, was der Fachbereich zu einem erfolgreichen Arbeit braucht, und der Fachbereich nicht versteht, wo seine Wunschvorstellungen an (informations-)technische Grenzen stoßen.

Die unterschiedlichen Sichtweisen sowie Erwartungen früh zu erkennen und zur Sprache zu bringen, ist eine Grundvoraussetzung für eine saubere Auftragsklärung. Denn nur wenn ein wechselseitiges Verständnis besteht, gelingt es, sich im Dialog darüber zu verständigen: Welche Features sind (aus fachlicher Sicht) unverzichtbar und worauf können wir nach einer gemeinsamen Kosten-Nutzen-Abwägung gegebenenfalls verzichten?


Der Autor

Zum Autor: Jürgen Rohr ist Inhaber der Projektmanagement-Beratung Vedanova, Wiesbaden. Er ist Co-Autor des Buchs »Prozessorientiertes Projektmanagement«, das im Hanser Verlag erschienen ist.