Die Projektplanung bei Software-Entwicklung ist meist unterentwickelt und wird nur (wenn überhaupt) mit halbem Herzen durchgeführt. Ein optimales Verfahren kann wohl von niemand angeboten werden. Einige allgemeine Aspekte zur Gliederung eines Projekts, zu

den Zeit- und Aufwandsschätzungen sowie zur Projektabwicklung insgesamt sollten aber

doch in jedes Planungsverfahren eingehen.

Das Problem ist so alt wie die Software-Entwicklung selbst. Wie kommt man zu realistischen Sehätzungen für den Zeitaufwand, der für die Teilaktivitätiten eines Projekts angesetzt werden muß? Wie setzt man diese in eine vernünftige Beziehung zueinander und wie behält man die Projektabwicklung unter dem Aspekt der Termine im Griff?

Die wohl am häufigsten praktizierte Vorgehensweise ist ungefähr folgende:

Im Verlauf der Projektierungsphase teilt man das Projekt mehr oder weniger grob in Teilaktivitäten auf, für die der zu erwartende Zeitaufwand geschätzt wird, meist aus sehließlieh nach Kriterien der eigenen Erfahrung. Durch Zuordnung der Projektmitarbeiter

und der Aktivitäten sowie durch Aneinanderreihen derselben pro Mitarbeiter enthält man Tätigkeitsketten, aus denen sich Zwischentermine und Endtermin nablesen lassen.

Nach dem so erzeugten Plan wird dann mit den besten Vorsätzen losproduziert. Der Plan versehwindet in einer Sehublade oder dekoriert unbeachtet eine Wand.

Wenn dann der Endtermin in Sichtweite kommt, stellt man fest, daß eigentlich noch sehr viel zu tun ist, daß der Termin wohl nur unter äußersten Anstrengungen zu halten ist.

Also ordnet man Überstunden an; große Hektik bricht aus, man entdeckt hier und da noch einige "vergessene" Funktionen, und der Termin muß mehrfach verschoben werden. Hinterher sagt man dann, wenn dies nicht gewesen und jenes nicht plötzlich aufgetreten wäre, hätte man pünktlich fertig sein können. Es leuchtet ein, daß dies nicht optimal ist. Andererseits gibt es sicher kein allgemeingültiges Verfahren im Sinne eines Kochbuches. Man muß immer eine dem Projekt angemessene Vorgehensweise erarbeiten.

Einige allgemeine Gesichtspunkte könnten und sollten jedoch in jedem Projekt Beachtung finden:

- Gliederung des Projekts

Teilaktivitäten sollten in der Regel nicht mehr als rund 8 Mannwochen Aufwand erfordern, um sie überschaubar zu halten. Bei großen Projekten muß deshalb die Aufgliederung mehrstufig in hierarchischen Ebenen erfolgen, wobei die unterste Ebene die feinste Aufteilung enthält. Jede dieser Ebenen muß später gleichberechtigt im Kontrollmechanismus berücksichtigt werden. Die Zeitschätzung erfolgt für die Aktivitäten der untersten Ebene, da die hierarchisch höherliegenden Ebenen aus ihr resultieren. Alle Aktivitäten müssen auf sachliche (und damit auch zeitliche) Abhängigkeiten zu anderen Aktivitäten untersucht und unter deren Berücksichtigung in den zeitlichen Ablauf eingeplant werden.

- Zeitschätzungen

Auf dem Markt werden verschiedene Verfahren zur Aufwandsentschädigung für Software-Entwicklung angeboten. Selbst sehr detaillierte Verfahren können zwangsläufig nicht alle spezifischen Aspekte eines Projekts berücksichtigen.

Eines haben aber zumindest die etwas detaillierteren Verfahren gemeinsam: Sie geben einen umfassenden Überblick, welche Aspekte standardmäßig in die Schätzungen eingehen sollten. Eine Mischung aus Standardverfahren, persönlichen Erfahrungen und der Berücksichtigung der speziellen Eigenheiten und Umstände des Projekts ergibt die besten Schätzwerte.

Anzumerken wäre noch, daß die meisten EDV-Leute dazu neigen, optimale Bedingungen für die Produktion anzunehmen, obwohl doch eigentlich jeder wissen müßte, wie schnell und wieviel Zeit verlorengeht durch unvorhergesehene Schwierigkeiten, Anlagenausfälle, Besprechungen etc. Dazu kam dem Management auch ein personenbezogener "Korrekturfaktor" für Selbstüberschätzung empfohlen werden.

- Projektabwicklung

Wichtigste Voraussetzung für eine sinnvolle Terminüberwachung ist, daß sie von allen Beteiligten ernst genommen wird: Einerseits müssen die Angaben über den Istzustand und die künftige Entwicklung gewissenhaft erarbeitet, andererseits aus deutlichen Abweichungen von Ist- und Sollzustand auch Konsequenzen gezogen werden beispielsweise durch personelle Änderungen im Team, durch Prioritätenverschiebungen für die Entwicklung oder durch die Änderung der Arbeitsbedingungen des Teams.

Wenn diese Voraussetzung nicht gegeben ist, ist es schade um jede Stunde, die in die Planung gesteckt wird.

Die Soll-Ist-Vergleiche müssen regelmäßig durchgeführt werden, je nach Projektgröße und voraussiehtlicher Dauer alle 1-4 Wochen. Das Verfahren des Soll-Ist-Vergleichs hängt natürlich ebenfalls von der Anzahl der Aktivitäten und der Anzahl der Projektmitarbeiter ab. Das Spektrum reicht von schlichten verbalen Aufzeichnungen über Balkendiagramme, Netzpläne und von EDV-integrierte Verfahren bis hin zu Kombinationen der genannten.

Es empfiehlt sich, die Terminüberwachung in Problemfällen einem guten Fachmann außerhalb des Teams zu übertragen.

Ein großes Handicap in der Projektabwicklung sind oft die "politischen" Termine, also solche, die nicht auf Grund von Aufwandschätzungen entstanden sind, sondern die von außerhalb der EDV, aus welchen Gründen auch immer, vorgegeben werden und meist nicht einzuhalten sind. Hier sollte man unter allen Umständen, zumindest intern, bei einer realistischen Planung bleiben. Das schließt natürlich in keiner Weise aus, daß alles nur mögliche versucht wird, sich dem "politischen" Termin weitestgehend zu nähern.

Fazit: Nach gründlicher Planung kann man sich durch regelmäßige Projektüberwachung mit relativ wenig Aufwand (im Verhältnis zur Projektgröße) jederzeit einen genauen Überblick über den Stand des Projekts und über bestehende oder zu erwartende Risiken und Engpässe verschaffen.

Der wesentliche Vorteil liegt darin, daß auf Schwierigkeiten und Probleme nicht erst nach deren Auftreten und nachdem sie womöglich schon Schaden angerichtet haben, reagiert wird, sondern, daß sie schon im voraus beseitigt oder zumindest verringert werden können.