Kurs:Projektmanagement/Lernskript

Definition: Projekt

DEFINITION: Projekt “[...] ein Vorhaben, das im wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z. B.

• Zielvorgabe
• zeitliche, finanzielle, personelle und andere Begrenzungen
• Abgrenzung gegenüber anderen Vorhaben
• projektspezifische Organisation” [DIN 69901]

Definitorische Projektmerkmale

• Zielvorgabe
• Außergewöhnlichkeit der Aufgabe (Einmaligkeit, zeitliche Begrenzungen)
• Ressourcenbegrenzung (z.B. Budgetvorgaben, Mitarbeiteranzahl)
• projektspezifische Organisation (Koordination von Mitarbeitern verschiedener Fachbereiche)

Prägende Merkmale

• Interdisziplinarität
• Bedeutung (zusätzliche Ressourcen notwendig, Dringlichkeit)
• Risiko
• Schwierigkeitsgrad
• Nationalität / Internationalität

DEFINITION: Projektmanagement

“[...] die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projektes” [DIN 69901]

• Führungsaufgaben  Zielsetzung
• Zieleinhaltung
• Entscheidung
• Führungsorganisation
• Projektorganisation
• Projektabwicklung
• Führungstechniken
• Motivationstechnik
• Besprechungstechnik
• Präsentationstechnik
• Entscheidungsfindungstechnik
• Führungsmittel
• Projektstruktur-Planungssysteme
• Termin-/Kapazitäts-/Kosten-/Planungs- und Steuerungssysteme

Vorgehensprinzipien

Was sind die Vorgehensprinzipien beim Projektmanagement ?

Vorgehensprinzipien

• „Vom Groben zum Detail”
• „Prinzip der Variantenbildung”
• „Prinzip der Phasengliederung”
• „Problemlösungszyklus”

Ziele: Projektmanagement

Übergeordnetes Ziel:

• Erfolgreiche Projektabwicklung, d.h.:

mit den vorgesehenen Mitteln (Personal, Kosten, Ressourcen)

innerhalb der Termine

unter Berücksichtigung der Rahmenbedingungen

mit Resultaten der geforderten Qualität

Untergeordnete Ziele:

• Risiken minimieren
• positiver Eindruck auf den Kunden / Markt
• Aneignung von Kenntnissen
• Transparenz des Projektablaufs

Projektarten

Welche Projektarten gibt es ?

Arten von Projekten

• Routineprojekte: Vorhaben, die durch einen hohen Standardisierungsgrad gekennzeichnet sind und einfach abgewickelt werden können (z. B. Ersatzinvestitionen)
• Komplexe Standardprojekte: klare Aufgabenstellung und formalisierte Methoden können bei der Realisierung angewandt werden (z. B. Informatikprojekte)
• Potentialprojekte: offene Fragestellung und geringes Risiko (z. B. Projektstudien= Vorhaben, die grundsätzliche Möglichkeiten abklären)
• Pionierprojekte: folgenreiche Eingriffe in die Organisation; für das Unternehmen risikoreich / bedrohlich. Arbeitsaufwand lässt sich aufgrund der Neuartigkeit sehr schwer abschätzen

(z. B. Neuorganisation von Geschäftsprozessen)

Charakteristika von IT-Projekten

Was charakterisiert IT-Projekte ?

• Temporäre Organisationsformen zur Entwicklung von betrieblichen Informationssystemen/

-Technologien und/oder organisatorischen Lösungen

• komplexe Arbeit, aber meist vorhersehbar
• Arbeitsprozess ist häufig in einem gewissen Rahmen standardisiert
• Realisierung erfolgt nach einem Vorgehensmodell
• System ist kompliziert und teilweise automatisiert (CASE-Tools)
• Aufgabenumwelt ist nicht immer dynamisch, sondern kann oft als weitgehend stabil angesehen

werden

• Projektteams bestehen aus professionellen Mitarbeitern verschiedener Disziplinen und

Geschäftsfelder

• hohe horizontale Aufgabenspezialisierung auf Grundlage formaler Ausbildung

Probleme und Risiken im Projektmanagement

• Ziele sind nicht immer genau vorgegeben oder werden geändert
• Termin- und Kostenüberschreitungen oder Funktions- und Qualitätsmängel
• Probleme bei der Aufwands- und Zeitabschätzung
• verschleppte Entscheidungsfindung
• Termindruck durch beschränkte Kapazitäten
• Interdependenzen zwischen Projekten/Bereichen - Kooperationsprobleme
• Ist-Situation wird ungenügend analysiert
• Lieblingslösung statt objektiver Alternativensuche
• Projektverantwortlichkeiten sind nicht vollständig und abgestimmt
• Probleme werden teilweise ignoriert und ausgesessen
• Risiken werden unterschätzt und als Schicksal hingenommen
• Improvisation steht höher im Kurs als systematische Organisation
• Fehler aus alten Projekten werden wiederholt

Funktionen und Aufgaben des Projektmanagements

Planung und Kommunikation

• Abgrenzung des Systems/Projektes („Was ist zu machen?“)
• Bildung von Arbeitspaketen („Wie wird das Projekt zerlegt?“)
• Zuordnung und Anweisung von Aufgaben („Wer arbeitet mit wem?“)
• Festlegung zeitlicher Abfolgen („Wann ist was fertig?“)
• Ermittlung des Ressourcenbedarfs („Wie viele Ressourcen für was?“)
• Planung der Kosten und Finanzen („Wieviel kostet was?“; „Woher kommt das Geld?“)

Schaffen und Wahren geeigneter Rahmenbedingungen

• Implementierung der Projektorganisation („Wer macht was?“)
• Sammeln und Auswerten relevanter Informationen („Projektfortschritt?“; „Budget eingehalten?“; „Ziele / Qualität erreicht?“)
• Definition des Projektinformations- und Dokumentationssystems (Berichterstattung)
• Frühes Erkennen und Neutralisieren unerwarteter Schwierigkeiten
• Schutz des Projektes vor der Umgebung
• Motivation und Kontrolle der Mitarbeiter

Projektziel

Was ist ein Projektziel ?

Projektziel

“[...] ein nachzuweisendes Ergebnis und vorgegebene Realisierungs- bedingungen der Gesamtaufgabe eines Projektes” [DIN 69900]

• entsteht aus Bedarf, Zwängen, Wünschen, Ideen etc.
• beschreibt, wie das Projektergebnis genau auszusehen hat (Projektanforderung)
• hat Bedingungen, die bei Erstellung zu berücksichtigen sind (Projektumfeld)
• Zielbeschreibung (Projektanforderung) muss eindeutig (operationalisierbar)

hinsichtlich Inhalt (Ergebnis), Zeitvorgabe (Termin) und Ausmaß (Kosten) sein.

• Berücksichtigung der Rangfolge innerhalb der voneinander abhängigen Projektziele und Beschreibung, in welchem Ausmaß diese über- bzw. unterschritten werden dürfen
• Zielfindung mittels z. B. Brainstorming oder systematischer Strukturierung

(Morphologie)

Meilenstein

Was ist ein Meilenstein ?

Meilenstein

• Abschlusspunkt einer Phase
• definiertes termingebundenes Sachergebnis
• wesentliches Schlüsselereignis für die Planung und Überwachung eines Projektes
• dient der Orientierung über den Projektablauf
• wesentlicher Bestandteil der Terminfortschrittskontrolle
• schärft das Terminbewusstsein

Teilaufgabe

Grenzen Sie Meilenstein und Teilaufgabe voneinander ab ? Teilaufgabe (TA)

• Teil eines Projektes; kann im Projektstrukturplan weiter aufgegliedert werden

Arbeitspacket

Arbeitspaket (AP)

• Teil eines Projektes, der im Projektstrukturplan nicht weiter aufgegliedert wird
• In sich geschlossenes, mit klaren Abgrenzungen und Schnittstellen zu anderen AP, damit es zur Abarbeitung an eine Organisationseinheit delegiert werden kann

Projektstrukturplan

• vollständige, hierarchische Strukturierung des Projektes in Teilprojekte (TP), Teilaufgaben (TA) und Arbeitspakete (AP) für die einzelnen Entwicklungsphasen
• Fundament für die gesamte Projektplanung und -kontrolle (Kosten, Termine, Ressourcen, Leistungsmerkmale) und der Darstellung in Netzplänen
• Detaillierungsgrad ist abhängig von der Projektkomplexität, der Definition der TP/TA/AP und der Überschaubarkeit des Projektablaufs
• Strukturierungsformen (Def. der Aufgabenpakete nach):
• objektorientiert (technischer Struktur des zu entwickelnden Objekts)
• funktionsorientiert (Entwicklungsfunktionen [Konstruktion, Musterbau etc.])
• ablauforieniert (Entwicklungsprozess)
• Ziel ist das Erkennen von Unklarheiten der Zieldefinition, Schaffen von Transparenz, Eingrenzung von Risiken, Erkennen von Schwerpunktaufgaben, Zuordnung der AP zu Aufgabenträgern, effiziente Koordination

Projektorganisation

Faktoren: Faktoren zur Wahl der geeigneten Organisationsform

• Vorhandene Organisationsstruktur
• Größe und Dauer des Projektes
• Eindeutigkeit der Aufgabenzerlegbarkeit
• Ähnlichkeit mit anderen Entwicklungsaktivitäten
• Geschäftspolitische Bedeutung des Projektes
• Grad der interdisziplinären Zusammenarbeit
• Risiko (hinsichtlich zu erreichender Ziele, Qualitäten, Kosten etc.)
• Ressourcenverfügbarkeit
• Firmeninterne Erfahrungen im Projektmanagement
• Anzahl der Projekte im Unternehmen

Task Force

• selbständige, speziell dafür eingerichtete Organisationseinheit, mit mehreren Stellen
• eindeutig abgegrenzte Projektaufgabe
• zielgerichteter Personaleinsatz
• Projektleiter ist verantwortlicher Leiter der Organisationseinheit
• starke Kompetenzausstattung des PL

(Weisungs-/Entscheidungsbefugnis)

• Starke Identifikation der Projektmitarbeiter mit dem Projekt
• Anwendung bei umfangreichen / langfristigen Projekten (Vollzeit-Einsatz)

Nachteile

• Freistellung und Wiedereingliederung der Mitarbeiter in die bestehende Organisationsstruktur
• evtl. werden von der Linie nicht die qualifiziertesten Mitarbeiter für die temporäre Tätigkeit abgeordnet
• Gefahr von Parallelentwicklungen zwischen Projekt und Linie

Matrix - Projektorganisation

• Zusammenarbeit mehrerer Linienstellen und/oder der temporärer Stellen; mehrerer Teilprojekte
• Projektgruppe bestimmt, WAS und WANN etwas zu tun ist, Fachbereiche legen fest, WIE es getan wird, WER es durchführt, WO und WOMIT
• PL ist fachlich / disziplinarisch der Abteilung unterstellt. Projektmitarbeiter verbleiben fachlich / disziplinarisch in ihren Fachbereichen und berichten an den PL

Es besteht Verantwortungsteilung

• PL hat Verantwortung für die Planung / Überwachung des Projektes
• Fachbereich hat Verantwortung für die Erreichung der Ziele

Nachteil:

• Kompetenzüberschneidungen
• Zielkonflikte zwischen Projektaufgabe und Fachbereichsaufgaben
• hohe Anforderungen an Kommunikation und Kooperation

Stabs - Projektorganisation

• Projektmanagement durch Koordination
• Projektleiter hat gegenüber den Linienvorgesetzten keine Weisungsbefugnis, sondern ausschließlich Informations-, Beratungs- und Planungsbefugnisse
• Anwendung nur bei wenig komplexen / risikobehafteten Projekten
• Bedarf keiner organisatorischen Änderung der Linie

Nachteile

• Konfliktpotential durch die Trennung von Entscheidungsvorbereitung und Entscheidungsdurchsetzung
• fehlendes Verantwortungsgefühl für das Projekt

(Abteilungsegoismus)

Aufbauorganisation

Welche Aufgabenträger existieren in der Projektorganisation ?

• Auftraggeber
• EDV/Fachausschuss
• Lenkungsausschuss / Steuerungsgremium
• Projektleiter

Wer ist der Projektauftraggeber ?

Auftraggeber

• Definition von Projektziel/-aufgabe/

Rahmenbedingungen

• Erstellung des Pflichtenhefts
• Festlegung max. Kosten
• Festlegung von Terminvorgaben
• Erstellung von Angebotsbedingungen/

Bewertungskriterien

• Auswahl Projektleiter (Verhandlung mit dem Auftragnehmer)
• Produktabnahme

Welche Funktionen und Verantwortlichkeiten haben die Aufgabenträger ?

Fach-/EDV-Ausschuss

• Beratung / Information der Projektgruppe
• Ergänzung des Fachwissens
• Verbreitung der Ergebnisse im Fachbereich
• Sicherstellung der fachlichen Anforderungen

Auftraggeber

• Definition von Projektziel/-aufgabe/

Rahmenbedingungen

• Erstellung des Pflichtenhefts
• Festlegung max. Kosten
• Festlegung von Terminvorgaben
• Erstellung von Angebotsbedingungen/

Bewertungskriterien

• Auswahl Projektleiter (Verhandlung mit dem Auftragnehmer)
• Produktabnahme

Lenkungsausschuss / Steuerungsgremium

• Kontrolle / Genehmigung der Projektplanung
• Prüfung / Genehmigung der erarbeiteten Phasenergebnisse
• Prüfung / Genehmigung der Projektstatusberichte
• Projektübergreifende Entscheidungen treffen, die die Kompetenz des Projektleiters übersteigen
• Entscheidungen über Änderungsanträge treffen
• Festlegung und Beauftragung von Mitgliedern der Fach-/EDV-Ausschusses
• Unterstützung und Beratung des Projektleiters

Projektleiter

• Überprüfung der Realisierbarkeit der Projektziele und deren Umsetzungsplanung
• Festlegung der Aufbau- und Ablauforganisation des Projektes
• Ressourcenbeschaffung und deren Delegation bzw. Koordination
• Festlegung der Projektaktivitäten / Projektstrukturplanung / Dokumentationsform
• Erstellung der Durchführungsplanung (zeitlich, personell, kostenmäßig)
• Bestimmung / Überwachung von Maßnahmen zur Zielerreichung (qualitativ)
• Analyse von Abweichungen und Steuerung von Gegenmaßnahmen
• Planung der Sitzungen des Projektsteuerungsgremiums
• Berichterstattung gegenüber den Gremien
• Erstellung von Entscheidungsvorlagen und Änderungsanträgen
• Planung und Durchführungen von Präsentationen zum Projekt
• Vertretung des Projektes nach außen
• Planung und Überwachung der Projektnachbearbeitung
• Erstellung des Projektabschlussberichts zur Ergebnissicherung

Wie und von wem soll die Projektmanagement-Aufgabe wahrgenommen werden ?

Projektleiter

• Überprüfung der Realisierbarkeit der Projektziele und deren Umsetzungsplanung
• Festlegung der Aufbau- und Ablauforganisation des Projektes
• Ressourcenbeschaffung und deren Delegation bzw. Koordination
• Festlegung der Projektaktivitäten / Projektstrukturplanung / Dokumentationsform
• Erstellung der Durchführungsplanung (zeitlich, personell, kostenmäßig)
• Bestimmung / Überwachung von Maßnahmen zur Zielerreichung (qualitativ)
• Analyse von Abweichungen und Steuerung von Gegenmaßnahmen
• Planung der Sitzungen des Projektsteuerungsgremiums
• Berichterstattung gegenüber den Gremien
• Erstellung von Entscheidungsvorlagen und Änderungsanträgen
• Planung und Durchführungen von Präsentationen zum Projekt
• Vertretung des Projektes nach außen
• Planung und Überwachung der Projektnachbearbeitung
• Erstellung des Projektabschlussberichts zur Ergebnissicherung

Welche Aufgaben sollen von der Projektgruppe erfüllt werden ? Welche Entscheidungs- und Kommunikationswege existieren ?

Projektplan

Systematische Informationsgewinnung über den zukünftigen Ablauf des Projektes und die gedankliche Vorwegnahme des notwendigen Handelns im Projekt

Gegenstand ist die:

• Strukturplanung („Was wird geliefert?“, „Welche zusätzlichen Ergebnisse?“, „Welche Tätigkeiten?“)
• Ablaufplanung („In welcher Reihenfolge?“)
• Terminplanung („Wann?“)
• Ressourcen-/Einsatzmittelplanung („Womit?“)
• Kostenplanung („Mit welchem Aufwand?“)

Projektstrukturplan

• Produktstrukturplan zur technischen Strukturierung des geplanten

Produkts bzw. des Systems

• Projektstrukturplans zur termin- und aufwandsgerechten

Projektabwicklung

• Kontenstrukturierung für die kostengerechte Projektabwicklung
• Ziel ist es, einen Überblick über das Projekt zu schaffen,

Zusammenhänge aufzudecken und Schnittstellen zu definieren

Vorgehensweisen:

• deduktiv (Ermittlung der Elemente der Strukurpläne durch Top-Down-Analyse)
• induktiv (kreative Sammlung aller denkbaren Elemente der Pläne)

Terminplanung

Ermittlung der

• Anfangs- bzw. Endtermine
• der Meilensteine
• der benötigten Dauer der Vorgänge und deren Anordnungsbeziehungen zueinander
• Pufferzeiten und kritischer Wege

Berechnung der Terminsituation

• vorwärts (frühest möglicher Anfangstermin)
• rückwärts (spätest erlaubter Anfangstermin)

Methoden der Aufwandsschätzung

• algorithmische Methoden (formaler Zusammenhang zwischen meßbaren Ergebnisgrößen z.B. Anzahl Konstruktionszeichnungen, Lines of Code)
• Vergleichsmethoden (Erfahrungsdaten aus abgeschlossenen Projekten)
• Kennzahlenmethoden (systematisches Sammeln projektspezifischer Meßdaten vergangener Vorhaben z.B. Testzeit je Anweisungszeile)

Ablaufplanung

• Einzelne Strukturplan-Elemente (Teilprojekte, Teilaufgaben und Arbeitspakete) werden in eine logische Reihenfolge der Abarbeitung gebracht
• Darstellung mittels der Netzplantechnik, Balkenpläne und Terminlisten, um abhängige Vorgänge/Ergebnisse/ Anordnungsbeziehungen darzustellen
• Ziel ist es, eine bestmögliche Reihenfolge für die Durchführung der einzelnen Tätigkeiten zu finden
• Die Termin-/Ablaufplanung bildet die Grundlage für die Projektkontrolle. Abweichungen gegenüber dem gültigen Plan lassen sich erkennen und Gegenmaßnahmen einleiten

Ressourcen/Einsatzmittelplanung

• Darstellung als Belastungsdiagramm der voraussichtlichen Auslastung der Betriebsmittel (Personal, Sachmittel) bzw. einzelner Organisationseinheiten
• gegebenenfalls auftretende Engpässe erkennen
• Engpässe durch entsprechende Gegenmaßnahmen zu beseitigen
• Verschiebung von „nicht-kritischen“ Vorgängen
• Personalaufstockung
• Personalverschiebung
• Fremdvergabe
• Verschiebung des Endtermin
• Darstellung mittels Balken-/Auslastungsdiagramm bzw. Personaleinsatzmatrix

Kostenplanung

• Ermittlung der benötigten Einsatzmittel je Vorgang und des

Gesamt-Einsatzmittelbedarfs

Betrachtungspunkte:

• was? -> Kostenelement
• wo? -> Kostenverursacher
• wofür? -> Projektaufgabe
• woher? -> Kostenherkunft
• wohin? -> Kostenempfänger
• wie? -> Tätigkeitsart
• wann? -> Projektphase
• Kalkulationabschnitte

Parametrische Methoden

• Basiskonzept
• Multiplikator-Methode
• CER-Technik
• WOLVERTON-Methode
• PRICE-Modelle
• COCOMO-Methode
• Function/Object-Point-Methode

Analogie-Methoden • Basiskonzept • Fallbasiertes Schließen

• bei Selbstkostenerstattungspreisen mit Prämienaufschlag (CPIF)
  • sind detaillierte, aber aufwändige Kostenschätz-Methoden
  • aus der Sicht des Auftragnehmers sehr wichtig
  • weil die spätere Prämie erheblich von der Kostenschätzung abhängt

• bei Selbstkostenerstattungspreisen mit Festgewinn (CPFF)
  • können relativ grobe Kostenschätz-Methoden eingesetzt werden,
  • weil der Festgewinn vom Schätzergebnis unabhängig ist

Netzpläne

• Hilfsmittel zum Analysieren, Beschreiben, Planen, Kontrollieren und

Steuern von Projektabläufen

• Vollständige, konsistente, grafische Darstellung des Projektablaufs,

die die logische und zeitliche Aufeinanderfolge von Vorgängen bzw. Ereignissen veranschaulicht

Netzplanmethoden:

• ereignisorientierte (Knoten=Ereignisse, Kanten=Tätigkeiten) z.B. PERT
• vorgangspfeilorientierte (Knoten=Vorgänge, Kanten=Tätigkeiten) z.B. CPM

slide-show CPM

• vorgangsknotenorientierte (Knoten=Vorgänge, Kanten bestimmen Anordnungsbeziehung) z.B. MPM
• Vor-/Mit-/Nachkalkulation

Leseempfehlung: Enzyklopädie der Wirtschaftsinformatik "Eintrag Netzplantechnik"

Projektinformationssysteme

Anforderungen an Projektinformationssysteme

• Verbesserung der Kommunikation und Koordination bei Projekten
• bessere Kontrolle der Projektpläne
• Erstellen benutzerdefinierter Planungslösungen
• Publizieren im Internet / Intranet
• Integration von Office - Produkten
• wirtschaftlicher Einsatz
• methodische und einfache Handhabung
• Differenzierung der Informationsdichte nach Informationslevel

Aufgaben von Projektinformationssystemen

• Planungsinstrument für
• Projektstruktur- und -ablaufplanung
• Termin-, Kapazitäts- und Kostenplanung
• Steuerungsinstrument für das
• Aufzeigen des Projektfortschritts
• Aufzeigen von Entscheidungsgrundlagen
• Aufzeigen von Kostenentwicklungen
• Kontroll- und Dokumentationsinstrument für die
• Termin-, Kapazitäts-, Kostenkontrolle
• Projektdokumentation und Ergebnisverwaltung
• Fortschrittsberichtserstattung

Software im Projektmanagement

Netzplansoftware

• Projektstrukturierung, Kostenplanung
• Planung und Kontrolle von Einsatzmitteln
• Dokumentation und Projekthistorie

Funktionale Software für die Projektarbeit

• Kostenschätzung
• Konfigurations-/Änderungsmanagement
• Risikoanalyse und Projektbeurteilung

Arbeitsplatzsoftware

• Textverarbeitung für Dokumentation
• Präsentationsgrafik
• Tabellenkalkulation

Computer-Assisted Learning/Learning Environments

• Teachware/interaktive Lernprogramme

Projektauftrag

• Schriftliche Fixierung der Zielvereinbarung des Entwicklungsvorhabens
• Vertragscharakter für Auftraggeber/-nehmer
• Enthält klare Definition der durchzuführenden Aufgabe, Kosten, Dauer

Inhalt eines Projektauftrags:

• Projektname
• Problemkurzbeschreibung, Zielsetzung, Begründung des Vorhabens
• Projektleiter, Teilprojektleiter, Unterauftragnehmer, sonstige Beteiligte
• geplanter Personalaufwand/Einsatzmittel
• Meilensteine/Fertigstellungstermine
• Chancen-/Risikobetrachtungen
• Randbedingungen

Kostenschätzung für Gesamtprojekte

Probleme bei der Schätzung von Projektkosten

• Wissensdefizite hinsichtlich der tatsächlich verursachten Kosten

• • phasenabhängige Verfügbarkeit von Informationen, die zur Durchführung von Kostenschätzungen erforderlich sind
  • in frühen Projektphasen fehlen oftmals

planungsrelevante Informationen in wesentlichem Umfang

• • zu Projektbeginn ist die Projektstruktur noch weit gehend unbekannt
  • bei der Projektstrukturplanung fehlt Wissen über den Projektablauf
  • spätere Änderungen von Projektstruktur oder Projektablauf sind anfangs notwendig unbekannt

Dilemma der Kostenplanung: in frühen Projektphasen

• erfolgen Entscheidungen, welche die späteren Projektkosten in erheblichem Ausmaß vorbestimmen,
• obwohl die erforderlichen Kosteninformationen oftmals nicht oder nur unzuverlässig zur Verfügung stehen

Reichweite der Kostenplanung

• nur die Projektkosten i.e.S., d.h. beispielsweise
  • die Entwicklungskosten bei der Entwicklung eines neuartigen Kfz-Motors
• die Baukosten bei der Herstellung eines Reaktors bekannter Technologie

• auch die Betriebskosten des
  • entwickelten bzw.
  • hergestellten Objekts
  • besonders relevant für BOOT-Projekte

• auch die Entsorgungskosten des Objekts
  • Kostenplanung einer Ölbohrinsel „Brent Spar”
  • Übergang zu Lebenszykluskosten-Analysen von Projekten

• • Methoden zur verursachungsgerechten Kostenschätzung
  • siehe früher: Kostenplanung auf Vorgangsebene
• taktisches/strategisches Verfälschen des vorhandenen Wissens über tatsächliche oder zumindest mutmaßliche Kosten
  • bewusste Kostenüberschätzungen (hohe Zielkosten ZK)
• um bei niedrigeren tatsächlichen Projektkosten (IK) entsprechend höhere Prämien zu erwirtschaften
• z.B. beim CPIF-Abrechnungsmodus

G = BG + RA·(ZK-IK)

• • bewusste Kostenunterschätzungen (niedrige Zielkosten)
• um den Zuschlag bei der Auftragsvergabe zu erhalten
• insbesondere beim CPFF-Abrechnungsmodus G = BG

betriebswirtschaftliche Methoden zur zielgerichteten

• Kostenüberschätzung oder
• Kostenunterschätzung

und Methoden zur Verhinderung solcher Schätzpraktiken

• z.B. VICKREY-Auktionsverfahren
  • stellt sicher, dass ein Leistungsanbieter bei rationalem Bieterverhalten
  • genau seine (erwarteten) Istkosten als Zielkosten (Erlösforderung) äußert„bidding games“

Methoden für die Kostenschätzung

E = IK + BG + RA· (ZK-IK) = BG + RA·ZK + (1-RA)·IK G = E - IK = BG + RA·(ZK-IK)

mit:

E: Erlös (Preis)

IK: Istkosten

FP: Festpreis

G: Gewinn

BG: Basisgewinn

RA: Risikoanteil des Auftragnehmers mit 0 ≤ RA ≤ 1

ZK: Zielkosten

Grenzfälle

• RA=0: Selbstkostenerstattungspreis mit Festgewinn

CPFF-Abrechnungsmodus: Cost Plus Fixed Fee

E = BG + 0·ZK + (1-0)·IK = IK + BG

• RA=1: absoluter Festpreis

FFP-Abrechnungsmodus: Firm Fixed Price

E = BG + 1·ZK + (1-1)·IK = ZK + BG = FP

Anwendungsbeispiel aus dem Bereich „Medizin-Management“

• Vereinbarung von Krankenkassen und Apotheken im Jahr 2003 zur Kostendämpfung im Gesundheitswesen
• Krankenkassen befürchteten, die Apotheken würden die Anzahl der abgegebenen Medikamentenpackungen „strategisch“ ausweiten,
• nachdem ein Festbetrag von 6,10 € je Medikamentenpackung (eventuell abzüglich Rabatten) vereinbart worden war
• Krankenkassen wollten kein Risiko tragen, mehr Medikamentenpackungen als im Jahr 2002 bezahlen zu müssen
• Apotheken vereinbarten, mindestens so viele Medikamentenpackungen wie im Jahr 2002 erstattet zu erhalten

§ 130 des „Kostendämpfungsgesetzes“ für das Gesundheitswesen

• „ … für das Jahr 2005 sind Vergütungen der Apotheken, die sich aus einer Abweichung der Zahl der abgegebenen Packungen verschreibungspflichtiger Arzneimittel im Jahr 2004 gegenüber dem

Jahr 2002 ergeben, auszugleichen … “

• wegen ihrer Risikoscheu haben die Krankenkassen als Auftraggeber
  • im Gesetz einen CPIF-Abrechnungsmodus festschreiben lassen mit:

E = IK + BG + RA· (ZK-IK)

mit: RA (des Auftragsnehmers!) = 1 und ZK = 6,10 € / Stück

• E = IK + BG + 1· (6,10·$Anzahl_{2002}$ -IK) = BG + 6,10·$Anzahl_{2002}$=“fix”

• die Krankenkassen
  • haben entgegen den Befürchtungen der Krankenkassen
  • im Jahr 2004 weniger (1,005 Mrd. Stück) Medikamentenpackungen

als im Jahr 2002 (0,845 Mrd. Stück) verkauft

• wegen der Festbetragsregelung fordern die Apotheken,
  • dass ihnen E = BG + 6,10 · $Anzahl_{2002}$ = “fix” erstattet wird

• die Krankenkassen und die Gesundheitsministerin („Ulla S.“) fordern,
  • dass den Apotheken nur die tatsächlich verkauften Medikamentenpackungen vergütet werden

wesentlicher Streitpunkt: wer trägt das „Risiko“?

Größenordnung

• ca. 226 bis 400 Mio. €
• 6,10 €/Stück · (1,005 Mrd. Stück – 0,845 Mrd. Stück) = 976 Mio. €

aber: intransparente Rabatte!

Rechtslage und ökonomische Analyse eindeutig:

• die Krankenkassen (und die Gesundheitsministerin) haben das gesamte „Risiko“ der Mehrmengen auf die Apotheken abgewälzt
• die Apotheken ernten jetzt die „Chancen“ der Mindermengen aufgrund des „freiwillig“ übernommenen Risikoanteils RA = 1

aber dennoch öffentlicher Streit:

• „Apotheker beharren auf Millionenforderung“
• „Politiker setzen auf Verhandlungslösung im Streit mit Kassen“

Schlussfolgerungen aus dieser „Realsatire“:

• hätten die Krankenkassen und das Gesundheitsministerium
• die „Funktionsweise“ von CPIF-Abrechnungsmodi durchschaut
  • wären sie vielleicht nicht so naiv gewesen,
  • RA = 1 zu „Lasten“ der Apotheken zu vereinbaren,
  • zumindest nicht „symmetrisch“ auch in Bezug auf Mindermengen

Parametrische Methoden

Basiskonzept  : Es wird ein Zusammenahng zwischen Kosten und mindestens einen weiteren ( quantitativ) Parameter angenommen.

qualitative Einflussgrösse wären z.B.

• Schwierigkeitsgrade „hoch“, „mittel“ „schwierig“

bei einer Entwicklungsaufgabe

• Einsatztyp wie „Realzeitanwendung“, „Dialoganwendung“,

„Batchbetrieb“ bei Anwendungssoftware

• Anspruchsniveau der Kunden bei Bachelor-, Master-, PhD-, Executive-Master-Studiengängen

Schätzung der Abbildungsvorschrift für die Kostenschätzfunktion „f“ durch statistische „best fit“-Analysen, insbesondere:

multivariate lineare Regressionsanalysen: K = f( $p_{1}$,$p_{2}$,...,$p_{n}$, $e_{1}$, $e_{2}$,..., $e_{n}$ )

Die Vorgabe der mathematischen Gestalt einer bestimmten Kostenschätzfunktion

• stellt ein kaum beachtetes Vorselektions-Problem dar
• „Bias“ für lineare u.ä. Fuktionen

Veranschaulichung der Kostenschätzfunktion in Diagrammen,

• mit direkten funktionalen Abhängigkeiten zwischen Parametern und Kosten als kontinuierlich variierenden Größen
• Aufspaltung der Kostenschätzfunktion in eine Funktionenschar abhängig von den Einflussgrößen als diskret variierenden Größen

Nachteile

genaue Kostenschätzungen sind mitunter Scheinpräzision

• weil sich mit statistischen Analysetechniken immer irgendwelche Werte berechnen lassen
• unabhängig von ihrer prognostischen Güte („Validität“) Vergleichsprojekte sollten nur herangezogen werden, wenn sie hinsichtlich ihrer Kostenverursachungsstruktur „hinreichend“ ähnlich sind

die Erfüllung dieser Anforderung ist aber oftmals unbekannt ?!

• Bei strengen Ähnlichkeitsanforderungen stehen oftmals nicht genügend Vergleichsprojekte zur Verfügung, um statistisch seriöse Kostenschätzfunktionen aufstellen zu können
• „Einmaligkeit“ von Projekten
• innovativer Charakter von Projekten

Multiplikator-Methode

Multiplikator-Methode als primitivste Variante ¸ die Kostenschätzfunktion wird auf einen simplen proportionalen Zusammenhang reduziert zwischen

• Projektkosten einerseits und
• genau einem Parameter andererseits

Nicht beachtet werden...

• nicht-lineare Zusammenhänge werden ignoriert
• Einflussgrößen werden nicht beachtet

Wie erhält man den Multiplikator ? aus Vergleichsprojekten wird ein Multiplikator ermittelt, der die Kosten pro Parameterausprägungseinheit angibt

unzulässige Proportionalisierung ?!

• aller Gemeinkosten (Fixkosten) und
• aller nicht-linearen Einzelkosten

CER-Technik

Verallgemeinerung der Multiplikatormethode

CER: Cost Estimation Relationships

Verallgemeinerung der Multiplikator-Methode durch

• mehrere quantitative Parameter
• Zulässigkeit von nicht-linearen Kostenschätzfunktionen

... keine unzulässigen Proportionalisierungen notwendig

• aber häufig noch unzulässige Linearisierungen, sofern lineare Schätzfunktionen verwendet werden

in der Praxis oftmals „ohne Not“ üblich

Standardfall parametrischer Methoden, der sich auszeichnet durch:

• keine Berücksichtigung qualitativer Einflussgrößen
• intensiver Gebrauch von sowohl multi- als auch monovariaten, sowohl nicht-linearen als auch linearen Regressionsanalysen

WOLVERTON-Methode

Kombination der Multiplikator-Methode mit zwei qualitativen Einflussgrößen:

• Schwierigkeitsgrad der Entwicklungsarbeiten mit den 3 Ausprägungen
  • “leicht”
  • “mittel”
  • “schwer”

• empirische Ermittlung von Multiplikatorender Dimension Kosten pro Einheit des Modulumfangs

Modulumfang oftmals gemessen in

• “lines of code” (loc)
• und zwar für jede Kombination zulässiger Ausprägungen für die zwei qualitativen Einflussgrößen

Schwierigkeitsgrad und Funktion

• Zerlegung der zu entwickelnden Software in Programm-Module und Schätzung der Modulkosten in Abhängigkeit:
  • vom erwarteten quantitativen Modulumfang
• in “lines of code” sowie
  • von den modulspezifischen Ausprägungen der beiden qualitativen Einflussgrößen „Schwierigkeitsgrad“ und „Funktion“
• Addition der Modulkosten aller Module der zu entwickelnden Software
  • ergibt die geschätzten Personalkosten PK für die Entwicklungsarbeiten

ein Zuschlagssatz z

• abhängig vom Gesamtumfang der Software in „lines of code“
• bis zu 11% für die allgemeinen Kosten des Projektmanagements pro Geldeinheit der geschätzten Personalkosten
• Gesamtkosten GK als Summe aus Personal- und Managementkosten:
  • GK = PK + z • PK

PRICE-Modelle

PRICE: Programmed Review of Information for Costing and Evaluation

• Zusammenfassung zahlreicher CER-Schätzgleichungen in einer Familie von umfangreichen Kostenschätzmodellen, die seit Mitte der 70er Jahre kommerziell verfügbar sind:
  • PRICE-H: Hardware-Entwicklungs-/Produktionskosten (1975)
  • PRICE-HL: Hardware-Instandhaltungs-/Lebenszykluskosten (1976)
  • PRICE-S: Software-Entwicklungskosten (1978)
  • PRICE-SL: Software-Wartungs-/Lebenszykluskosten (1980)
  • PRICE-M: Entwicklungs-/Produktionskosten für Mikrochips (1982)

• zusätzlich mehrere Hilfsprogramme, z.B. für:
  • Durchführung von Regressionsanalysen (PRICE-D)
  • Schätzung der Anweisungsanzahl (loc) bei Softwarepaketen

• schnelle Durchführung von Kostenschätzungen (PRICE-H)
  • Dateneingabe:

• ca. 20 bis 30 technische Parameter
  • Schätzdauer: wenige Minuten bis Sekunden

• aufwändige Modell-Kalibrierungen zur unternehmensspezifischen

Adjustierung der Schätzmodelle erforderlich

• • ECIRP-Hilfsprogramm
    • Anpassung der Parameter der Schätzgleichungen an unternehmensindividuelle Produktivitäten / Kostenzuschlagssätze
    • retrospektive Regressionsanalyse früherer Projekte gefördert durch Projektdatenbanken mit PRICE-Gliederung für „knowledge reuse“ / „lessons learned“ ?

COCOMO-Methode

COCOMO: Constructive Cost Model wurde von BOEHM Ende der 70er Jahre konzipiert

• anhand einer empirischen Erhebung des Entwicklungsaufwands für 63 Software-Projekte

Grundmodell: nicht-lineare Regressionsfunktion zwischen

• Programmgröße gemessen in „kloc“
• Personalaufwand gemessen in Personenmonate

Zwischenmodell:

• 15 weitere Einflussgrößen wie bei der WOLVERTON-Methode
• werden als zusätzliche „Kostentreiber“ berücksichtigt

wie z.B.: Analysefähigkeit der Mitarbeiter

• Erfahrungen der Mitarbeiter im spezifischen Aufgabengebiet
• Verwendung von „modernen” Software-Entwicklungsmethoden z.B. CASE-Werkzeuge
• Computer Aided Software Engineering

Detailmodell:

• zusätzlich wird eine Differenzierung der Einflussgrößen
• nach Projektkomponenten und Projektphasen ermöglicht

in der Softwareindustrie weit verbreitet

• wegen Einfachheit und
• hoher Transparenz

Function/Object-Point-Methode

Beispiel Vergütungstarif von AGD und SDSt Function-Point-Methode von J. ALBRECHT konzipiert für die Aufwandsschätzung von Software-Projekten

zwei Haupteinflussgrößen

• Anzahl zu erfüllender Funktionen der Informationsverarbeitung
• und deren Komplexität je einzelner Funktion: “einfach” / “mittel” / “schwer”

Ermittlung der gewichteten Funktionenanzahl als Produkt über alle Funktionen (n=1,…,N) Funktion $\sum _{n=1}^{N}$ = $f_{n}$

• Komplexitätsgewicht $g_{n}$

Ermittlung eines projektspezifischen Einflussgrads für zusätzliche Einflussgrößen, wie z.B.

• Aufwand für Ausnahmeroutinen
• schwierige Rechenprozeduren
• Ermittlung eines „Funktionswerts“ („function points“) als Produkt: gewichtete Funktionenanzahl • Einflussgrad

Ermittlung des Entwicklungsaufwands (Personenmonate) für ein Software-Projekt

• aus dem Funktionswert („function points“)
• mittels einer nicht-linearen „Funktionswertkurve“

Fortentwicklung zur Object-Point-Methode

Class Points: je Klasse (Objekttyp) werden erfasst

• (Attributeanzahl + 2 • Relationenanzahl + 3 • Methodenanzahl)
• multipliziert mit der Wiederverwendungsrate zur Berücksichtigung von

• Minderaufwand durch Wiederverwendung von „vorproduzierten“ Bausteinen aus Klassen-Bibliotheken
• Mehraufwand für Anpassung und Integration der Bausteine in ihre Anwendungsumgebung
• Message Points: für Aufwand zur Realisierung der Ablaufsteuerung durch „message passing“ zwischen den Objekten

• Process Points: in Abhängigkeit von Prozesstyp, Prozessvarianten und Komplexität
• Korrektur um Qualitätsgrad der Software: Aufstellung von Qualitätsanforderungen
• Offenheit für Total Quality Management u.ä. (TPM!): Verdichtung zu einem Qualitätsfaktor
• oftmals als „Durchschnitt“ aus allen Qualitätsanforderungen:

Quality Adjusted Object Points = Object Points • Qualitätsfaktor

• zusätzliche Korrektur um einen „aggregierten“ Einflussfaktor
• für 10 umgebungsspezifische Einzelfaktoren

Adjusted Object Points = Quality Adjusted Object Points • Einflussfaktor

• Entwicklungsaufwand (Personenmonate) für ein Software-Projekt nach der Multiplikator-Methode
  • ein „primitiver“ Rückschritt hinter die nicht-lineare „Funktionswertkurve“ der Function-Pouint-Methode
  • 2 Personenmonate je Adjusted Object Point
• nachträglich sind noch weitere „Kalibrierungen“ möglich
• Anpassung an unternehmens- und projektspezifische Einflüsse

Analogie-Methoden

Vorgehensweise zur Kostenschätzung für ein neues Projekt

• Suche in der Projektdatenbank nach einem bereits durchgeführten Projekt, das dem neuen Projekt am ähnlichsten ist

• Information-Retrieval-Techniken, insbesondere:
  • quantitative Ähnlichkeitsmaße: inhaltliche Probleme bei der Feststellung von Ähnlichkeiten

¸ bislang nur beherrscht: Ähnlichkeiten zwischen quantitativen Projektmerkmalen

• • vor allem aus dem Bereich von Data/Text/Knowledge Mining Mustererkennung („pattern matching”)

u.a. aus der KI-Forschung

• für qualitative Einflussgrößen: parametrische Schätzmethoden! liegen nur wenige Ähnlichkeitsmaße vor

• Gap-Analyse: Feststellung der Diskrepanz zwischen
  • ähnlichstem, bereits durchgeführten und
  • neuem, noch durchzuführenden Projekt
• zur Ermittlung von Anpassungsbedarf
• Anpassung der Kosteninformationen
  • über das alte Projekt
  • an die Spezifika des neuen Projekts, für eine begründete Schätzung der Kosten des neuen Projekts

Fallbasiertes Schließen: Case Based Reasoning (CBR) als moderne Variante der Analogie-Methoden

Ein Fall ist – im Kontext der Kostenschätzung – ein Tripel aus:

• der Beschreibung eines Entwicklungsprojekts

• Fallbeschreibung
  • durch quantitative und qualitative Deskriptoren
  • dem tatsächlich entstandenen Entwicklungsaufwand (Kosten)

• Fallresultat
• in Personenstunden (Volumen) und in Monaten (Zeitdauer)
• einer qualitativen Beurteilung der Generalisierbarkeit der Beziehung zwischen Projektbeschreibung und Entwicklungsaufwand

• Fallbewertung: wie z.B. „typisch” oder „Ausnahmefall”

Fallbeschreibung

Fallbeschreibung durch eine vordefinierte Deskriptoren-Hierarchie

• zur Vereinfachung und Systematisierung der Wissensakquisition über bereits bearbeitete Fälle
• Einsatzmöglichkeiten von Projekt-Ontologien
• Beispiele für typische, ein Projekt charakterisierende Deskriptoren:

• Projekt [i.e.S.] mit Angaben u.a. über Größe und Komplexität von
  • Entwicklungsaufgabe
  • Entwicklungsverlauf
  • Erfahrungsstand der Projektmitarbeiter

• (Software-) Produkt mit Angaben u.a. über „lines of code” Attribute-, Relationen-, Methoden-, Regelanzahlen usw.
  • Art der Benutzeroberfläche
  • Art der Hilfefunktionen
  • Art der Prozess-Kritikalität: Realzeit-, Dialog-, Batchbetrieb
• Sachgebiet („Domäne”), in dem das Produkt eingesetzt werden soll z.B. Flugzeug- versus Waschmaschinen-Steuerung
• eingesetzte Entwicklungswerkzeuge z.B. Vorgehensmodelle, CASE-Tools, Klassen-Bibliotheken

Darüber hinaus besteht hinreichende Flexibilität, um zusätzliche Deskriptoren zu ergänzen, die nur spezifisch für einzelne Projektklassen gelten wie. z.B. Enge des Kontakts mit Fachexperten insbesondere für die Entwicklung von Expertensystemen

Ermittlung eines ähnlichsten („besten“) Falls in der Falldatenbank

• Abgleich („best fit“) der neuen Fallbeschreibung mit allen bisher abgespeicherten Fallbeschreibungen
• keine feste Vorgabe von Ähnlichkeitskriterien
• sondern fallspezifische Festlegung der jeweils relevanten

Deskriptoren („Szenarien”) aus den Fallbeschreibungen, z.B.:

• Merkmale von Produktionsstrukturen bei der Entwicklung von PPS-Software
• Wissensdomäne und Regelkomplexität bei der Entwicklung eines „klassischen” Expertensystems

mehrstufige Ähnlichkeitsfeststellung durch:

• ausschließende Deskriptoren im Sinne von „k.o.“-Kriterien
• bewertende Deskriptoren
  • die diesbezügliche Ähnlichkeit zweier Projekte wird bei KURBEL et al. durch die „asymmetrische Tversky-Relation“ quantifiziert
• man kann sich „austummeln“ durch Aggregation der deskriptorenspezifischen Ähnlichkeitswerte
• durch Addition der gewichteten Ähnlichkeitswerte: Nutzwertanalyse
• aber ebenso vorstellbar: AHP-Technik, Goal Programming … (TPM)

Auswahl eines besten Falls mit Hilfe von heuristischen Auswahlregeln:

• Normalregel: ein bester Fall weist im Vergleich mit dem neuen Fall eine vorgegebene Mindestähnlichkeit auf und besitzt unter allen alten Fällen eine maximale Ähnlichkeit
• Kollisionsregel: wenn mehrere alte Fälle die Normalregel bestmöglich erfüllen, dann wird ein „typischer” Fall einem „unüblich verlaufenen” Fall vorgezogen

• Anpassung eines ausgewählten besten Falls an die Spezifika des aktuell betrachteten Falls
• Kostenschätzung für ein neues Projekt: Einsatz von heuristischen Anpassungsregeln,

die von erfahrenen Praktikern akquiriert wurden, wie z.B.:

• Wenn in der Fallbewertung für den ausgewählten besten alten Fall ausgewiesen wurde, dass das Fallresultat „realisierte Projektkosten“ atypisch niedrig lag,
• dann ist der geschätzte Projektaufwand um 10% zu erhöhen.

Probleme der Methodenanwendung

Probleme der Schätz-Zuverlässigkeit

• zwei Kategorien der Verursachung von unzuverlässigen Kostenschätzungen
• nach N.R. AUGUSTINE

• „bekannte Unbekannte“, die sich durch bewusste „Polster“ bei der Kostenschätzung berücksichtigen lassen
  • pessimistische Schätz-Szenarien,
  • Worst-case-Schätzungen
  • Durchlaufzeiten-Syndrom

Augustine's Law: Korrekturfaktor = ( 1 + ${\frac {0,8}{1+8*t^{3}}}$ )

t: Status der F&E-Arbeiten mit t=0 für F&E-Beginn und t=1 für F&E-Abschluss