Kategorie-Archiv: Check-Liste

Checkliste Übergreifende Projektziele

o Wurden übergreifende Projektziele definiert?
o Wurden alle Ziele lösungsneutral formuliert?
o Ist jedes Projektziel realistisch und tatsächlich erreichbar?
o Ist jedes Projektziel messbar, mindestens aber überprüfbar formuliert?
o Wurden alle Projektziele schriftlich dokumentiert?
o Sind allen Sachzielen entsprechende Zeitziele zugeordnet?
o Wurden zu jedem Projektziel wichtige Informationen hinterlegt? (z.B. Stakeholder, Grund für das Ziel, Verknüpfungen zu anderen Zielen, Konflikte, Changelog)
o Sind in den Projektzielen Kostenziele, Terminziele und Qualitätsziele erfasst?
o Wurden auch Nicht-Projektziele auf geeignete Weise dokumentiert?
o Wurden alle übergreifenden Projektziele vor Projektbeginn festgelegt?

o Wurden Zuständigkeiten für Festlegungen von Zielen innerhalb des Projekts definiert / dokumentiert?
o Wurden Projektziele durch ein Steuerungsgremium freigegeben?
o Wurden die Projektziele mit allen Stakeholdern abgestimmt? (ggf. gegengezeichnet)

o Wurden alle Ziele auf Zielalternativen hin geprüft?
o Bei Änderungen der übergreifenden Projektziele:
– werden die Anforderungen aller Stakeholder berücksichtigt?
– werden Änderungen dokumentiert? (ggf. von Auftragnehmer / Auftraggeber gegengezeichnet)

o Ist sichergestellt, dass Kostenziele, Terminziele und Qualitätsziele während der Realisierungsphase regelmäßig gemessen und bewertet werden? (–> evtl. in Checkliste Projektkontrolling)

Checkliste Projektstart

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?
Planungsrisiken:
  • Ist eine hohe Änderungshäufigkeit der Anforderungen zu erwarten?
  • Wurde in geeignetem Maße auf die Terminunsicherheit bei Unterauftragnehmern und Lieferanten eingegangen? (Wurden Lieferzeiten realistisch eingeschätzt?)
  • Wurde in geeignetem Maße auf die Qualitätsunsicherheit bei Unterauftragnehmern und Lieferanten eingegangen?
  • Sind die Meilensteine sachgerecht gesetzt?
  • Wurden alle logischen Abhängigkeiten im Projektablauf bedacht?
Vertragliche Risiken:
  • Sind alle Verträge eindeutig und unmissverständlich formuliert?
  • Ist indirekter Schaden (Folgeschaden) vertraglich ausgeschlossen?
  • Ist eine Force-Majeure-Klausel vorgesehen (Krieg, Aufruhr, Streik, Unwetter)
  • Wird eine verlängerte Gewährleistungsfrist gefordert?
  • Hat der Kunde außergewöhnliche Schadensersatz- oder Rücktrittsrechte?
  • Sind Vertragsstrafen für Fristüberschreitungen gefordert? (Penalty)
  • Ist ein Gerichtsstand oder Schiedsgericht vorgesehen?
  • Kann Eigentumsvorbehalt durchgesetzt werden?
  • Ist die Übernahme angefallener Investitionskosten bei Projektabbruch klar geregelt?
Kaufmännische Risiken:
  • Besteht ein Preisrisiko (Festpreis, Pauschalpreis)?
  • Wurden Risiken in der Kalkulation angemessen bewertet?
  • Wurden die wichtigsten Kosten berücksichtigt? (auch für sämtliche Teile?)
    • Konstuktions- / Entwicklungskosten?
    • Fertigungskosten?
    • Montagekosten?
    • Verifikations- (Test) Kosten?
    • Transportkosten?
    • Reisekosten?
    • Abnahmekosten?
    • Schulungskosten?
    • Gewährleistung- und Garantie?
  • Sind alle bis zum Ablauf der Festpreisbindung zu erwartenden Material- und Lohnveränderungen berücksichtigt?
  • Ergeben sich Zahlungsausfall- oder Finanzierungsrisiken?
  • Liegen ausreichend Sicherheiten für die Zahlung vor?
  • Ist die Bonität des Auftraggebers ausreichend?
  • Sind eingeplante Finanzierungsquellen verlässlich?
  • Sind Liquiditätsengpässe auszuschließen?
  • Sind Geldtransferrisiken begrenzt?
  • Sind die Kosten für erforderliche Patente / Lizenzen bekannt?
  • Sind für alle Fälle ausreichend Rückstellungen gebildet worden?
Personelle Risiken:
  • Wurde  in geeignetem Maße auf Personalrisiken eingegangen? (Vertretungen, Urlaub, Krankheit, Fluktuation)
  • Verfügen die Mitarbeiter über die erforderliche Qualifikation? (Wenn nein, sind Schulungsaufwände einkalkuliert?)
  • Sind die Mitarbeiter motiviert?
  • Sind die Risiken aufgrund interkultureller Differenzen begrenzt?

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

Checkliste Requirements Engineering

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

Checklisten zur Erstellung eines Projektmanagement-Handbuchs

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.