Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.03.1992 - 

Projektmanagement in der Praxis (Teil 2)

Bei der Projektentstehung werden die Weichen gestellt

Wie Projekte entstehen, durch wen und wie präzise der Projektauftrag formuliert wird, ist für deren weiteren Ablauf und letztlich für ihr Ergebnis von großer Bedeutung. In vielen Projekten werden allerdings die Weichen von Anfang an falsch - oder schlimmer noch - gar nicht gestellt. Die Auswirkungen sind dann im weiteren immer wieder spürbar.

Ihre Entstehungsgeschichte zu rekonstruieren, fiel bei fast allen untersuchten Projekten ausgesprochen schwer. War der Weg zum "offiziellen" Beginn bei einigen Projekten erstaunlich kurz und unkompliziert, so stellt sich der Prozeß ihrer Initiierung und der Abstimmung, der ihrer offiziellen Sanktionierung vorausging, bei den meisten Projekten recht mühselig und langwierig dar. Bisweilen zog er sich über Jahre hinweg.

Meist verloren sich die eigentlichen Anfänge in einem Dunkel, in dem nur schwer die ursprünglichen Anstöße und Urheber auszumachen waren. Das trifft nicht nur für Entwicklungsvorhaben zu, die erst relativ spät "offiziellen" Status erhielten, sondern auch für Projekte, deren Beginn durch einen ausdrücklichen Auftrag - der Geschäfts- oder Bereichsleitung, eines Kunden - markiert wurde.

Mochte dieser Auftrag auch als die offizielle Geburtsstunde eines Projekts gelten, seine eigentlichen Anfänge wiesen meist weiter zurück. Vorangegangen war eine längere Periode, in der sich eine zunächst vage Unzufriedenheit mit den bestehenden Verhältnissen bemerkbar machte und Schritt für Schritt zu einer Projektidee verdichtete, oder die Faszination an dem Leistungspotential neuer Technologien zu der Forderung führte, über diese verfügen zu können.

Dabei waren die Initiatoren in sehr unterschiedlichen Bereichen zu finden: in der DV-Abteilung des Unternehmens, in den Fachbereichen, in der Geschäftsleitung oder auch in externen Beratungs- oder Herstellerfirmen. Sie hatten auch sehr unterschiedliche hierarchischen Positionen inne - vom Vorstandsvorsitzenden bis zum Sachbearbeiter.

In 41 Prozent der Projekte ging die Initiative vom Anwenderbereich aus, in 26 Prozent von der Geschäftsleitung, in weiteren 26 Prozent vom Bereich DV/Organisation/Softwareentwicklung, bei 26 Prozent der Projekte kamen die Impulse von außen, von Beratern, Softwarehäusern oder Herstellern. Natürlich unterscheidet sich die Situation in Softwarehäusern und Anwenderunternehmen grundlegend. In Softwarehäusern waren entweder die eigene Geschäftsleitung oder externe Auftraggeber die Initiatoren von Projekten. In Anwenderunternehmen kamen die ersten Impulse in etwa der Hälfte der Projekte aus dem Anwenderbereich, zu etwa einem Drittel von der DV/Organisation. (Siehe Tabelle 1)

Typische Entstehungskonstellationen, denen wir bei den untersuchten Projekten begegneten, waren:

- Ein oder mehrere Entwickler in der DV-Abteilung eines

Anwenderunternehmens konzipieren die Idee für das Vorhaben, angeregt durch Schwierigkeiten, denen sie in ihrer Arbeit begegnen.

- Im Dialog zwischen Anwendern und Entwicklern entsteht der Plan für ein neues- Vorhaben, angeregt etwa durch die Grenzen und Unzulänglichkeiten des bestehenden Einsatzes der Informationstechnik.

- Die Erstinitiative für das Entwicklungsprojekt geht von einer Führungskraft im Fachbereich oder einem Mitglied der Geschäftsleitung aus; bestimmend sind dabei Hoffnungen

auf Rationalisierungsgewinne, auf Eröffnung neuer Handlungsmöglichkeiten oder schlicht die Faszination am neuen Technikpotential.

- Die Initiative für das Entwicklungsvorhaben kommt von außen, von einem Berater, Hersteller, Softwarehaus, häufig in informeller Abstimmung mit internen "Promotoren", die sich von solchen Initiativen bessere Durchsetzungschancen versprechen.

Gerade in Projekten, die dann nach "außen" an Softwarehäuser oder Hersteller vergeben wurden, waren solche "Kurzschlüsse" zu beobachten.

Im "normalen" Ablauf, in knapp der Hälfte der Projekte, führten diese Initiativen zu einem formalen Projektauftrag durch die Geschäftsleitung, einen Investitionsausschuß oder andere Stellen - durch den das Projekt sozusagen offiziellen Status erhielt. Bei einem Fünftel der Projekte ging ein solcher Auftrag auf einen förmlichen Projektantrag zurück. Bei etwa einem Drittel allerdings gab es einen solch offiziellen Auftrag nicht, sie gewannen ihren Status als "Projekt" als Ergebnis zunächst weitgehend informeller Aktivitäten.

Gehörten Anwender noch in relativ vielen Softwareprojekten mit zu den ursprünglichen Initiatoren, so waren dann bei der Formulierung des Projektauftrags eindeutig andere Bereiche dominierend: die Geschäftsleitung und der DV-Bereich.

Geringer dagegen war der Einfluß des Anwenderbereichs. Dies führte häufig dazu, daß die Formulierung des Entwicklungsauftrages vorrangig aus der Perspektive der "Techniker" oder DV-Organisatoren erfolgte und wesentlich durch deren Sichtweise und Interessen bestimmt war.

In nur gut einem Viertel der Projekte war der Anwenderbereich in die Formulierung des Projektauftrages maßgeblich einbezogen. In 48 Prozent wurde der Projektauftrag durch die Geschäftsleitung formuliert, in 39 Prozent durch den DV-Bereich. In 13 Prozent waren Externe (Berater/Hersteller) mit einbezogen.

In einem Projekt, das von einem Großunternehmen an ein Softwarehaus vergeben wurde, waren in die Formulierung des Auftrages Mitarbeiter der Organisationsabteilung und die Abteilungsleiter mehrerer Anwenderbereiche einbezogen. Die Verhandlungen mit dem Softwarehaus, in dem Umfang und Inhalt des Auftrages detailliert festgelegt wurden, führte dann der Leiter der Organisationsabteilung mit einem der Geschäftsführer des Softwarehauses.

Eine Untersuchung in amerikanischen Unternehmen kommt zu dem Schluß, daß "die Leute, die über die Entwicklung von Software entscheiden, selten auch die sind, die sie tatsächlich nutzen". Dieser Befund gilt weitgehend auch für die Entstehungsgeschichte der von uns untersuchten Softwareprojekte. Diese Abgehobenheit der Entscheidungssituation kam um so stärker zum Tragen, als sie häufig durch komplementäre Wissensdefizite der Beteiligten akzentuiert war. Die involvierten DV- oder Software-Experten hatten nur rudimentäre Kenntnisse von der Anwendungssituation, das Management seinerseits verfügte über kaum ausreichenden Einblick in die technischen Aspekte, über die entschieden wurde.

Die Auswirkungen solcher Abgehobenheit der Abstimmungs- und Entscheidungsprozesse, die dann zum Projektauftrag führen, von den Bedingungen und Anforderungen, die die eigentliche Nutzungssituation bestimmen, waren in vielen Projekten bemerkbar.

Diese mangelnden technischen Fachkenntnisse auf der einen Seite, wie auch die ungenügende analytische Durchdringung der Anwendungssituation auf der anderen führte dazu, daß der Forderungskatalog mit Leistungsmerkmalen überfrachtet wurde, über deren Notwendigkeit nur sehr vage Vorstellungen bestehen.

Je weniger präzise man wußte, wie und wofür man die neue Software nutzen will, desto expansiver war man mit seinen Wünschen, wobei diese sich weniger an den Gegebenheiten und Anforderungen des Anwendungsfeldes ausrichteten als an dem Spektrum an Funktionalitäten, den die "Technik" anbot, das man von ihr erwartete.

War auf rein technischer Seite eine Neigung zur Ausweitung der abgeforderten Funktionalitäten zu beobachten, so war in der organisatorischen Dimension - soweit diese Oberhaupt thematisiert wurde - eher eine minimalistische Tendenz erkennbar. Nach dem Motto "Wasch mich, aber mach mich nicht naß" versucht man, arbeitsorganisatorische Konsequenzen möglichst offenzuhalten oder ausdrücklich auszuschließen.

Belastet wurde die Entstehung von Softwareprojekten häufig dadurch, daß der Projektauftrag nicht unumstritten war. Immerhin in knapp der Hälfte der Projekte gab es in der Entstehungsphase Meinungsverschiedenheiten, in Anwenderunternehmen war dies bei 38 Prozent der Projekte, in Softwarehäusern sogar bei 48 Prozent der Fall. Solche Konflikte gab es bei "externen" Projekten, die nach außen gegeben wurden, zwischen Auftraggebern und Auftragnehmern wie bei internen Projekten zwischen den involvierten Stellen.

Umstritten war die Konzipierung von Projekten meist nicht so sehr wegen ihrer Kosten oder wegen fragwürdiger Wirtschaftlichkeit. Dazu fehlten vielfach schon die entsprechenden Informationen. In einem Sechstel der Projekte gab es keine Kalkulationen der voraussichtlichen Kosten, in einem guten Drittel wurden sie erst mit Projektbeginn als Orientierungsgröße, nicht aber als Entscheidungsgrundlage erstellt. Mit anderen Worten: In nur der Hälfte der Projekte gingen - mehr oder weniger fundierte - Kostenkalkulationen in die Entscheidung ein.

Kontrovers waren vor allem jene Aspekte des Projektauftrages, durch die Möglicherweise Belange einzelner betrieblicher Stellen berührt wurden, etwa wenn es um Fragen der Kompetenz oder Aufgabenverteilung ging. Dies widerspricht nicht der festgestellten Tendenz, den Entwicklungsauftrag als primär oder ausschließlich technische Aufgabe zu definieren. Mochten es auch letztlich Kompetenzfragen gewesen sein, die hinter den Auseinandersetzungen standen, die Argumentation wurde auf technischer Ebene ausgetragen.

Die Entstehungsgeschichte der untersuchten Projekte zeigt also eine außerordentliche Vielfalt: in ihrer Dauer, in dem Grad der Formulierung, in ihrer Konflikthaftigkeit und in der Sorgfalt und Präzision, mit der der Auftrag formuliert wurde. Gemeinsam scheint ihnen eines: die Behandlung des Auftrages als primär technische

Entwicklungsaufgabe.

Mit der Verschiebung bei den Akteuren und Promotoren des Projektes ging häufig auch eine Umakzentuierung der ursprünglichen Definition der Entwicklungsaufgabe einher: Die fachlichen Probleme, die ursprünglich die ersten Anstöße zur Projektentstehung gegeben hatten, traten eher in den Hintergrund, technische Fragestellungen dominierten mehr und mehr.

Ergebnis dieser Entstehungsbiographie war auch, daß in vielen Projekten der Entwicklungsauftrag nur sehr allgemein und unzulänglich umrissen war und daß dieser vor allem kaum eine stabile Grundlage lieferte.

In nur einem Viertel der Projekte meinten die befragten Experten, im Projektauftrag seien Ziele detailliert formuliert worden. In 43 Prozent war dies nur sehr allgemein der Fall und in 31 Prozent wurden die Zielsetzungen als diffus bezeichnet. Nur in jedem fünften Projekt blieb der Projektauftrag im Verlauf des Projektes unverändert. In 46 Prozent war eine Präzisierung notwendig, in 34 Prozent kam es im Projektverlauf zu einer oder mehreren Neudefinitionen.

Den Auswirkungen der Entstehungsgeschichte von Projekten werden wir in ihrem weiteren Ablauf immer wieder begegnen: bei der Abwicklung des Projektmanagements und des Personaleinsatzes, in ihrer Konflikthaftigkeit und der scheinbar widersinnigen Diskontinuität vieler Entwicklungsprozesse und nicht zuletzt bei der Spezifikation der Anforderungen. (wird fortgesetzt)