Bild © Timo Klostermeier Pixelio.de

Videoanleitungen zu der Projektkostenschätzung

Finden Sie in den Unterseiten (in Englisch)

Kostenabschätzung der Systementwicklung 

Als System in dieser Definition besteht aus

  • Software
  • Hardware und
  • Mechanik

Die Problematik

Die Finanz und Ressourcenplanung für Projekte werden zu Beginn fast immer durch Geschäftsführung und das Controlling zusammengestrichen.

Das Problem bei der Ermittlung ist die schiere Menge an Faktoren. Zum Zeitpunkt des RFQ sind die Ressourcen nicht allokiert. Niemand hat wirklich Zeit diese Aufgabe erledigen. Die Kosten werden „gewürfelt“, insbesondere da man weiß, dass das Gremium die Kosten sowieso zusammenstreicht. 

Zu Beginn eines Projektes werden aber die Weichen für die Stressfaktoren im Projekt gestellt. Sind genügend oder zu viel Mitarbeiter und Finanzen vorhanden?

In einigen Branchen ist es Usus, dass Projekte in den „Task Force Modus“ gehen. Ressourcen, welche benötigt werden, werden zu Beginn des Projekts nicht genehmigt. Den Schätzungen wird nicht getraut.
Es kommt einem vor wie im Film: “Und täglich grüßt das Murmeltier“.

„Work once – Use many“

lesen Sie, wie Sie mit geringem Aufwand methodisch die Projektkosten einer Systementwicklung, basierend auf den Besonderheiten Ihrer Firma, bzw. Ihres Teams, sachlich begründet, ermitteln können.
Wenn Sie einmal etwas Aufwand hineinstecken (ca. 1 Tag), brauchen Sie danach nur noch wenig um verlässliche Zahlen für die Projekte zu bekommen..

Und das Wichtigste – die Zahlen sind belastbar.

Auf in den Ring zum Fight mit der Projektgremium, den Sie nun gewinnen können

Eine gute Methode

müsste in der Lage sein:

  • Schnell und einfach
    • Normenspezifische (Automobil, Luftfahrt, Medizin, Industrie.....)
    • Firmenspezifische
    • Projektspezifische
    • Methodenspezifische
    • und andere Besonderheiten zu erfassen
  • korrekt zu berücksichtigen und dann trotzdem
  • die Projektkosten genau vorherzusagen.

Einflussfaktoren für die Kosten der Systementwicklung

Bevor ich die Details der Methode beschreiben, zunächst Zahlen und Notwendigkeiten aus der Entwicklung.

Die Entwicklungsmethode

 (AGILE, SAFe©, V-Modell, RUP...) sorgt für Kosten Varianz.

Namecook veröffentlichte in 2013 eine Studie mit dem Titel „EVALUATING TEN SOFTWARE DEVELOPMENT METHODOLOGIES.“. Hier ein Auszug.

Vergleichbare Software Entwicklungen
Gesamt und Qualitätskosten

  1. Die Auswahl der (Software) Entwicklungsmethode hat mehr mit dem Beitritt zu einem „Kult“, als mit einer technischen Entscheidung zu tun[1].
    (Ist also Meinungs- und nicht sachgetrieben.  Anmerkung d. Ü.)
  2. Insgesamt erreichen die Agile-Familie und die Methoden, die die Geschwindigkeit hervorheben, ihr Ziel. Sie sind ziemlich schnell.
  3. Die qualitätsbewusstenMethoden wie TSP, RUP und CMMI 5 erreichen ebenfalls ihre Ziele
    Sie liefern nur sehr wenige Mängel.
  4. Keine einzige Methode scheint ein universelles Allheilmittel zu sein, das bei jeder Größe und Art von Softwareanwendung erfolgreich sein kann.

[1] Originaltext:
In general selecting a software development methodology has more in common with joining a cult than it does with making a technical decision.

Schwierige Voraussetzungen

Kostet es nun 1 Mio. oder doch eher 4 Mio.?

und das Alles bei gleichem Arbeitsumfang?

Hier sieht man das Problem, mit dem der Projektleiter konfrontiert ist: Er muss erklären warum er „mehr braucht“.

Die Kriterien, welche typischerweise bei der Vergabe eines Auftrages im Raum stehen sind Geld und Zeit.

Software, Hardware und Mechanik

In der Systementwicklung gibt es, zusätzlich zu der obigen Varianz in der reinen Softwareentwicklung, noch weitere Einflussfaktoren, welche das Projekt verteuern und die Varianz erhöhen können.

Das dem Management gegenüber dazustellen,  scheiint unmöglich. Der typische Stress zu Beginn des Projekts wird eingeleitet mit

„Das ist zu teuer, das dauert zu lange.“

Der Projektleiter kommt sich vor wie eine Schießbudenfigur. Man traut Ihm Alles zu, nur bei den Ressourcen und Finanzen, weiß man alles besser.

Dieser „Fight“ mit dem Management, der allein aufgrund der Methode – es wurde Geschätzt – und damit ist es nicht zuverlässig, gegen das Controlling und Management verloren wird, bestimmt zum Projektstart die Konsequenz:

  • Entweder: Ab Mitte des Projektes „nachkarten“.
    oder noch schlimmer:
  • Task Force Modus“.
    Beides kann vermieden werden!

Gemeinsames Verstehen basierend auf Fakten

Erfolgreich durchgeführte Projekte innerhalb der Firma als Vergleich zu nehmen ist ein zielführender Ansatz. Zumindest sind da die Besonderheiten der Firma berücksichtigt.

Ob das Projekt eine Neuentwicklung oder ein „carry over“ ist, erhöht die Kosten- und Ressourcenvarianz.

Auch das wird in der Methode erfasst.

Der normative Ansatz

Normen sind kondensiertes Wissen. Die Nutzung dieses Wissens (Bsp: ISO 16326[1], SPICE®[2] etc.) sollte ein Zugewinn für die Firma sein. Um dahin zu kommen ist ein wenig Arbeit notwendig. Es gibt immer wieder Task Forces. Ein Projekt dass in Time und in Budget – oder auch nur in der Nähe war – habe ich bisher nicht kennengelernt.
Zunächst muss man verstehen: Alle Projekte, welche Normen genügen müssen (Automobil, Eisenbahn, Industrie, Luftfahrt, Medizin ...), verlangen Prozesse[3] und Arbeitsprodukte.
Diese Arbeitsprodukte müssen in definierter Qualität erstellt, den Prozessen muss gefolgt werden!

Diese Methode basiert auf dem prozessorientierten Ansatz.

Jeglicher Einsatz von Werkzeugen sollte dem Ansatz „Prozess, Methode, Tool folgen“.

Daher führe ich Sie nun durch die Prozesse und den Stellparametern, welche Prozessspezifisch vorhanden sind.


[1] ISO 16326: Systems and software engineering -- Life cycle processes -- Project management

[2] ISO 15504 / 33002 (SPICE)

[3] Die ISO 9001 verlangt auch ein prozessorientiertes Vorgehen, ist aber lange nicht so strikt wie in den Entwicklungsnormen

BILD: V-Modell nach ASPICE®.
Systementwicklung folgt Prozessen, wie im Bild.
Dabei bedeutet: SYS – Systementwicklung
[(Beinhaltet Kunden- und (1), Systemanforderungen(2), Systemarchitektur(3),  Integration(4), Qualifikation(5)]
In den Domänen
(HWE= Hardware Engineering, SWE=Software Engineering, MEE= Mechanik Engineering)
[(Mit Anforderungen(1), Architektur(2),  Detail Design(3) Modul Tests(4), Integration(5), Qualifikation(6)]
Sowie: MAN.3: Projekt-, ACQ.4: Lieferanten-,  SUP.1: Qualitäts-, SUP.8: Konfigurations-, SUP.9: Problem- und SUP.10 Änderungsmanagement.

Je nach normativem Umfeld und Entwicklungsumfang werden bestimmte Prozesse nicht durchgeführt oder es kommen noch weitere Prozesse hinzu.
Eine Systementwicklung im normativen Umfeld (Automotive) beinhaltet mehr als 20 Prozesse und mehr als 100 Arbeitsprodukte. In der Luftfahrt können es bei einemähnlichen Produkt, bedingt durch normative Vorgaben,  mehr als 40 Prozesse und mehr als 250 Arbeitsprodukte werden.

Methodisches Vorgehen

Basierend auf den obige Ausführungen wird in der Methode für jeden Prozess

  • die Prozessspezifischen zugehörigen Arbeitsprodukte erfasst
    • der Aufwand zur Erstellung der Arbeitsprodukte
    • der Aufwand zur Pflegeder Arbeitsprodukte
  • über den gesamten Lebenszyklus hinweg.

Zusätzlich werden die Abhängigkeiten der Arbeitsprodukte untereinander zu betrachten. Zum Beispiel:

  • Jede übergeordnete Anforderung benötigt mindestens eine (1) Anforderung auf unterer Ebene.
  • Jede Anforderung benötigt mindestens einen (1) Test.
  • Wie ist die Wiederverwendbarkeit bestehender Artefakte aus vorhergehenden Entwicklungen?
  • Gestehung der Qualitätsdokumente.
    • Welche Dokumente?
    • Wie lange dauert das?
  • Investments und Ausgaben (Capex/Opex) müssen erfasst und bewertet werden
  • Prototypenkosten und Prototypenmengen müssen über den Entwicklungszyklus hinweg betrachtet werden

Bezugsgrundlage der Kalkulation

Das Einzige was zu Beginn einer Entwicklung vorhanden ist/sein sollte, sind die Anforderungen des Kunden, sowie (hoffentlich) die Erfahrungen aus vergangenen Projekten.

D.h: Das einzige Bezugssystem, welches man verwenden kann sind die Anforderungen und die bisherige Erfahrung.

Excel

Excel wird hier als Tool verwendet, da es weltweit im Einsatz ist. Langfristig sollte man unternehmensspezifisch mit Datenbank basierten Lösungen arbeiten um die Stellparameter automatisiert zu erfassen und einzuspielen.
Die hier verwendete Datei basiert auf der Automotive SPICE©. Eine Anpassung an andere normative Umfelder ist relativ einfach.

Das Ergebnis

Das Management möchte ein sinnvolle, sachlogische, faktenbasierte Zusammenfassung um eine Entscheidung treffen zu können. Gleichzeitig müssen Details vorhanden sein um Nachfragen beantworten zu können.

Klar gegliedert in System, Domänen (SW, HW, ME ....), Qualität und Management

Management Summary

Das Deckblatt zeigt den benötigten Aufwand in Zeit und Geld.

Management Summary

Natürlich sind auf dieser Seite noch mehr Details, welche über die Gruppier Funktion eingeblendet werden können.
Auf der Hauptseite können die Stundensätze für die Mitarbeiter in den Domänen eingetragen werden.
Details zu den Ausgaben, Arbeits- und Qualitätskosten werden angezeigt.

Details zu den Ausgaben, Arbeits- und Qualitätskosten werden angezeigt.

Wie kommt man zu den Daten/Zahlen?

Das Management wird völlig zurecht jede Zahl hinterfragen. Damit die Ergebnisse, welche Sie präsentieren stimmig und belegbar sind, kommt die Arbeit, die einmal getan werden muss.

Für jeden Prozess[1], mit Ausnahme Lieferantenmanagement, ist ein eigenes Tabellenblatt vorhanden, Dort werden die Prozessspezifischen Daten erfasst. Im Folgenden führe ich Sie einmal durch den methodischen Ansatz.

Die Domänen (HWE, SWE, MEE) sind zusammengefasst worden. Die Unterschiede in den Entwicklungen werden auf der Systemebene erfasst.
Ein Auftrennen der Domänen, um genauer zu werden ist mit ein wenig Aufwand jederzeit möglich. Beginnen wir mit dem Übergeordneten Prozess.

 


[1]16 Prozesse - 6 (Domänen) + 5 (System), Projektmanagement und 4 Qualitätsprozesse

Das Projektmanagement MAN.3

Grunddaten zum Projekt

Sind nur die „Basics“. 

Name, Start und Ende, Arbeitszeiten.

Diese Daten spielen bei der Ermittlung der notwendigen Anzahl von Mitarbeitern im Projekt eine Rolle

Anforderungen an das Projektmanagement

Auch das Projektmanagement muss Arbeitsprodukte liefern, welche Teil der Entwicklung sind. Die Planung, die Zahlen, den Status etc.

Diese Artefakte werden in der Tabellenseite in einer Gruppe „Things that have to be delivered“ zusammengefasst.
Die Namen der Arbeitsprodukte sind (ASPICE) Norm entnommen. 
Details/Qualitätskriterien welche festlegen, was der genaue Inhalt der Arbeitsprodukte ist, finden Sie Beispielhaft ab Seite 96 in der kostenfrei verfügbaren Norm.
Die Arbeitslast – also die Zeit selbst - wird beim Projektmanagement unterteilt in

  • Erstellungszeit welche für das Arbeitsprodukt benötigt wird, sowie
  • Pflege der Daten.
    • „Wann“ muss gepflegt werden (täglich, wöchentlich, monatlich, 3 monatlich...)
    • „Wie oft“ muss in diesem „Wann“ gepflegt werden (1 x / Einheit oder 3 x oder ???) und
    • „wie lange dauert die Pflege“

Dabei wird diese Last wird dabei pro Arbeitsprodukt erfasst. Der Gesamtaufwand über den Lebenszyklus wird berechnet. Natürlich können sie Interne Artefakte zufügen.

Damit sind alle in Bezug auf das Projektmanagement notwendigen Daten erfasst.

Hier sind es IHRE Zahlen! – Wie lange brauchen Sie?

Projektphasenplanung – Sample Planning

Die Lastverteilung über Zeit macht immer wieder die Frage – wo sind meine Ressourcen?

Das Ideal einer gleichmäßigen Lastverteilung ... ist ein Ideal.

Jede Branche hat eigene Projektphasen Bezeichnungen.
Im Automobilbereich werden die Projektphasen mit A, B, C, D benannt. Ändern Sie die Namen wie es bei Ihnen üblich ist.

Wenn Sie in den Ausschreibungsunterlagen den erwarteten Funktionshub über die Musterphasen kennen, können Sie hier die Lastverteilung eintragen. Gegebenenfalls nehmen Sie auch einfach das was bei Ihnen typisch ist. Die genauen Daten sind jedoch zu Beginn oftmals nicht verfügbar, ich habe meine Erfahrungswerte da eingestellt.

Legen Sie fest, wie die Verteilung der Anforderungen über die Projektphasen geplant ist und ob es sich um interne oder Kundenphasen handelt. Mit dieser Festlegung, typischerweise abgeleitet aus den Anforderungen des Kunden über die zu liefernde Funktionalität, wird dann die phasenspezifische Arbeitslast in den Prozessen berechnet. Die Prototypenkosten, welche auf einem separaten Blatt bearbeitet werden, werden Ihnen (sofern dort Daten vorhanden sind) eingeblendet.

Qualität – Überprüfung in jedem Prozess

In jedem Prozess müssen Arbeitsprodukte überprüft werden (Review). Sind die vorgeschriebenen Produkte erstellt, inhaltlich und formal korrekt etc.? Jedes Tabellenblatt, welches sich auf Entwicklungsprozesse bezieht, also auch hier im Projektmanagement hat einen Bereich Qualität.
Die Arbeitsprodukte, welche gemäß Norm geliefert werden müssen, sind dort aufgeführt. Hier können Sie eigene Arbeitsprodukte zufügen, bzw. festlegen ob Sie diesen Review der Arbeitsprodukte brauchen oder nicht. Entsprechend wird die „Last“ entfernt.

Für jedes Arbeitsprodukt wird festgelegt, wie viele dieser Arbeitsprodukte / Projektphase vorhanden sein werden.
Das geschieht automatisch anhand von Vorgaben, die Sie in den jeweiligen Prozessen festlegen. Nur im Projektmanagement wird die Menge Ihnen geschätzt.
Die Zeitdauer um einen Review durchzuführen wird im Prozess Qualitätsmanagement (SUP.1) festgelegt, die Gesamtzeit wird dann als
Anzahl der Arbeitsprodukte * Zeitdauer * teilnehmenden Personen
automatisch berechnet.

Die weitere Beschreibung

wird erstellt, aber da es alles kostenlos ist .... 
Holen sie sich einfach die Excel Datei

Projektkosten Abschätzung... wenn man keine Function Points hat

Kleines Video zur Benutzung des Excel Sheets.

Wie schätze ich Projektkosten, wenn ich keine Function Points habe?
Wenn ich nur auf Systemebene eine Abschätzung von SW, HW und Mechanik geben soll

Das Video "How to"

Kostenfrei

Fragen Sie uns nach diesem Tool. Senden sie uns eine Mail - wir übersenden Ihnen die Excel Datei