Projekt-Scoping

Ihr Chef hat Ihnen das Projekt übergeben mit den Worten: „Das schaffen Sie schon!“. Nach dem Durchsehen der Unterlagen haben Sie sogar Zeit gehabt, mit dem Projektteam zu sprechen – nur... irgendwie taucht aus dem Nebel keine strahlende Erkenntnis auf?

Vielleicht befolgen Sie sogar den Rat aus einem der letzten Blog-Posts und orientieren sich an den neun Bereichen: dabei fällt Ihnen dann auf, dass insbesondere der Umfang (Scope) und die Kosten nicht klar sind. Was nun?

Kennen Sie den alten Witz mit dem Bildhauer, der von einem begeisterten Kunstfreund gefragt wird, wie er denn so wundervolle Madonnen aus dem Stein herausarbeitet? „Ach, ich meißel’ halt alles weg, was nicht nach Madonna aussieht!“. So einfach ist es zwar nicht – der Ansatz ist aber ähnlich: ich empfehle Ihnen, ein „Scoping“ durchzuführen, also die wesentlichen Inhalte, Kosten und Dauer aus dem Nebel ans Licht zu zerren. 

Für Software-Projekte erstellen Sie iterativ folgende Artefakte:

Business Case

Lohnt sich das Endprodukt? Zumindest sollte jemand identifizieren können, was der Nutzen ist, wenn auch nicht immer in EUR.

Welche Annahmen liegen dem Szenario zu Grunde? Wenn Sie dies wissen, können Sie viel effektivere Entscheidungen treffen!

Beispiel: Sie erstellen eine Verwaltungssoftware, die nicht am Markt als Standardsoftware verfügbar ist. Mitten im Projekt stellen Sie fest, dass ein Softwarehaus mit drei Buchstaben kurz vor der Fertigstellung einer Standardsoftware steht. Was nun? Ist Ihre Lösung noch viel billiger als die neue? Welche Vorteile hat Ihre Lösung, die im Standard nicht zu finden sind? Müssen Sie sich vielleicht noch stärker auf die individuellen Features fokussieren?

Übersicht Geschäftsprozesse

In vielen großen Unternehmen werden von Organisations- oder Optimierungs- oder Prozess-Abteilungen Geschäftsprozesse erfasst, verwaltet und auf fachlicher Ebene analysiert. Dabei reicht die Bandbreite von „Bilder malen“ bis hin zu ausgewachsener BPMN-Modellierung mit direkter Verwendung in Workflow-Engines. Mein Eindruck: es wird häufiger gemalt als modelliert. Das liegt wohl auch daran, dass Fachabteilungen in fachlichen Zusammenhängen denken – nicht in Algorithmen. Sonst würden die Mitarbeiter ja auch schnell in der IT-Abteilung landen...

Gut nutzen kann man Prozess-Landkarten, Bebauungspläne usw. Gibt es bei Ihnen nicht? 

• Tragen Sie horizontal die groben wertschöpfenden Prozessbereiche auf, z.B. Marketing, Akquise / Vertrieb, Abschluss, Leistung / Bestandsverwaltung / Pflege, Austritt / Storno / Beendigung (je nach Branche halt unterschiedlich). 
• Platz für sekundäre Prozessbereiche wie Buchhaltung, Personalwesen etc. ist dann schon meist nicht mehr – die passen auch zur Not auf ein weiteres Blatt. 
• Unter jeden Prozessbereich können Sie die Systeme packen, die daran beteiligt sind.  Oder, um auf die Geschäftsprozesse zu kommen, die feineren Schritte wie „Angebot erstellen“, „Vertrag abschließen“, „Leistungsanspruch prüfen“. Das Blatt füllt sich in der Regel schnell...
• Hilfreich ist oft, die wesentlichen Prozessbeteiligten (als Rollen) in der Senkrechten zu notieren, in der ersten Spalte: dann können Sie die Prozesse schnell den Beteiligten zuordnen.

Tipp: elektronisch (PowerPoint, Visio, Zeichentools) geht das letztlich schneller als auf Papier.

Auf dieser Ebene müssen Sie vor allem herausfinden, an welchen Prozessen Ihr neues System beteiligt sein wird!

Use Case Übersicht

Die konkrete Beteiligung des Systems an den Prozessen betrachten wir dann als „Use Cases“ oder „Anwendungsfälle“. Die Grundidee ist sehr einfach: wer macht was mit dem System? Zunächst mal trägt man alle Akteure und Top-Level Use Cases in einem Diagramm zusammen. Auch wesentliche, fremde Systeme wie die Buchhaltung oder das Dokumentenarchiv sollten hier als Akteure auftauchen.

Diese Top-Level Use Cases bilden die oberste Ebene Ihrer funktionalen Gliederung. Verfeinern Sie diese Ebene durch Use Cases, für die Sie grob erfassen, was gemeint ist: „Einloggen: Benutzer kann sich einloggen mit Möglichkeit zum Password Reset“.

Meist kann man die Verfeinerungen in die Übersicht einbauen: mit einem UML-Tool können Sie z.B. farbige Bereiche einrichten, um das Lesen zu erleichtern. 

Geplante Komponenten

Was müssen Sie eigentlich programmieren, so im Groben? Anfangs fällt dies vielen Beteiligten schwer, weil sie geistig von „Anforderung“ auf „Lösung“ umschalten müssen.

Tipp: Beginnen Sie „außen“: wo sind die „Schnittstellen“ des Systems? Arbeiten Sie sich dann nach „innen“ vor:

• GUI und menschliche Interaktion: Hier finden Sie schnell GUI-Komponenten und meist auch gleich die darunter liegenden Logik-Komponenten.
• Schnittstellen von und zu anderen Systemen: Wie funktionieren die? Zum Einlesen von Dateien brauchen Sie beispielsweise mindestens eine Importkomponente – welche Komponente jedoch führt die fachliche Logik aus?

Aus diesen Überlegungen bestimmen Sie ziemlich schnell Aussagen zu Abhängigkeiten, Umfang und Kosten:

• Erstellen Sie eine Matrix aus Use Cases und Komponenten: im Kreuzungspunkt eine „1“, falls die Komponente im Use Case verwendet wird, sonst eine „0“.
• Denken Sie sehr intensiv nach über Komponenten, die keine oder wenige Einsen haben...
• Lassen Sie erfahrene Architekten oder Entwickler die Komponenten schätzen – in Projekttagen.
• Parallel dazu können Sie durch Komplexitätsfaktoren versuchen, den Aufwand für die Use Cases zu schätzen und mit Aufwandsklassen zu multiplizieren:

Einfach: 2 PT
Mittel: 5 PT
Komplex: 10 PT

• Der Trick: die Trennung von Klassifikation und Zahlen führt zu besseren Schätzungen!
• Zu guter Letzt vergleichen Sie die Schätzungen für Use Cases und Komponenten – und finden Sie heraus, warum es an welcher Stelle Unterschiede gibt.

Der Plan

Wenn Sie die ersten Hürden überwunden haben, müssen Sie natürlich eine Vorstellung über den Ablauf gewinnen – welche Komponenten / Use Cases etc. bauen Sie zuerst?

Wenn Sie agil planen, brauchen Sie nicht alles herunter zu brechen und zu verfeinern! Nur die wichtigen Teile – wenn Sie herausgefunden haben, welche das sind...