Projektmanagement im Maschinenbau

Bei OpenPM wurde die Tage damit begonnen, eine Projektstart-Checkliste zu erstellen. Ich möchte das Ganze etwas pragmatischer angehen und versuche eine Checkliste für externe Projekte im Maschinen- und Anlagenbau zu entwerfen. Der Business Case erklärt sich damit auch von alleine – nämlich mit dem Verkauf der Anlage/Maschine einen Gewinn zu erwirtschaften. Nehmen wir weiterhin an, dass es zwei Projektstarts gibt – das Vorprojekt (vom ersten Kontakt bis zum fertigen Angebot) und der eigentliche Projektstart (Kundenauftrag eingegangen, interner Auftrag liegt vor):

Vorprojekt:

Projekthintergrund / Ausgangssituation / Projektumwelt:

• Wie wichtig ist das Projekt? (Priorität)
• Ist das Projektziel realistisch und tatsächlich erreichbar? (Machbarkeitsanalyse)
• Ist die Finanzierung der Machbarkeitsanalyse eindeutig geklärt?
• Ist das Projektziel unmissverständlich formuliert?
• Welche Zielvorgaben (Termin, Kosten, Qualität, Quantität) gibt es?
• Was sind Nicht-Ziele des Projekts?
• In welchem Umfeld bewegt sich das Projekt?
• Wer sind die Stakeholder (Interessenvertreter)?
• In welcher Beziehung stehen die Stakeholder zueinander?
• Gibt es limitierende Rahmenbedingungen?
• Mitarbeiter Qualifikation
• externe Ressourcen
• Produktionskapazitäten
• Ist das Budget (bzgl. Kosten & Ressourcen) ausreichend?
• Wurde eine erste Grobkalkulation durchgeführt und dokumentiert?
• Gibt es Abhängigkeiten zu anderen Projekten (positiv wie negativ)?
• Gab es bereits ähnliche Projekte in der Vergangenheit aus deren Erfahrungsschatz profitiert werden kann?
• Wenn ja, sind Lessons Learned verfügbar?
• Ist evtl. ein geformtes Team verfügbar?

Abwicklung

• Wurden Meilensteine (inkl. Zahlungsziele) definiert? (üblicherweise mindestens:
• Projektstart (Anzahlung)
• Final Acceptance Test beim Hersteller (1. Zahlung)
• Final Acceptance Test beim Kunden, offizielle Abnahme (Schlusszahlung)

Projektteam / Organisatorisches

• Wie wird das Projekt organisatorisch aufgebaut?
• Welche Rollen sind im Projekt zu besetzen?
• Wer sind die Mitglieder des Projektkernteams?
• Gibt es ein zentrales PMO oder muss für das Projekt ein Project Management Office (Teamassistenz) eingerichtet werden?

Anforderungen, Lastenheft:

Weitere Informationen in der  Checkliste Requirements Engineering.

• Liegt ein Lastenheft seitens des Auftraggebers vor?
• Wurden alle Lieferungen und Leistungen des Auftragnehmers schriftlich fixiert? Insbesondere:
• abzuliefernder Produkte und Produktunterlagen?
• Schnittstellenbeschreibung?
• Protokolle?
• Konstruktionsdokumente?
• Konstruktionsanforderungen
• Zeichnungen
• Stücklisten
• Vorschriften
• Fertigteilliste
• statische Berechnungen
• dynamische Berechnungen
• kinematische Berechnungen
• anzuwendende Maßeinheiten?
• anzuwendende Darstellungsformen/ -normen?
• Herstellungsplan?
• Beschreibung aller Fertigungs- und Testvorrichtungen?
• Montage- und Integrationsvorschriften?
• Verpackung und Transport?
• Verifikations- /Testkonzept?
• Sind alle Tests im Testbaum erfasst?
• Wurden alle Tests kategorisiert nach Entwicklungstest, Qualifikationstest, Abnahmetest…
• Wurden Tests auf Einzelteilebene und auf Systemebene erdacht?
• Schulung / Qualifikation?
• Bedienungsanleitungen?
• Wartungs,- Serviceanleitungen?
• Gibt es zu erfüllende Sonderbedingungen?
• Lebensdauer?
• Leistung?
• Strom-/Treibstoffverbrauch?
• Austauschbarkeit?
• Thermische Verformung, Ausdehnung?
• Brennbarkeit, Entflammbarkeit?
• Transportierbarkeit?
• Emissionen?
• Umweltverträglichkeit?
• Fertigungsfreundlichkeit?
• Festigkeit?
• Verformung?
• Gewicht?
• Programmiersprache der Steuerung?
• elektrische Leistung? (Hochspannung)
• Wärmeentwicklung?
• Wärmeisolierung?
• Lautstärke?
• Abmessung / Raumbedarf?
• Qualität?
• Wartungsaufwand?
• Strahlung?
• Beschleunigungen?
• Schwingungen?
• Eigenfrequenzen?
• Schnittstellen? (z.B. ProfiBus, RS485, Ethernet oder bestimmte Softwareprotokolle)
• Wurden alle Anforderungen auf Machbarkeit überprüft?
• Wurde für alle Anforderungen eine technische Lösungsmöglichkeit gefunden?
• Wurden Anforderungen, für die keine technische Lösungsmöglichkeit gesehen wurde, im Einvernehmen mit dem Auftraggeber aus dem Vertrag genommen?
• Wurden die Eigenfertigungs- und Fremdbezugsanteile eindeutig geklärt?
• Wurden für alle Anforderungen, deren Erfüllung analytisch überprüfbar sind, Berechnungsarten ermittelt und festgelegt?
• Wurden für alle Belastungen Sicherheitsfaktoren festgelegt? (oder sind ggf. Faktoren gesetzlich vorgeschrieben?)

Technische Risiken:

• Besteht der Lieferumfang aus erprobten Teilanlagen / Komponenten?
• Ist die Herstellungstechnologie bekannt und erprobt?
• Wurde auf mögliche alternative Technologien geprüft?
• Wenn ja, wurde eine begründbare (dokumentierte) Auswahl getroffen?
• Sind technische Garantien gefordert?
• Ergibt sich aus dem Projekt ein Patentrisiko?
• Ist der Service und Ersatzteildienst gesichert?
• Ist das Risiko eines Ausfalls von Anlagen oder Anlagenteilen begrenzt?
• Sind unbekannte Technologien beherrschbar?
• Sind unbekannte Produktionsverfahren beherrschbar?
• Sind Risiken aufgrund unbekannter Anwendungen des Systems begrenzt?
• Sind die Risiken aufgrund der Komplexität des Gesamtsystems begrenzt?
• Sind die Risiken aufgrund möglicher Modifikationen des Gesamtsystems begrenzt?
• Sind die Schnittstellenrisiken begrenzt?
• Sind Transportrisiken begrenzt? Ist die Anlage transportierbar?

Projekt:

Kick-Off Meeting

• Sind technische Voraussetzungen für das Meeting vorhanden?
• Raum
• Beamer
• Präsentation
• Unterlagen / Handouts
• Einladungen an alle Teilnehmer mit Tagesordnungspunkten
• ggf. Catering
• Wie ist die Projektorganisation aufgebaut?
• hinsichtlich Personal? (Projektleiter), Vorstellungsrunde
• regelmäßige Projekt-Meetings? (Jourfixe)
• Statusberichte? (wie oft, von wem, an wen?)
• Gibt es einen Lenkungsausschuss bzw. ein Steuerungsgremium?
• Wurden organisatorische Faktoren zum Projektstart geklärt?
• Projektnummer vergeben?
• Projektakte / -ordner eröffnet?
• Projektsteckbrief verfasst und veröffentlicht?
• interner Projektauftrag von Geschäftsführung / Bereichsleitung unterschrieben?
• Wissensmanagement nach Unternehmensvorgaben?
• Gibt es ein gemeinsames Glossar? (insbesondere bei Zusammenarbeit mit Externen/Dienstleistern)
• Ist das Projektbudget bekannt und soll es kommuniziert werden?
• Wurden die Aufgaben spezifiziert, die vom PMO erfüllt werden sollen?
• Unterstützung bei Aufwandsschätzung?
• Aufbauen und Verwalten (Pflegen) von Projektplänen?
• Erstellen von Auslastungsberechnungen (Personalplanung)?
• Erstellen von Terminplänen?
• Termintracking? (z.B. Lieferanten)
• Unterstützung bei der Stundenkontierung?
• Erstellen von Trendanalysen?
• Erstellen von Statusberichten?
• Unterstützung der Qualitätssicherung?
• Organisieren von Projektmeetings? (Protokolle erstellen und verteilen)
• Pflege der Lessons Learned?
• Offene-Punkte-Liste pflegen?
• Wurden Aufgaben mit Verantwortlichkeit und Lösungszeitraum benannt  (schriftlich im Protokoll)?
• Wurde das Protokoll an alle Teilnehmer gesendet und im Team-Space / Projektordner abgelegt?
• Sollen weitere Stakeholder das Protokoll erhalten

Projektstrukturplan:

• Sind alle Teilaufgaben (und Meilensteine) erfasst?
• Decken die Arbeitspakete alle Aufgaben des Projekts vollständig ab?
• Sind alle Abhängigkeiten zwischen den Arbeitspaketen dokumentiert?
• Sind alle Aufgaben an externe Unternehmen als Arbeitspaket eingerichtet?
• Ist für jedes Arbeitspaket:
• eine vollständige Arbeitspaketbeschreibung verfügbar?
• nur eine Person verantwortlich und benannt?
• eine Zuordnung der Kosten und Ressourcen erfolgt?
• eine übergeordnete Teilaufgabe zugeordnet?

Konfigurationsmanagement:

• Sind den Konfigurationseinheiten die zugehörigen Dokumente zugeordnet?
• Ist ein geeignetes Nummerierungssystem eingeführt worden?
• Ist jeder Änderungsstatus eindeutig identifizierbar?
• Ist jede Änderung rückverfolgbar?
• Ist die Bezugskonfiguration (Baseline) bestimmt?
• Ist der Änderungsprozess lückenlos definiert und beschrieben?
• Liegt ein Änderungsantragsformular vor? (Change Request)
• Wird in der Formularvorlage darauf eingegangen, wer die Kosten der Änderung zu tragen hat?

Projekte im Ausland:

• Ist der Kunde / das betreffende Land Sanktionen unterworfen? (Schwarze Liste)
• Liegt der Lieferort in einem politischen Spannungsgebiet?
• Sind klimatische Risiken bekannt? (Unwetter, Hitze, Frost?)
• Ist eine Ausfuhrgenehmigung / sind Einfuhrgarantien / Baugenehmigungen erforderlich?
• Ist eine handelsrechtliche oder steuerrechtliche Registrierung im Land notwendig?
• Ist die Gründung einer eigenen Gesellschaft für die Durchführung des Auftrags notwendig?
• Müssen ggf. bestehende Steuergesetze im Land berücksichtigt werden?
• Sind internationale juristische Besonderheiten hinreichend bekannt?
• Muss von allen Erzeugnissen (Baugruppen) ein Nachweis über das Herstellungsland dokumentiert werden?
• Sind fremdsprachige Beschreibungen, Anleitungen, Bedienungs- und Wartungsanleitungen vorhanden?
• Müssen bestimmte gesetzliche Rahmenbedingungen eingehalten werden?
• Maschinenrichtlinie des Landes? (CE Norm)
• RoHS-Konfirmität?
• Halogenfreie, flammwidrige Kabel?
• Vor Ort eingesetzte Mitarbeiter:
• Werden die im Zusammenhang mit der Montage tätigen Arbeitnehmer im Land steuerpflichtig / sozialversicherungspflichtig?
• Wurden bei der Budget-Planung die Kosten für Visa, Reise und Unterbringung der Mitarbeiter berücksichtigt?
• Müssen bestimmte Impfungen veranlasst werden?
• Ist der Reisepass des Mitarbeiters gültig?
• Ist die Eröffnung eines Bankkontos im Land erforderlich?
• Wurde das Währungsrisiko bedacht? (Wer sichert ab?, wird in EURO oder in Landeswährung angeboten?)
• Ist die Finanzierung über eine Bank abgesichert?
• Was passiert bei Ausfall der Zahlung? (Käufer,- / Verkäuferschutz)
• Wie wird die Anlage / Maschine transportiert? (Schiff, Flugzeug, LKW).
• Wurde eine geeignete Transportversicherung abgeschlossen?
• Sind Lager-, Transport- und Verlademöglichkeit im Empfängerland geklärt?
• Ist sichergestellt, dass technische Hilfsmittel am Aufbauort verfügbar sind? (z.B. Gabelstapler)
• Ist die Einfuhr der Erzeugnisse an Einfuhrgenehmigungen gebunden?
• Wer beantragt diese?
• Sind bei Einfuhr der Materialien Abgaben zu entrichten?
• Wie wird das eingeführte Montagegerät behandelt?
• Welche Formalitäten bei der Zollbehörde sind zu erfüllen?

Quellen (Inspiration):

OpenPM – Checkliste Projektstart
Gareis, R. – Projektmanagement im Maschinen- und Anlagenbau. MANZsche Verlags- und Universitätsbuchhandlung Wien, 1991
Felkei, R., Beiderwieden A. – Projektmanagement für technische Projekte. Vierweg+Teubner Verlag, 2011
Burghard, M. – PM-Merkblätter Beiheft zum Buch “Projektmanagement” (SIEMENS)

eigene Erfahrungen im Projektgeschäft

Nachdem ich das Buch “Requirements Engineering – a good practice guide” etwas näher vorgestellt habe, möchte ich gerne aus den beschriebenen Guidelines eine Checkliste für das Requirements Engineering ableiten. Es folgt eine Tabelle mit drei Spalten:

Spalte 1 -> Kapitel des o.g. Buches / Guideline-Nr.
Spalte 2 -> Name der Guideline (engl. Original)
Spalte 3 -> (sinnvolle) Ableitung für das Requirements-Engineering im Maschinenbau (Checkliste)

3.1	Define a standard document structure	Ist die Struktur des Anforderungsdokuments standardisiert? *
3.2	Explain how to use the document	Wird erläutert, wie das Anforderungsdokument zu benutzen ist? (einleitendes Kapitel)
3.3	Include a summary of the requirements	Wurde eine Zusammenfassung des Projekts im Anforderungsdokument hinterlegt?
3.4	Make a business case for the system	Liegt dem Projekt ein Business Case zu Grunde?
3.5	Define specialized terms	Ist ein Glossar zur Unterstützung des einheitlichen Verständnisses von Fachbegriffen verfügbar?
3.6	Lay out the document for readability	Ist das Anforderungsdokument einfach lesbar? (Layout) *
3.7	Help readers find information	Ist ein Index / Inhaltsverzeichnis im Anforderungsdokument vorhanden?
3.8	Make the document easy to change
4.1	Assess system feasibility	Liegt eine Machbarkeitsstudie für das Projekt vor?
4.2	Be sensitive to organizational and political considerations	Wurden politische / interne Interessen betrachtet?
4.3	Identify and consult system stakeholders	Wurden alle relevanten Stakeholder einbezogen?
4.4	Record requirements sources	Wurde die Quelle für jede Anforderung aufgenommen?
4.5	Define the system’s operating environment	Wurde die Betriebsumgebung genau definiert? Welche Bedingungen sind am Standort vorhanden? (Medien, Räume, Transportmittel, Schwingungen, Temperatur, Luftfeuchte…)
4.6	Use the business concerns to drive requirements elicitation
4.7	Look for domain constraints	Wurden auf Einschränkungen im Gesamtsystemkontext geprüft? (Lärmschutzanforderungen, Strahlenschutzanforderungen, zu erfüllende Normen?)
4.8	Record requirements rationale	Wurde eine Begründung für die Anforderung mitgeliefert / dokumentiert?
4.9	Collect requirements from multiple viewpoints	Wurden die Anforderungen aus mehreren Perspektiven überprüft / formuliert?
4.10	Prototype poorly understood requirements	Wurde versucht unklare Anforderungen anhand eines Prototyps deutlich zu erläutern?
4.11	Use scenarios to elicit requirements	Können Szenarios (Anwendungsfälle / Use Case) genutzt werden um weitere (verborgene / bisher nicht bedachte) Anforderungen zu extrahieren?
4.12	Define operational processes
4.13	Reuse requirements	Ist die Anforderung identisch / ähnlich zu einer Anforderungen aus einem anderen Projekt? Könnte die Anforderung aus einem anderen Projekt übernommen / modifiziert werden?
5.1	Define system boundaries	Wurden die Systemgrenzen definiert und dokumentiert?
5.2	Use checklists for requirements analysis	Wird jede Anforderung anhand einer Checkliste geprüft? (Mögliche Fragen: - Sind in der Anforderung bereits technische Informationen zur Umsetzung enthalten? -> lösungsneutral formulieren - Handelt es sich evtl. um eine kombinierte Anforderung? (Besteht die Möglichkeit der Splittung in zwei oder mehr einzelne Anforderungen) - Ist die Anforderung unbedingt erforderlich oder handelt es sich um eine „Nice-To-Have“ oder „Gold plating“ Anf.? - Muss zur Umsetzung der Anforderung eine Eigenentwicklung durchgeführt werden oder kann auf Standard-Soft/Hardware zurückgegriffen werden? (z. B. eigenen Mikrocontroller entwickeln oder kommerzielles Produkt einsetzen?) - Geht die Anforderung konform mit den Zielen im Business Case des Projekts? (siehe 3.4) - Ist die Anforderung eindeutig oder kann sie von verschiedenen Lesern verschieden interpretiert werden? Was sind mögliche Interpretationen? - Ist die Anforderung realistisch mit der zu verwendenden Technologie erfüllbar? - Kann die erfolgreiche Umsetzung der Anforderung mit einem Testfall überprüft werden?
5.3	Provide software to support negotiations	Haben alle Stakeholder Zugriff auf die Anforderungen? (Einheitliche Diskussionsgrundlage für Verhandlungen)
5.4	Plan for conflicts and conflict resolution	Werden bereits während der Anforderungsaufnahme evtl. Konflikte / Überschneidungen identifiziert und Lösungen angedacht? (“requirements negitiation meetings”)
5.5	Prioritise requirements	Wurden alle Anforderungen priorisiert?
5.6	Classify requirements using a multi-dimensional approach	Wurden die Anforderungen kategorisiert (z.B. System, User Interface, Datenbank, Sicherheit)
5.7	Use interaction matrices to find conflicts and overlaps	Wurde eine Interatkionsmatrix benutzt um Anforderungs-Konflikte und Überlappungen zu erkennen?
5.8	Assess requirements risks	Wurde jede Anforderung hinsichtlich Risiken überprüft? Wenn ja, wurde Eintrittswahrscheinlichkeit, Auswirkung, Gegenmaßnahme dokumentiert?
6.1	Define standard templates for describing requirements	Gibt es standardisierte Templates wie Anforderungen zu formulieren sind? (bestimmte Wortgruppen, Schlüsselworte…)
6.2	Use language simply, consistently and concisely	Wurde möglist einfache Sprache verwendet und wurden Begriffe konsistent benutzt?
6.3	Use diagrams appropriately	Wurden Diagramme angemessen benutzt? (z. B. um Abläufe, Datenströhme oder schwer in Text zu fassende Anforderungen zu beschreiben)
6.4	Supplement natural language with other descriptions of requirements
6.5	Specify requirements quantitatively	Wurden alle quantitativen Anforderungen genau spezifiziert (z. B. Zahlenwerte, Wertebereiche, Toleranzen).
7.1	Develop complementary system models	Wurde an geeigneten Stellen ein Modell / Showcase hinterlegt? (z. B. Screenshot einer Benutzeroberfläche, Mockups)
7.2	Model the System’s Environment	Wurde die Systemumgebung modelliert? (Schnittstellen, evtl. beteiligte Geschäftsprozesse)
7.3	Model the System Architecture	Wurde die Gesamtsystemarchitektur modelliert? (Vogelperspektive, Untersysteme und deren Interaktionen)
7.4	Use structured methods for system modeling	Wurde bei System-Modellierungen eine strukturierte Methode verwendet (z.B. UML, ARIS…)
7.5	Use a data dictionary	Wurde ein Komponenten-Glossar angelegt? (einheitliche Sprache in großen Projekten mit vielen Mitarbeitern)
7.6	Document the links between stakeholder requirements and system models	Wurden Verbindungen zwischen natürlichsprachigen Anforderungen und zugehörigen Systemmodellen hergestellt?
8.1	Check that the requirements document meets your standards	Wurden Standards zum Anforderungs-Management festgelegt? Wenn ja, wurden die Standards eingehalten?
8.2	Organize formal requirements inspections	Werden die aufgenommenen Anforderungen (regelmäßig) durch Inspektionen von (internem) Fachpersonal überprüft (und ggf. auf Probleme und Inkonsistenzen untersucht)
8.3	Use multi-disciplinary teams to review requirements	Werden die Anforderungen auch von Mitarbeitern aus anderen Fachbereichen überprüft? (z. B. aus Sicht des Service, der Inbetriebnahme oder der Fertigung)
8.4	Define validation checklists	Werden die gesammelten Anforderungen einer Validierung basierend auf einer Checkliste unterzogen? Fragen könnten z. B. sein:- Sind die Anforderungen komplett? Gibt es aus einer anderen Sichtweise evtl. zusätzliche Anforderungen? - Sind die Anforderungen konsistent oder gibt es evtl. mehrere Anforderungen, die einen Sachverhalt unterschiedlich beschreiben? - Sind die Anforderungen verständlich, einheitlich und eindeutig formuliert? - Sind die Anforderungen nachverfolgbar? (einheitliche, eindeutige Bezeichnung, Quelle, betreffende Stakeholder, Änderungen) Enthalten die Anforderungen Verweise zu zusammenhängenden Anforderungen? (Siehe auch 5.2 -> Checkliste für einzelne Anforderungen)
8.5	Use prototyping to animate requirements	(siehe Guideline 4.10)
8.6	Write a draft user manual
8.7	Propose requirements test classes	(siehe Guideline 5.2)
8.8	Paraphrase system models
9.1	Uniquely identify each requirement	Ist jede Anforderung eindeutig identifizierbar?
9.2	Define policies for requirements management	Wurde eine einheitliche Strategie zum Requirements Management definiert? Diese sollte mindestens enthalten: - Standards für Anforderungsdokumente (siehe 3.1 und 6.1) - Plan wie Veränderungs-Management (Change Management) zu erfolgen hat - Plan zum Review von Anforderungen und deren Validierung - Verbindungen zwischen Anforderungsmanagement und anderen Fachabteilungen - Plan wie “Traceability” umgesetzt wird (Welche Informationen über Abhängigkeiten von Anforderungen soll erhalten bleiben und wie?) - ggf. Reports
9.3	Define traceability policies	Welche Traceability-Informationen sollen gesammelt werden? z. B. - Anforderung – Quelle - Anforderung – Begründung - Anforderung – Anforderung (Abhängigkeiten) - Anforderung – Subsystem (Architektur) - Anforderung – Schnittstelle
9.4	Maintain a traceability manual	siehe 9.3
9.5	Use a database to manage requirements
9.6	Define change management policies
9.7	Identify global system requirements	Wurden alle globalen Systemanforderungen erhoben? (Übergreifende Anforderungen, z. B. keine scharfen Kanten an der Maschine)
9.8	Identify volatile requirements
9.9	Record rejected requirements	Wurden alle verworfenen Anforderungen dokumentiert? (Auch der Grund warum die Anforderung verworfen wurde?)
10.1	Create safety requirements checklist	Wurde eine Checkliste mit Sicherheitsanforderungen erstellt? Fragen könnten sein: - Wie hat ein korrekter Maschinen-Start zu erfolgen? - Welche Initialparameter sollen hinterlegt sein? - Wie wird auf bestimmte Benutzereingaben reagiert? - Was passiert wenn ein (Teil-)System offline geht? - Was passiert wenn unerwartete Eingaben erfolgen? - Wie erfolgt ein Validitätscheck von Benutzereingaben? - Was passiert bei Time-Outs / Buffer-Overruns? - Welche Alarm-Stati / Systeme gibt es?
10.2	Involve external reviewers in the validation process	- Könnten externe Reviewer in den Validierungsprozess integriert werden?
10.3	Identify and analyze hazards
10.4	Derive safety requirements from hazard analysis
10.5	Cross-check operational and functional requirements against safety requirements	Wurden alle Anforderungen anhand des Sicherheitkonzepts überprüft?
10.6	Specify systems using formal specifications
10.7	Collect incident experience
10.8	Learn from incident experience
10.9	Establish an organizational safety culture

*) Anmerkung: erübrigt sich bei Nutzung einer softwarebasierten RE-Lösung

Anforderungsanalyse, Anforderungsmanagement, Requirements, Requirements Engineering, Requirements Management

Kurzbewertung:
ISBN: 978-0471974444

Im Zuge meiner Recherchen bin ich heute auf einen Schatz der Requirements Engineering Literatur gestoßen. Ian Sommerville und Pete Sawyer trugen 1997 auf knapp 390 Seiten in einem “good practice guide” die ihrer Meinung nach wichtigsten Praktiken rund um das Thema Anforderungen zusammen. Ich meine, der Großteil des Buches ist aktueller denn je!

Inhalt

Nach Kapitel 1 (Einführung) gehen die Autoren direkt auf die praktische Prozessverbesserung ein. Dazu wird gezeigt wie der Reifegrad der Prozesses gemessen werden kann und welche die Top 10 Guidelines sind. Von Kapitel 3 bis 10 werden die insgesamt 66 Guidelines untergliedert in:

(3) Das Anforderungsdokument
(4) Anforderungsaufnahme
(5) Anforderungsanalyse und -verhandlung
(6) Anforderungen beschreiben
(7) System Modellierung
(8) Anforderungsüberprüfung
(9) Anforderungs-Management
(10) Anforderungs-Management für kritische Systeme
näher erläutert.
Kapitel 11 gibt einen Überblick über Modellierung mit strukturierten Methoden. Die Vor- und Nachteile einer formalen Spezifikation werden in Kapitel 12 näher betrachtet. Abschließend wird in Kapitel 13 auf verschiedene Sichtweisen (Viewpoints) von Anforderungen eingegangen.

Stil

Das Buch ist in allen Belangen extrem praxisnah. Sehr viele Stichpunkte, übersichtliche Struktur und viele Zusammenfassungen machen es geradezu spielerisch möglich, sich einen bestimmten Aspekt des Buches heraus zu greifen und innerhalb weniger Minuten zu durchschauen. Die englische Sprache ist dabei kein Hindernis – alles ist recht einfach formuliert. Eine deutsche Übersetzung habe ich nicht gefunden. Die einzelnen Guidelines sind immer gleich aufgebaut: erst kommt eine Zusammenfassung in Tabellenform, in der Name, Hauptnutzen, eine Einschätzung des Aufwands zur Einführung und der zu erwartenden Kosten sowie der Guideline-Typ (Basic, Intermediate, Advanced) aufgeführt sind. Dann wird etwas detaillierter erläutert, welche Vorteile die Guideline mit sich bringt, wie sie implementiert werden kann und was bei der Umsetzung für Aufwände und Probleme zu erwarten sind.

Fazit

Auch wenn das Buch für Software-Entwickler geschrieben wurde und die Erstauflage bereits 15 Jahre in der Vergangenheit liegt, kann dieses Buch ohne Einschränkung auch an jeden Maschinenbauer empfohlen werden, der sich mit dem Management von Anforderungen auseinander setzen muss. Lediglich die beschriebenen Modelle und strukturierten/formalen Methoden sind etwas in die Jahre gekommen. Wer ein günstiges Second-Hand Exemplar erwerben kann, wird den Kauf keinesfalls bereuen! Die knapp 80 EUR Neupreis sind allerdings doch etwas happig.

Anforderung, Anforderungsanalyse, Requirements, Requirements Engineering, Requirements Management

Ich bin ein sehr großer Check-Listen Fan! Neulich schwebte mir die Idee vor, warum nicht einmal eine Check-Liste entwickeln, mit deren Hilfe sich ein Projektmanagement-Handbuch gestalten lässt? Ein solches Handbuch sollte quasi in jedem Unternehmen verfügbar sein, das im Projektgeschäft tätig ist. Es ermöglicht neuen Kollegen das nötige Wissen zu vermitteln, wie ein Projekt abgewickelt wird und dem Unternehmen an sich, die Qualität des PMs messbar zu machen. Natürlich ist jedes Unternehmen unterschiedlich und daher wird es nie den heiligen Gral der Projektmanagement-Handbücher geben.

Die Idee ist die, einen großen Haufen intelligenter Fragen zum Thema Projektmanagement zu formulieren. Je vollständiger die Liste, desto unwahrscheinlicher ist es, dass ein essentieller Teil vergessen wurde. Punkte die für das Unternehmen weniger wichtig erscheinen oder in der Implementierung zu aufwändig sind, können einfach gelöscht werden. So ergibt sich ein individuelles Set von Fragen, deren Beantwortung das PM-Handbuch ergeben.

Ein kleines Beispiel:

Projektphase -> Zieledefinition

- Wie sind zu Beginn eines Projekts die Projektziele systematisch zu erfassen?
- Wie sind die Zuständigkeiten für die Festlegung von Projekten geregelt?
- In welcher Form werden in den Projektzielen Kostenziele, Terminziele und Qualitätsziele erfasst?

usw…

Die Quantität und Qualität der Antworten bleiben natürlich jedem PM-Verantwortlichen selbst überlassen. Es gibt bekanntlicher weise viele Wege nach Rom und in der heutigen Zeit ist reichhaltiges Methoden-Wissen nur einen Maus-Klick entfernt.

Die Inspiration zu den Fragen werde ich aus verschiedenen Quellen (z.B. Reifegradmodelle, Fachliteratur, eigene Erfahrungen) beziehen. Sobald mein erster Entwurf fertig ist, wird er an dieser Stelle veröffentlicht.

Ich möchte heute alle Leser auf ein Projekt hinweisen, welches ich nach einigen Wochen skeptischen Beobachtens und Abwartens, für einen sehr guten Ansatz halte!

Um die Erklärung zu vereinfachen, copy-und-paste ich hier einfach mal das Mission Statement:

“Open-PM (#openpm) ist eine offene, frei zugängliche, unabhängige und nicht kommerzielle Plattform für Projektmanagement und alle, die an Projekten arbeiten. Aus der Praxis für die Praxis werden qualitativ hochwertige, interdisziplinäre, vielfältige und unter einer freien Lizenz nutzbare Tools und Prozesse als zentral verfügbares Know-How gesammelt, bereitgestellt und gemeinsam weiter entwickelt.

Werte

Aus der Praxis für die Praxis.
Wertschätzender Umgang mit Meinungs- und Ideenvielfalt.
Offen und frei zugänglich und unter einer freien Lizenz nutzbar.
Kollegiale Zusammenarbeit und Bereitschaft zum Teilen.”

Quelle: OpenPM