Ein Interessent meldet sich. Und meist möchte dieser schon am Anfang zuerst wissen, wie viel die Einführung der Software kosten wird. Telefonisch. Auf schnellstem Wege. Und natürlich nenne ich dann einen Betrag. Aus dem Bauch heraus. Und verweise dann auf den ersten Schritt meiner Projektplanung:

Schätzungen etablieren

In der CMMI-DEV 1.3 ist dieses spezifische Ziel mit “Schätzungen von Projektplanungsparametern werden etabliert und beibehalten” zusammengefasst und beinhaltet die folgenden Subpraktiken:

Umfang des Projekts abschätzen.
Schätzungen der Attribute von Arbeitsergebnissen und Aufgaben etablieren.
Projektphasen definieren.
Aufwand und Kosten schätzen.

Wichtig für mich als Unternehmer ist der Begriff des Etablierens. Das heißt die kontinuierliche Standardisierung und Anwendung, das Beibehalten, von Schätzungen. Die Dokumentation der Annahmen und der Schätzgrundlagen sind wichtig für die Stakeholder des Projektes. Und sichern mir und den späteren Anwendern der Software einen erfolgreichen Verlauf des Projektes.

Folgende Parameter – und auch Weitere – sind für meine erfolgreiche Projektplanung essentiell:

Planung (im Allgemeinen)
Organisation
Personalzuweisung
Leitung
Koordination
Berichterstattung
Budgetierung

Die Planung geht in Bezug auf die Schätzung etablieren direkt in die Organisation über. Und hier ist der zu erwartende Einsatz des Interessenten genauer zu betrachten. Nur wenn eine Integration von Mitarbeitern in das Software-Projekt zugesagt ist (Personalzuweisung), können sich Parameter zur Leitung und Koordination ergeben. Und dann auch über mögliche Berichterstattungen gesprochen werden.

Die Budgetierung hat einen besonderen Stellenwert. Mein persönliches konkretes Ziel der Schätzung ist ein monetäres Angebot zur schrittweisen Einführung der Software. Enthalten ist dann meist ein Projekt Plan mit Projektphasen und Meilensteinen. Gerne auch schon mit ersten Terminen.

In diesen ersten Gesprächen zur Schätzung etablieren werden die Stärken des Interessenten bestimmt. Das ist vielleicht auf dem ersten Blick etwas seltsam. Und doch notwendig. Mir ist es wichtig, dass sich meine Kunden ergänzen! Aktuell prüfe ich Möglichkeiten, die Kommunikation nicht nur zu mir zu stärken, sondern auch untereinander.

Auch in Bezug auf die permanente Reduktion meiner eigenen Unternehmer Aufgaben ist es wichtig, nur die für mich passenden Kunden zu bedienen. Der Übergang in die Wartbarkeit der Software wird schon in dieser frühen Phase von mir mit betrachtet.

Und so kann es sein, wenn gewisse Kriterien nicht erfüllt sind, dass ich einen Interessenten ablehne. Das hätte ich so früher nie und nimmer getan! Ganz sicherlich ist das ein Anzeichen für meine Reife als Unternehmer in den letzten Jahren meiner Selbstständigkeit. Irgendwie bin ich stolz drauf.

1) Umfang des Projektes abschätzen

In der CMMI-DEV 1.3 ist diese Subpraktik mit “Einen Projektstrukturplan auf oberster Ebene erstellen, um den Umfang des Projektes zu schätzen” zusammengefasst. Es geht hier konkret darum die ersten Schätzungen zu strukturieren. Und die handhabbaren Bestandteile zu erkennen. Hier mal eine am Produkt orientierte Struktur am Beispiel der meiner Software QuoMod:

Stammdaten
Dokumente
Arbeitsabläufe (Workflow)
Schnittstellen zu weiteren Produkten

Um den Umfang des Projektes abschätzen zu können, kann es hilfreich sein, sich die Gliederungsprinzipien eines Projektstrukturplans genauer anzuschauen. Vom Prinzip her ist es eine gute Mischung der orientierten Gliederungen nach:

Funktionen
Objekten
Zeit

Und natürlich gibt es schon Standard-Projektstrukturpläne. Bei meinem Schätzungen etablieren fange ich nicht bei 0 (=null) an. Planerische Arbeiten einsparen. Ja, das tue ich hier konsequent. Ich erinnere mich dann immer gerne an die in der CMMI-DEV häufig vorkommende Angabe von “historischen Daten”.

Ja, die dokumentierte Historie ist definitiv Gold wert. Und erleichtert mir hier mein Agieren als Unternehmer ungemein. Auch hier wieder ein Aspekt der permanenten Reduktion der eigenen Aufgaben: Effektivität trifft Effizienz.

Um dann das Angebot mit Meilensteinen und Terminen erstellen zu können, folgen:

Termin- und Ablaufplanung
Ressourceneinplanung
Kostenplanung
Risikoplanung

Schon jetzt sichere ich die Umsetzung ab: 1) Mache ich mir Gedanken zu möglichen Kennzahlensystemen. Und 2) Plane ich in verschiedenen Zeithorizonten. Meine Kunden werden in den nächsten Jahren begleitet. Den ersten Kunden meiner Selbstständigkeit begleite ich nun schon über 17 Jahre. Und bisher hat mich kein Kunde verlassen.

2) Schätzungen der Attribute von Arbeitsergebnissen und Aufgaben etablieren

In der CMMI-DEV 1.3 ist diese Subpraktik mit “Schätzungen der Attribute von Arbeitsergebnissen und Aufgaben etablieren und beibehalten” zusammengefasst. Das Beibehalten ist nur in der Zusammenfassung enthalten. Doch wenn ich genauer darüber nachdenke, ist es entscheidend für den Erfolg von Schätzungen etablieren. Kongruent, standhaft sein. Immer!

Es gibt viele Modelle zu Schätzungen; hier eine kleine Auswahl, die ich gerne für meine Argumentationen verwende:

Anzahl und Komplexität von Anforderungen
Anzahl und Komplexität von Schnittstellen
Anzahl der Funktionen
Anzahl der Seiten
Anzahl der Ein- und Ausgaben
Nähe zu Kunden, Endanwendern und Lieferanten

Und auch hier bin ich froh, dass mir meine “historischen Daten” sehr behilflich sind. Je nach Modell ist es mir möglich, aus dem Bauch heraus erste Schätzungen zu erstellen. Die ultimativ geeignete Methode zur Ermittlung der Attribute von Arbeitsergebnissen und Aufgaben gibt es nicht. Insbesondere weil der letzte Punkte der Auflistung menschlich ist.

Daher sind die ersten Gespräche mit einem Interessenten sehr wichtig und müssen gut reflektiert werden. Ich schaue mir die Mitarbeiter genau an, insbesondere deren Möglichkeiten der Integration ist das geplante Software-Projekt. Die Mitarbeiter sollten den Willen zur kontinuierlichen Weiterbildung und gewisse Basisfertigkeiten mitbringen. Damit die im Projekt immer wieder zu treffenden Entscheidungen zeitnah geschehen können. Auch, hier: Effektivität trifft Effizienz.

Arbeitsergebnisse variieren, aber im Allgemeinen sind es im Bereich der Schätzung:

Dokumente und Dateien

Aus diesen sind dann konkrete Rückschlüsse zur Funktionalität des Software-Produkts möglich; im Besonderen zur Angemessenheit und der Richtigkeit. Diese können dann jederzeit entsprechend aus verschiedenen Perspektiven argumentiert werden (siehe oben).

3) Projektphasen definieren

In der CMMI-DEV 1.3 ist diese Subpraktik mit “Projektphasen definieren, um den Umfang der Planung festzulegen” zusammengefasst.

Hier geschieht ein Sprung. Persönlich bin ich der Meinung, dass vorher das Verständnis für Projektphasen geschärft werden sollte. Im zweiten Absatz dieser Subpraktik befindet sich dann auch der Satz “Das Verstehen der Projektphasen ist … entscheidend”. Als Beispiel dienen die Projektphasen:

Konzeptuntersuchung
Entwicklung
Produktion
Betrieb
Entsorgung

Meine ersten Gespräche mit Interessenten kann als Projektphase Konzeptuntersuchung angesehen werden. Untersuchung trifft es ganz gut, denn:

Drum prüfe, wer sich ewig bindet, ob sich das Herz zum Herzen findet!
Friedrich Schiller Das Lied von der Glocke

In der Konzeptuntersuchung Projektphase ist es jederzeit möglich “Nein” zu sagen. Und das ist auch gut so. Meine K.O.-Kriterien und auch die K.O.-Kriterien meines Interessenten müssen betrachtet werden. Es gibt Gespräche, bei denen sogar diese Kriterien offen kommuniziert werden. Das erzeugt Nähe und auch Vertrauen. Das finde ich super!

Kurz noch einige Worte zu der Entsorgung Projektphase. Hier ist damit gemeint, dass meine Interessenten sich auch von vorherigen Produkten / Vorgehensweise verabschieden werden. Auch das muss besprochen werden. Der Abschied von Altem fällt den Anwendern unterschiedlich leicht und/oder schwer. Es ist sogar so, dass während der Erstellung der Software ehemalige Engpässe auftauchen werden und diese nun mit der neuen Software-Lösung entsorgt werden. Kontinuierliche Verbesserung in seiner reinsten Form. Und auch wieder hier: Effektivität trifft Effizienz.

Sobald dann das “Ja” gesagt ist, können dann die konkreten Schätzungen erfolgen. Und zwar basierend auf den Entwicklungsphasen:

Anforderungsanalyse
Entwurf
Herstellung
Integration
Verifizierung

Verifizierung – Nachweis, dass ein vermuteter oder behaupteter Sachverhalt wahr ist – erfolgt kontinuierlich. Warum? Weil meine normale Vorgehensweise in spiralförmigen Modellzyklen gemeinsam mit dem Kunden erfolgt. Es werden immer mal wieder gedankliche Prototypen erstellt, die dann in die Software-Lösung integriert werden.

Daher ist es notwendig, im permanenten Kundenkontakt zu stehen. Fragen dürfen jederzeit gestellt werden. Die Software-Lösung QuoMod wird gemeinsam entwickelt! Bei einem aktuellen Kunden läuft gerade ein Experiment: wöchentliche Sprechstunden übers Internet mit gegenseitigem Freigeben der Bildschirme und fester Agenda. Bisher ein sehr erfolgreiches Vorgehen.

Wie zu erwarten, die Arbeitsergebnisse dieser Subpraktik sind:

Projektphasen
Meilensteine

4) Aufwand und Kosten schätzen

In der CMMI-DEV 1.3 ist diese Subpraktik mit “Projektaufwand und -kosten für Arbeitsergebnisse und Aufgaben basierend auf Annahmen schätzen” zusammengefasst. Nun befinden wir uns schon in der finalen Subpraktik zum spezifischen Ziel Schätzungen etablieren. Und auch hier sind mir die historischen Daten vergangener Projekte eine große Hilfe, zum Beispiel:

Größe
Aktivitäten
und vielen weiteren Planungsparametern…

Das Angebot an meinen Interessenten kann erstellt werden. Und die persönlichen Erfahrungen werden in Überlegungen für die Aufstellung sinnvoller Schätzgrundlagen, Managementreserven und vertretbarem Ressourcenverbrauch überführt.

Zusätzlich – und das ist eine äußerst spannende Angelegenheit – können unternehmerische Wachstumsmodelle und Wachstumsprinzipien weiterentwickelt werden. Denn jede Erstellung eines Angebots ist die Manifestation von geplantem Wachstum. Da bin ich meinen Kunden äußerst dankbar.

Sobald das Angebot mit einer Aufstellung von Aufwand und Kosten vorliegt, ist klar: Die Umsetzung ist gesichert. Die Aufgaben sind klar definiert. Das Management weiß genau was, wann und wie zu tun ist. Die Kontrolle der Umsetzung ist definiert. Zu erkennen exemplarisch an den Modellen:

Projekt Struktur Plan
Anforderungen an Produkte und Produktbestandteile
Schätzungen der Größe von Arbeitsergebnissen, Aufgaben und vorherzusehenden Änderungen

und dem vorliegenden Angebot für meinen Interessenten.