Zwar definiert die strategische Informationsplanung die fachlichen Anforderungen, nicht aber die geforderte Qualität, das beanspruchte Budget und die Bedingungen für die

Durchführung. Diese Informationen müssen vielmehr durch eine ergänzende Anforderungsanalyse ermittelt werden.

Von der strategischen Informationsplanung erhalten wir Anwendungssysteme und Prioritäten für die weitere Verfeinerung der Systeme. Die anwendungsbezogene Detaillierung läuft in eigenständigen Projekten ab. Für jedes Projekt liefert die strategische Informationsplanung als Input einen relevanten Ausschnitt aus dem Unternehmensmodell, der folgende Ergebnisse beinhaltet:

- die Unternehmensziele

- die Projektabgrenzung durch Ausweis der Kommunikation des Systems mit seiner Umgebung,

- ein grobes Funktionsmodell,

- ein grobes Informationsmodell und

- die Kommunikationsstruktur.

Die vorliegenden Ergebnisse aus der strategischen Informationsplanung decken einen großen und wichtigen Teil der gesamten Projektanforderungen ab. Das Projekt ist fachlich und inhaltlich von anderen Anwendungssystemen abgehoben. Besonders hervorzuheben ist, daß durch den integrierten Ansatz auch die Anwendungssysteme übersichtlich gegeneinander abgegrenzt und einheitlich beschrieben sind.

Neben den fachlichen Anforderungen müssen zu jedem Projektbeginn aber noch weitere Rahmenbedingungen analysiert und festgelegt werden. Zusätzliche Überlegungen sollten angestellt werden hinsichtlich der Qualitäts-, Durchführungs- und Budget-Anforderungen.

Alle diese Projektanforderungen werden im Pflichtenheft festgehalten und sind zu Beginn eines Projekts aufzunehmen. Der Aufwand für die Durchführung der Anforderungsanalyse - auch Requirement-Engineering genannt - reduziert sich erheblich, sofern im Unternehmen die Ergebnisse einer strategischen Informationsplanung bereits vorliegen. Je nach Bedeutung und Projektgröße wird der Planungsaufwand zur Bestimmung der Anforderungen größer oder kleiner ausfallen.

Wichtig für ein Projekt sind die Qualitätsanforderungen. Allgemein verstehen wir darunter die Anforderung, wie gut ein Produkt sein soll. Die Qualitätsanforderungen werden durch einen Zielbaum und den Anforderungskatalog beschrieben.

Ziele dienen als Orientierungshilfe für alle Projektmitarbeiter und den Auftraggeber. Eine Zielformulierung ist zweckmäßig, wenn es gelingt, dem Projektmitarbeiter die Absichten des Vorhabens mitzuteilen. Ein eindeutig beschriebenes Ziel ist eines, mit dem der Auftraggeber seine Absichten erfolgreich mitteilt.

Die formulierten Ziele oder Absichen des Auftraggebers sollten während der gesamten Projektdauer von jedem Mitarbeiter im Auge behalten werden. Wenn dies die wichtigste Anforderung an ein Zielsystem ist, so kann und soll ein Zielsystem nicht bis ins letzte Detail ausgearbeitet werden, zumal der Auftraggeber an der weiteren Detaillierung des Zielsystems nicht mehr beteiligt ist. Wir plädieren deshalb für einen Zielbaum, der nicht mehr als drei oder vier Stufen in der horizontalen wie auch in der vertikalen Ebene aufweist.

Anforderungen, also Produkt und Systemeigenschaften, dienen hingegen dem einzelnen Projektmitarbeiter als Muß- oder Kann-Vorgaben, die er für eine Teilaufgabe zu erfüllen hat. Die Summe dieser Vorgaben ergeben einen Anforderungskatalog. Der Anforderungskatalog sollte nur das externe Verhalten des Systems spezifizieren. Auch hier gilt der Grundsatz, überschaubar zu bleiben und sich nicht in Details zu verlieren. Dabei ist besonders auf Praktikabilität und Widersprüchlichkeit der Anforderungen untereinander zu achten.

Vom Unternehmensmodell ausgehend, sind die fachlichen Ziele weitgehend vorgegeben. Allerdings sind sie noch zu überprüfen sowie um weitere Projektanforderungen zu ergänzen. Auch hier ist es für die DV-Abteilung günstig, wenn sie auf die Ergebnisse aus der strategischen Informationsplanung zurückgreifen und sich dadurch mühsame und schwierige Abstimmungsprozesse mit der Geschäftsführung ersparen kann.

Jeder erfahrene Projektleiter weiß, daß die Budget-Anforderungen sensible Parameter der Projektanforderungen sind. Dies um so mehr, als die Realität zeigt, daß nicht selten Abweichungen von mehr als hundert Prozent zwischen den geplanten Zeit- und Kostenbudgets sowie dem tatsächlichen Bedarf auftreten.

Unsere Erfahrungen zeigen, daß der Aufwand für eine Software-Entwicklung stark vom Qualitätsniveau des zur Verfügung stehenden Personals, der Methoden und Verfahren, der vorhandenen Werkzeuge sowie der Erfahrung des Projektteams im Umgang mit der Software-Entwicklungsumgebung abhängt. Ein zweiter Faktor, dem entscheidender Einfluß auf das Budget zugesprochen werden kann, ist die Klarheit und Stabilität der Projektabgrenzung. Ist die Abgrenzung nicht klar formuliert und mit den Beteiligten abgestimmt, so werden diese Grenzen im Laufe der Detailstudie immer wieder neu interpretiert. Damit unterliegt die Basis der Schätzung einer stetigen Veränderung.

In der Praxis erleben wir häufig, daß zur Bestimmung der Budget-Anforderungen der Systemumfang sowie der Grad der Systemkomplexität als wichtigste Größen herangezogen werden. Meist basiert aber der geschätzte Systemumfang auf einer gedachten oder nur vage formulierten Projektabgrenzung. Ändern sich im Laufe des Projekts die Systemgrenzen, so ändert sich auch der Projektumfang - und damit die Entwicklungskosten.

Dieses Problem, das Jeder erfahrene Projektmitarbeiter kennt, kann weitgehend vermieden werden, wenn eine eingehende Anforderungsanalyse vor Beginn der Detailstudie durchgeführt wird. Einen wesentlichen Beitrag zur sauberen Projektabgrenzung liefert die strategische Informationsplanung mit der Erstellung des Unternehmensmodells und der Bildung von Anwendungssystemen.

Einen dritten wichtigen Aspekt für die Budget-Anforderungen stellen die bereits behandelten Qualitätsanforderungen dar. Qualität und Kosten stehen in einem unmittelbaren Zusammenhang. Sind zu Beginn der Detailstudie die Qualitätsanforderungen nicht hinreichend bekannt, so kann vorausgesagt werden, daß die geschätzten Entwicklungskosten nicht eingehalten werden. Insgesamt ist festzuhalten, daß zur Bestimmung der Budget-Anforderungen das Qualifikationsniveau des Projektteams, die Abgrenzung des Projekts und die Anforderungen an die Qualität der Ergebnisse als die entscheidenden Größen angesehen werden müssen.

Die Durchführungsanforderungen betreffen den organisatorischen Teil eines Projekts. Nachdem bekannt ist, welche Ziele dem Projekt zugrundeliegen und welchen Qualitätsanforderungen das Ergebnis genügen soll, ist die Projektdurchführung zu planen. Die Durchführungsanforderungen lassen sich unterteilen in die

- Wahl der Projektorganisation,

- Festlegung der Projektsteuerungsmethode,

- Bestimmung der Projektinfrastruktur sowie

- Planung des Einführungskonzeptes.

Die Projektorganisation regelt die Kompetenzen

Der Wahl der Projektorganisation kommt eine wesentliche Bedeutung für das Gelingen eines Projekts zu, denn sie bestimmt Aufgaben und Kompetenzen eines Projektleiters. Im allgemeinen hat der Projektleiter wenig Einfluß auf die Wahl der Organisationsform. Er sollte aber deren Merkmale kennen, um Schwächen vorzubeugen und Stärken besser nutzen zu können.

Generell gibt es drei Grundformen der Projektorganisation, die wir in bezug auf die Kompetenzmerkmale näher betrachten wollen:

- die Einfluß-Projektorganisation,

- die reine Projektorganisation und

- die Matrix-Projektorganisation.

Bei der Einfluß-Projektorganisation verfügt der Projektleiter über keine oder wenig Entscheidungs- und Weisungsbefugnis. Diese liegen während der gesamten Projektdauer beim Auftraggeber. Diese Organisationsform ist nur dann zu empfehlen, wenn die Bedeutung des Vorhabens für das Unternehmen sowie Umfang und Komplexität des Projekts gering sind.

Bei zunehmendem Umfang und größerer Komplexität eines Vorhabens bedarf es einer klaren Ablaufregelung bezüglich Kompetenz und Aufgabenzuordnung. Diese Regelung ist bei der Einfluß-Projektorganisation nicht gegeben. Die Arbeitsergebnisse sind bei dieser Organisationsform stark von der Bereitwilligkeit der einzelnen Projektmitarbeiter abhängig.

Die reine Projektorganisationsform ist dadurch gekennzeichnet, daß der Projektleiter alle formalen Kompetenzen besitzt. Die beteiligten Mitarbeiter sind fachlich und persönlich unter der Leitung eines Projektleiters zusammengefaßt. Dadurch werden kurze Entscheidungswege gewährleistet und schnelle Reaktionszeiten ermöglicht. Diese Organisationsform läßt sich auch dann anwenden, wenn die Bedeutung des Vorhabens für das Unternehmen, der Projektumfang sowie Kosten- und Zeitdruck sehr groß sind.

So effektiv die reine Projektorganisation auch sein kann, sie birgt auch große Risiken in sich; denn sie bedarf eines fähigen Projektleiters. Ist die Persönlichkeit des Projektleiters zu schwach, so nutzt ihm die eingeräumte Kompetenz nicht viel; ist sie zu autoritär, so wird Widerstand in der Projektgruppe erzeugt. Ähnliche Beziehungsprobleme können sich ergeben, wenn der Projektleiter über zu wenig Führungserfahrung verfügt oder geringe Fachkenntnisse besitzt.

Die Matrix-Projektorganisation schließlich teilt Verantwortung und Kompetenz zwischen Projektleitung und Fachinstanz. Eine Entscheidung kommt also nur dann zustande, wenn sich Projektleiter und Fachvorgesetzte einig sind. Diese Organisationsform ist dann zu empfehlen, wenn zwar die Bedeutung des Vorhabens für das Unternehmen und die Komplexität sehr groß sind, aber die Projektdauer nicht sehr zeitkritisch ist. Außerdem ist dies die richtige Organisationsform, wenn der Mitarbeitereinsatz für die gesamte Projektdauer nicht festgelegt ist.

Die Matrix-Projektorganisation ist die in der Praxis am häufigsten anzutreffende Organisationsform. Obwohl sie viele Vorteile besitzt - zum Beispiel flexibler Personaleinsatz - , hat sie den entscheidenden Nachteil, daß sich niemand so richtig für etwas verantwortlich fühlt. Besonders große und langwierige Projekte leiden unter dieser Krankheit.

Dennoch wird diese Organisationsform in großen Unternehmen sehr bevorzugt. Sie ist nämlich vom theoretischen Standpunkt gesehen die Beste, da eine interdisziplinäre Betrachtungsweise möglich wird. Allerdings bedarf die Matrix-Organisation einer hohen Teamfähigkeit, die in der Praxis aus Macht- und Interessensgründen meist nicht gegeben ist.

Ein Projektleiter muß sich überlegen, wie er seine Management-Funktionen wahrnehmen will. Die Projektorganisation allein sagt nichts über die Steuerungsmethode aus. Ein Projektleiter muß in organisatorischer Hinsicht Aktivitäten, Termine und Ressourcen planen, steuern und kontrollieren.

Wie der Projektleiter diese Management-Funktionen wahrnehmen will, sollte in einem Projekthandbuch festgehalten werden. Auch hier werden in der Praxis sehr viele Fehler gemacht. Oft sind im Projekthandbuch die Dinge bis ins kleinste Detail geregelt, mit der Folge, daß keiner versteht, was hier beschrieben ist.

Wer ein Regelwerk schafft, welches alles bis ins kleinste Detail festlegt, zweifelt an der Fähigkeit der Projektmitarbeiter. Darüber hinaus wird er höchstwahrscheinlich mit folgenden Problemen konfrontiert: Die Einhaltung dieses umfassenden Regelwerkes kann kaum kontrolliert werden. Außerdem ist es schwierig, ein solches Regelwerk in die Köpfe der Projektmitarbeiter zu bekommen. Bleibt zu fragen, ob der Aufwand, der zur Einhaltung getrieben wird, sich rechtfertigen läßt.

Ein allzu detailliertes Projekthandbuch schafft also mehr Probleme als Lösungen. Es wird zu einem Hemmschuh im Projekt, der jeden Freiheitsraum und jede Kreativität nimmt. Trotzdem sollte ein Projekthandbuch nicht fehlen; es muß klar und übersichtlich gegliedert sein und die wesentlichen Steuerungsinstrumente enthalten.

Nicht selten haben wir Projekthandbücher erlebt, die mehr als 400 Seiten umfassen. Der Grund für diese Aufblähung liegt neben einer zu weitgehenden Detaillierung häufig auch darin, daß in das Projekthandbuch auch technische Management-Funktionen wie die Beschreibung von Methoden und Verfahren (zum Beispiel Change-Management) aufgenommen werden.

Technische Funktionen haben jedoch nichts im Projekthandbuch zu suchen. Das Projekthandbuch hat sich zu beschränken auf Aussagen zu

- Projektauftrag,

- Projektzielen,

- Projektführung,

- Projektvorgehen,

- Projektdokumentation und - - Projektberichtswesen.

Zu den Durchführungsanforderungen gehört auch die Festlegung der Projektinfrastruktur sowie die Planung des Einführungskonzeptes. Zur Projektinfrastruktur wiederum zählen die Festlegung von Entwicklungs- und Zielumgebung (Rechnerarchitektur, Trägersysteme) sowie die notwendige Ausstattung bezüglich Räumlichkeiten und Betriebsmittel. Die Auswahl der Entwicklungs- und Zielumgebung sollte frühzeitig beginnen, spätestens aber dann, wenn die Untersuchungsergebnisse aus der Anforderungsanalyse vorliegen.

Die Planung des Einführungskonzeptes ist eine sehr wichtige Maßnahme, die ebenfalls frühzeitig im Projekt eingeplant werden sollte. Mit dem Einführungskonzept wird nicht nur die technische Vorbereitung der Anwender auf ihre Aufgabe festgelegt, sondern auch die Form der Akzeptanzbildung bei den Beteiligten am System. Viele Störungen, die bei der Einführung einer neuen Lösung auftreten, zum Beispiel Widerstand gegen Veränderungen oder Gefährdung des Arbeitsplatzes, können vorweggenommen und durch geeignete Begleitmaßnahmen abgefangen werden, wenn bereits im Planungsstadium die denkbaren Auswirkungen auf die Organisation diskutiert werden.

Die strategische Informationsplanung liefert nicht alle Voraussetzungen, die zu Beginn einer erfolgreichen Projektarbeit vorliegen müssen. Wesentlich ist zum einen, daß aus der strategischen Informationsplanung heraus der Untersuchungsbereich eines Projekts sowie die angestrebten fachlichen Ziele vorliegen. Zum anderen ist jedoch genauso wichtig, daß der Untersuchungsbereich in bezug auf seine Schnittstellen zu anderen Bereichen klar und unmißverständlich abgegrenzt wurde.

* Bernhard Hitpass, Ulrich Richter und Eric Rottee sind Mitarbeiter der Innova Consulting GmbH, Wiesbaden.