Ein Projekt ist einmalig. Es ist mit gewissen Risiken verbunden und ist, da es einmalig ist, nicht mit einem anderen Projekt direkt vergleichbar. Das ist eine in allen Lehrbüchern beschriebene Tatsache. Wenn Projekte einmalig sind, wieso geht man dann immer mehr oder weniger gleich an Projekte heran? Ganz einfach: Projekte können anhand bestimmter Eigenschaften klassifiziert werden. Und so ist die Herangehensweise natürlich pro Projekttyp sehr ähnlich. Wenn ich hier jetzt beschreibe, wie die Vorstudie zu strukturieren ist, kann das keine allgemeingültige Beschreibung sein. Es ist eine mögliche Art die Vorstudie zu strukturieren. Wenn man nichts hat, kann man sich hier ein paar Ideen herausfischen. Andere Themengebiete sind nicht relevant oder durch diese Vorstudie nicht abgedeckt. Also: Selber kreativ sein und Hirn einschalten! Nicht alles was Roland sagt stimmt. Normalerweise laber ich sogar ziemlich viel Mist. Das kommt daher, dass es keine einzige Wahrheit gibt. Die Projektmanagementwelt ist bunt und nicht schwarz- weiß. Thomas befragte in der ersten Woche die Entwickler, Giuseppe, den Familienvater der anderen Firma und einige schwere Jungs. Thomas ist (so wie ich) ein bisschen schwer von Begriff. Aber nach der Woche war ihm klar, dass er sich mit einer kriminellen Vereinigung eingelassen hatte und so schnell da nicht mehr herauskommen wird. Welchen Zweck die Betonschuhe und der Familienteich haben wurde ihm auch klar. „Was solls, wenn man schon Mist baut, dann wenigstens Spaß dabei!“, sagte er sich. Da an kündigen nicht zu denken war, entschied Thomas sich das Projekt durchzuführen. Er erstellte eine Vorlage für eine Vorstudie mit folgenden Kapiteln (zu den Begriffen siehe Glossar Informatik):

Einleitung / Management Summary

Hier wird auf maximal einer Seite beschrieben was mit dem zu erstellenden System erreicht werden soll. Es soll den Auftraggebern eine Zusammenfassung geben, was sie erhalten und die wichtigsten Eckpunkte auflisten.

Systemübersicht

Falls möglich, sollte gleich eine sehr grobe Systemübersicht dargestellt werden.

Anforderungen

Auflistung der Eigenschaften die dieses System haben soll. Die Anforderungen werden in funktionale und nicht-funktionale Anforderungen aufgegliedert. Hier kann schon mit Usecases gearbeitet werden. Wie die Anforderungen zusammen gesammelt werden ist im Prinzip nicht wichtig. Hauptsache sie sind eindeutig identifizierbar und so vollständig wie möglich. Beispielsweise kann man jeder Anforderung eine Nummer geben. Diese Nummer kann man später wieder verwenden.

Funktionale Anforderungen

Hier wird beschrieben was man mit dem System später machen kann. Zum Beispiel „Anf#82: Verwalten der schweren Jungs“ oder „Anf#98 Auflistung wie viel Schmuggelware abgegeben wurde“ Weiterhin sind funktionale Anforderungen die Beschreibung der Schnittstellen und anzubindenden Systeme.

nicht-funktionale Anforderungen

Wie der Name schon sagt- handelt es sich hier um Anforderungen, die nichts direkt mit der Funktion zu tun haben. Im Prinzip ist es egal ob eine Berechnung 100 Tage benötigt. Wenn nach 100 Tagen das Ergebnis der Berechnung vorliegt, hat die Funktion funktionert. Eventuell sind 100 Tage aber ein bisschen lange um 20+30 zu rechnen

Sicherheitsanforderungen

Welche Personen dürfen auf welche Daten zugreifen? Wie schützen wir uns vor anderen Familien oder der Steuerbehörde?

Geschwindigkeit

Wie lange darf eine Bearbeitung dauern?

Mengengerüste

Wie viele Mitarbeiter, Daten und Zugriffe sind zu erwarten?

Betreibbarkeit

Welche Service Levels müssen vereinbart werden? Vor allem bei einem System, indem Personen direkt betroffen sind, muss man sich hier besonders viel Gedanken machen. Wie viel Wartungsfenster sind zu erwarten? Welche weiteren Kriterien sind hier zu beachten? (Rechenzentrumeigenschaften usw.)

Rechtliche Fragen

Was erlaubt das Gesetz? Im Fall der Familie: was ist erlaubt und was wird geahndet?

Desaster Recovery

Wie schnell müssen welche Funktionen nach einer Katastrophe wieder verfügbar sein? Welche Vorgaben sind in der Firma vorhanden?

Business Continuity

Wie wird gewährleistet das im Katastrophenfall die Geschäfte weiter getätigt werden können? Von welchen IT-Systemen ist die Firma abhängig?

Wartbarkeit

Gibt es spezielle Anforderungen an die Wartbarkeit der Systeme? Beispielsweise sind die Legacy Systeme weiterhin zu warten. Wie soll das gewährleistet werden?

Erweiterbarkeit

Jedes System muss erweiterbar sein. Wo sind die Grenzen? Woran kann erkannt werden, dass diese Grenzen erreicht werden?

Dokumentation

Welche Dokumentation (Betriebsdokumente, Sourcecode Beschreibung usw.) muss erstellt werden?

Stakeholder

Welche Personengruppen sind im späteren Projekt zu beachten? Je politischer ein Projekt ist, desto wichtiger ist es zu wissen, wen man alles informieren muss. Dieser Punkt kommt zwar später wieder in der Projektbeschreibung, doch schadet es nichts, sich schon sehr bald darüber klar zu werden, wer alles betroffen ist.

Abgrenzungen

Was ist nicht Aufgabe dieses Systems? Diese Frage ist sehr wichtig. Ansonsten wird man mit ungeplanten Anforderungen zugeschüttet. Beispielsweise ist das bestehende System deshalb so komplex, da während des Erstellens immer neue Anforderungen hinzugefügt wurden. Hier kann erkannt werden, dass die Vorstudie unter Umständen schon ein eigenes Projekt ist. Bei großen Systemen wird daher die Vorstudie schon als Evaluationsprojekt durchgeführt. Egal wie groß ein Projekt ist, ich kann nur empfehlen eine gewissenhafte Vorstudie durchzuführen. Jede Überlegung in diesem Bereich spart euch hinterher das Vielfache an Ärger, Fehlern und Aufwänden!