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.

02.02.1979 - 

Projektplanung und -kontrolle:

Distributed Processing von rückwärts

MÜNCHEN - In Unternehmen, die seit längerer Zeit Datenverarbeitung betreiben, haben wir heute die Situation, daß etwa ein bis drei mittlere Projekte mit Aufwendungen von einem Mannjahr oder mehr laufen. Daneben sind jedoch viele Kleinaktivitäten von wenigen Mannwochen oder auch nur von Manntagen abzuwickeln. Sie beziehen sich auf Ergänzungen und Erweiterungen bestehender Anwendungen, auf Programmänderungen, auf Fehlerbehebung und auf Verwaltungsprobleme der Organisations- und EDV-Abteilung.

Gerade die Kleinaktivitäten stören jedoch in zunehmendem Maße die reibungslose Abwicklung neuer Projekte, weil kurzfristig immer wieder Prioritäten verschoben werden müssen.

Durch die Installation von maschinellen Projektplanungssystemen versuchen viele, das Problem zu lösen. Dies gelingt jedoch aus meiner Erfahrung heraus nur dann, wenn derartige Systeme einen guten Komfort hinsichtlich der Kleinaktivitäten, sprich Änderungen, bieten. Leider liegt hier manches im Argen. Oft unterstützen Projektplanungssysteme wirklich nur die Entwicklung von neuen Projekten gut, der Änderungsdienst wird vernachlässigt, der Benutzer wird schlichtweg allein gelassen.

Änderungsdienst einbeziehen

Aus zahlreichen Gesprächen mit EDV-Leitern und Praktikern der Organisation habe ich die Erkenntnis gewonnen, daß eine optimale Unterstützung des Änderungsdienstes eine dringende Forderung der Benutzer bei einem Projektplanungssystem ist. Dies darf aber keinesfalls bedeuten, daß die Verfolgung der Projektsituation negativ betroffen wird. Damit ist lediglich gemeint, daß eine gewisse Gleichrangigkeit zwischen Kleinaktivitäten und Projekten zu erzielen ist. Dies muß einfach aus den gegebenen Realitäten des EDV-Alltags abgeleitet werden. Es ist eben nicht realisierbar, daß der Änderungsdienst für bestehende Anwendungen für mehrere Jahre abgekappt wird. Tut man dies doch, so machen sich die Fachbereiche organisatorisch selbständig. Distributed Processing von rückwärts ist die unausbleibliche Folge.

Was sollte also ein Projektplanungssystem an wichtigen Komponenten enthalten?

Es ist einleuchtend, daß alle wichtigen Detailinformationen der Projektabwicklung Bestandteil eines Projektplanungssystems sein müssen. Hierzu zählen etwa folgende Daten, wie Projektnummer, Plantermin, Fertigstellungstermin, Planaufwand, Restaufwand und Ist-Aufwand. Derartige Daten sollten nach möglichst beliebigen Sortierungen mit einer Art Reportgenerator auswertbar sein. Wünschenswert wäre auch eine abteilungs- und gruppenmäßige Zuordnung, damit mehrere Abteilungen innerhalb der ORG/EDV ihre eigenen Reports bekommen können.

Aufgeschmissen ohne Fachbereichs-Informationen

Projekte und Kleinaktivitäten werden für Fachbereiche erarbeitet. Es kommt daher darauf an, daß ein ORG/EDV-Bereich über detaillierte Informationen aller Aktivitäten verfügt, die er für diesen entsprechenden Fachbereich abgewickelt hat oder in Zukunft durchfuhren soll. Wie soll sonst eine wirkungsvolle Steuerung gegenüber den Fachbereichen erfolgen, wenn der ORG/EDV-Bereich keine brauchbaren Informationen aus der Sicht des Fachbereichs besitzt? So sollten etwa folgende wichtige Fragestellungen ad hoc beantwortet werden können:

- Wieviel Manntage ORG/EDV-Arbeit wurden im letzten Jahr für den Fachbereich investiert?

- Wieviel Manntage liegen als unerledigte Anforderungen für diesen Fachbereich vor?

- Wieviel Programmänderungen wurden im letzten Jahr beantragt sind durchgeführt?

- Wie steht der jeweilige Fachbereich im Vergleich zu den anderen Fachbereichen?

- Wieviel Terminänderungen wurden im letzten Jahr von Seiten des Fachbereichs vorgenommen?

- Welche Aktivitäten sind aus der Sicht des Fachbereichs bei einzelnen Projekten in naher Zukunft kritisch?

Mit Fachbereichen kann man im allgemeinen nur dann konkret über Prioritäten, Verschiebungen und Projektablehnungen reden, wenn man ihnen die eigene Situation im Vergleich aufzeigen kann. Einen übermäßigen Änderungsdienst kann man auch nur dann abblocken oder mildern, wenn Informationen über die negativen Folgen vorliegen oder ableitbar sind. Unabhängig von der Projektsortierung müssen deshalb Informationen zu Projekten und Kleinaktivitäten nach Fachbereichen selektiert werden können, damit konkrete Gespräche mit den Fachbereichen geführt werden können.

Ohne Alternativ-Berechnungen geht's nicht

Die Projektabwicklung würde sich in den meisten Unternehmen reibungslos vollziehen, wenn das Änderungsproblem nicht wäre. Die mittel- und langfristige

Scholz: "Maschinell ermittelte Termine werden oft mit Mißtrauen betrachtet."

Termin- und Kapazitätsplanung ist nicht das entscheidende Problem bei der EDV-Projektplanung. Diese läßt sich leicht mit einem Balkendiagramm und mit entsprechenden manuellen Mitarbeiterübersichten führen. Es gibt jedoch in fast allen ORG/EDV-Bereichen ein kurzfristiges Dispositionsproblem, das sich etwa auf die nächsten drei bis sechs Monate im voraus erstreckt. Für diese Zeit muß eine möglichst exakte Personal und Terminplanung vorliegen können. Ein Projektplanungssystem sollte daher in der Lage sein, für diesen Zeitraum im voraus Alternativberechnungen anstellen zu können, wenn dies gewünscht

wird.

Projekttermine sind Verhandlungssache

So wäre es wünschenswert, daß ein Projektplanungssystem auf der Basis der bisherigen Projektsituation quasi automatisch neue Aktivitäten entsprechend gewünschten Endterminen einplant und nun die kapazitätsmäßigen Engpässe kurzfristig aufzeigt. In einem Alternativlauf könnte dann ein Verschieben bestehender Projekte oder der neuen Aktivitäten (nach Diskussion mit den Fachbereichen) erfolgen. Ich halte es nicht für glücklich, wenn ein System aufgrund netzplanmäßiger Abhängigkeiten und individueller Personalkapazitäten aller ORG/EDV-Mitarbeiter eine optimale Einordnung eines neuen Projektes vornimmt. Der Verwaltungsaufwand auf der Benutzerseite ist, dazu erstens zu hoch und zweitens zwingt die betriebliche Praxis mehr zu pragmatischen Lösungen, die in enger Zusammenarbeit mit den Fachbereichen zu erarbeiten sind. Projekttermine werden heute mehr und mehr verhandelt, so daß maschinell ermittelte Termine oft mit Mißtrauen betrachtet werden.

Selbst das Top-Management sollte informiert werden

Ein Projektplanungssystem sollte in der Lage sein, eine Projektliste für das Top-Management erstellen zu können, in der die wesentlichen Projektdaten, in einer einzigen Zeile je Projekt, zusammengestellt sind, so daß alle Projekte quasi auf einem Blatt dargestellt werden können. Eine solche Liste dient dann als Grobinformation und Basis für weitere Informationswünsche seitens des Managements.

Mitarbeiter im ORG/EDV-Bereich sind auch nur Menschen mit all ihren Stärken und Schwächen. Jeder Mitarbeiter wird immer wieder versuchen, negative Tatsachen zu vertuschen. Ein Projektplanungssystem sollte daher die Änderungen von Planaufwendungen oder Planterminen unlöschbar festhalten können, damit auf diese Art und Weise eine Projekthistorie aufgebaut wird. Ist ein Projektplanungssystem dann zusätzlich in der Lage, beliebige Bemerkungen zu den Stammdaten einsteuern zu können, so besteht die Möglichkeit der Verwaltung einer Abwicklungshistorie des gesamten Projektgeschehens. Die Diskussion mit Fachbereichen und ORG/ EDV-Mitarbeitern wird dadurch erheblich vereinfacht, weil alle wesentlichen Projektdaten in einem maschinellen Verwaltungssystem festgehalten werden. Sind dann auch die organisatorischen Kleinaktivitäten in das System integriert, kann eine wesentliche Entlastung des ORG/EDV-Managements sowie aller Projektleiter und Gruppenleiter festgestellt werden.