<projektname>
Projekt-Handbuch
Version: 01
06.12.2019

Status: draft

Dokument Eigentümer:

<Name des Projektleiters>

Anpassungen für ein Projekt sind notwendig. Erweiterungen/ Änderungen liegen in der Verantwortung des Projektleiters. Änderungen bzgl. dem Template sind zurückzumelden an M. Grzan oder Abteilung QM.

Inhalt

Inhaltsverzeichnis

1	Inhalt	2

1.1	Inhaltsverzeichnis	2

1.2	Tabellenverzeichnis	3

1.3	Abbildungsverzeichnis	3

1.4	Abkürzungen	3

2	Scope / Ziel	4

2.1	Nutzung der Ergebnisse	4

2.2	Informations-Quelle	4

3	Das Projekt	5

3.1	Systembeschreibung	5

3.1.1	Übersicht Module	5

3.1.2	Entwicklungsstufen	5

4	Organisation	6

4.1	Projekt-Team	6

4.2	Projekt-Organigramm	7

4.3	Terminplan	7

4.4	Stakeholder	8

4.5	Schnittstellen	8

4.6	Projekt-Disziplinen	9

4.6.1	Projektleitung	9

4.6.2	System-Engineer	9

4.6.3	EE-HW	9

4.6.4	EE-SW	9

4.6.5	HMI/GUI	9

4.6.6	Mechanisches Design	9

4.6.7	Test und Validierung	9

4.6.8	Entwicklungsleitung	9

4.7	Datenhandling im Projekt	10

4.7.1	Dateinamen	10

4.7.2	Email-Kennzeichnungen	10

4.7.3	Projektsprache in Dokumenten	10

4.7.4	Datenablage	10

4.8	Prozesse im Projekt	11

4.8.1	Dokumenten-Review	11

4.8.2	Freigabe	11

4.8.3	Design-Review	11

4.8.4	Design-Freeze	11

4.8.5	Entscheidungsvorbereitungen	11

4.8.6	Entscheidungsblatt	11

4.8.7	Materialbeschaffung	11

4.9	Umgebungsbedingungen	12

4.9.1	Projektraum	12

4.10	Spielregeln im Projekt	12

4.10.1	Regelmeetings Entwicklung	12

4.10.2	Regelmeetings Projektleitung	12

4.10.3	Emails	13

4.10.4	Berichtswesen	13

4.10.5	Umgang mit erkannten Risiken	13

4.10.6	OPL (open points list)	13

4.10.7	Arbeitszeit	13

4.10.8	Urlaubsplanung	13

5	Änderungshistorie	14

Tabellenverzeichnis

Tabelle 1: Änderungshistorie

Abbildungsverzeichnis

Abbildung 1: Projekt-Organigramm

Abbildung 2: Terminplan

Abkürzungen

MAB	Müller Apparatebau Kranzberg

EE	Elektrik / Elektronik

Nr.	Nummer

z.B.	zum Beispiel

OPL	open points list

V	Version

HMI	human machine interface

GUI	graphical user interface

R&D	research and development (Entwicklungsabteilung)

Scope / Ziel

Dieses Dokument beschreibt die notwendigen Bedingungen und Regeln, das Projekt <Name des Projektes> mit einem definierten Projekt-Team zu bearbeiten.

Nutzung der Ergebnisse

Dieses Dokument hat den Nutzen, die Erwartungshaltungen eines jeden Projekt-Team Mitgliedes und des Projektleiters klarzustellen und somit die Effizienz im Projektverlauf zu steigern.

Informations-Quelle

Die Inhalte dieses Dokumentes stammen aus folgenden Quellen:

Erfahrungen M. Grzan

Das Projekt

Systembeschreibung

Kunde:

Maschine / System macht was?

Angaben zum groben Verständnis des Produktes / des Systems

Übersicht Module

Angabe von Modulen oder Sub-Systemen

Entwicklungsstufen

Beschreibung der Entwicklungsstufen

Organisation

Projekt-Team

Projektleiter

Systemingenieur (System-Eng.)

Systementwickler Mechanisches Design

Systementwickler Elektrisches Design Hardware

Systementwickler Elektrisches Design Software

Systementwicklung HMI / GUI

Dokumentation

Test und Validierung

Entwicklungsleiter

(weitere bitte aufführen)

Projekt-Organigramm

Dies ist ein Platzhalter. Hier muss das Organigramm für das jeweilige Projekt aktualisiert werden.

Abbildung 1: Projekt-Organigramm

Terminplan

Dies ist ein Platzhalter. Hier muss der Terminplan des jeweiligen Projektes aktualisiert werden.

Abbildung 2: Terminplan

Stakeholder

Kunde

BoD

(weitere bitte aufführen)

Schnittstellen

Produktionsleitung

Produktion Elektrik/Elektronik

Produktion Mechanik

Einkauf

Qualität

(weitere bitte aufführen)

Projekt-Disziplinen

Projektleitung

Um das Projektziel / die Projektziele erreichen zu können, wird eine Projektleitung benötigt.

Dessen Verantwortung ist neben der Einhaltung von Kostenrahmen und Terminen die Führung des Projektteams.

System-Engineer

Fachlich wird die Projektleitung vom System-Engineer unterstützt.

Dieser bringt alle Projektdisziplinen von der fachlichen Seite gesehen ins Ziel.

Er hat den Überblick über alle technischen und funktionalen Anforderungen im Projekt.

EE-HW

Alles, was mit EE-Hardware zu tun hat (z.B. Verkabelung, Schaltpläne, Blockschaltbilder, Komponenten, Steuerungen, Komponenten-Spezifikationen, Stücklisten EE, etc.).

EE-SW

Alles, was mit der Software für die Steuerung zu tun hat (z.B. SPS-Basis-SW, SPS-Appl.-SW, SPS-Initialisierung, Testspezifikationen, Funktionsprüfungen, Reviews, Abnahmen, etc.)

HMI/GUI

Alles, was mit der Bedienung des Operators zur Maschine zu tun hat (z.B. Software-Code-Verwaltung, Ablage, Lieferanten-Steuerung, Spezifikationen, Prüfmechanismen, Reviews, Abnahmen, etc.)

Mechanisches Design

Alles, was konstruktive Dinge beinhaltet (z.B. Metalle, Motoren, Spezifikationen, Bauraum, Stücklisten, etc.).

Test und Validierung

Alles rund um das Thema Komponenten-, Modul- und Systemtests.

Entwicklungsleitung

In Fällen von Eskalationen oder Konflikten oder technischer Entscheidungsfindungen schaltet sich der Entwicklungsleiter mit ein.

Weiterhin hat er die Verantwortung für die Bereitstellung von Ressourcen.

Urlaubsplanung fällt ebenfalls in seinen Bereich.

(weitere bitte aufführen)

Datenhandling im Projekt

Dateinamen

Alle Dateien, die zum Projekt <Projectname> gehören, werden wie folgt benannt:

<Projectname>_<Inhalt_1>_<Inhalt_2>_V1.<file-extension>

Beispiel: DT20_Konzept_Steuerung_V2.pptx

Beispiel: DT21_Konzept_Übergabe_V1.pptx

Beispiel: DT21_Spezifikation_Querschneider_V1.docx

(DT als Beispiel-Projektname)

Email-Kennzeichnungen

Alle Emails, die zum Projekt < Projectname > gehören, werden in der Betreffzeile wie folgt (als Beispiel) benannt:

DT2.0, Konzeptfreigabe

(DT als Beispiel-Projektname)

Projektsprache in Dokumenten

Deutsch

Datenablage

Alle projektspezifischen Dateien und Daten sind in dem vorgesehen Projektordner abzulegen.

Ort unter Laufwerk X://

(Weiteres bitte aufführen)

Prozesse im Projekt

Dokumenten-Review

Alle anfallenden Dokumente -egal ob während der Entwicklung oder für den Kunden- müssen von einem 2. Projektmitglied gegengeprüft werden (Reviews).

Das Review-Ergebnis ist dokumentarisch festzuhalten.

Freigabe

Alle anfallenden Dokumente -egal ob während der Entwicklung oder für den Kunden- müssen von einem berechtigten Freigabe-Verantwortlichen freigegeben werden (aber erst nach den Reviews).

Die Freigabe wird mit Unterschrift oder per Email getätigt.

Design-Review

Interne modulbezogene und interne systembezogene Design-Reviews sind erforderlich, um einen Design-Freeze vorzubereiten.

Zusätzlich hilft dies bei einem Kunden Design Review.

Ergebnisse des Design-Reviews sind zu dokumentieren.

Design-Freeze

Interne modulbezogene und interne systembezogene Design-Freezes sind erforderlich, um definierte, abgeschlossene Entwicklungsstände nachweisen zu können.

Zusätzlich hilft dies bei einem Kunden Design Review.

Ergebnisse des Design-Freeze sind zu dokumentieren.

Entscheidungsvorbereitungen

Wird eine Entscheidung benötigt, wird diese Entscheidung so vorbereitet, dass der Entscheidende die Entscheidung anhand von Sinnhaftigkeit-Termin-Machbarkeit-Kosten treffen kann.

Entscheidungsblatt

Eine projektentscheidende Änderung oder wichtige Entscheidung muss mit einem Entscheidungsblatt festgehalten werden.

Materialbeschaffung

Wird für das Projekt Material benötigt, wird eine schriftliche Bedarfsmeldung erstellt und vom Projektleiter freigegeben.

Inhalt der Bedarfsmeldung ist:

Typenbezeichnung, Nr., Anzahl, Kosten pro Stück

(weitere bitte aufführen)

Umgebungsbedingungen

Projektraum

Nach Möglichkeit sitzen alle Personen, die in dem Projekt mitarbeiten (Entwicklung), in einem Raum.

Um ungestört arbeiten zu können, wird die Tür mit einem Poster oder Kalender oder Sichtschutz beklebt

Spielregeln im Projekt

Generell gilt:

Probleme gibt es nicht, nur Herausforderungen.

Wir lassen uns ausreden.

Wir bleiben sachlich und werden nicht ausfallend.

Wir reden zielführend, klar, eindeutig und auf den Punkt kommend.

Wir hören zu.

Wir denken in Lösungen, nicht in Problemen.

Wir sind pünktlich.

Wir sind zuverlässig.

Wir melden immer zurück, auch dann, wenn ich eine Absprache oder eine Ergebnisbringung nicht einhalten kann.

Wir helfen einander.

Wir reden miteinander, nicht übereinander.

Wir lernen stetig dazu und wenden das Gelernte an.

Wir dürfen Fehler machen, aber nicht zweimal den gleichen Fehler.

In jedem Regeltermin ist der aktuelle Projektplan verfügbar.

Alle nicht-projektbezogenen Anfragen oder Aufgabendelegationen (z.B. durch den Vertrieb oder angrenzende Abteilungen) per Email oder verbal (mündlich) sind nicht anzunehmen.

Diese sind an den Entwicklungsleiter weiterzuleiten.

(weitere bitte aufführen)

Regelmeetings Entwicklung

In dieser Regelrunde treffen sich die Entwickler der Disziplinen und besprechen offene Themen. Die Runde ist nicht gedacht als Diskussionsrunde.

Jede Runde hat das Ziel, offene technische Themen gemeinsam anzusprechen.

Jeder Teilnehmer bereitet sich auf diese Runde in schriftlicher Art vor.

Die Runde wird geleitet von dem System.-Eng. und protokolliert in einer OPL.

Regelmeetings Projektleitung

In dieser Regelrunde treffen sich die Haupt-Entwickler der Disziplinen und geben einen Status an den PL bekannt. Die Runde ist nicht gedacht als Diskussionsrunde.

Jede Runde hat das Ziel, Status abzugeben und gemeinsam Projekt-Risiken (Qualität, Kosten, Termine) anzusprechen.

Die Runde wird geleitet von dem PL und dieser protokolliert in einem Statusbericht.

Emails

Emails sind dazu da, einer Person oder einer Personengruppe eine kurze Info zu senden, nicht aber für technische Darstellungen oder Romane oder Statusberichte gedacht.

Aufgabendelegationen per Email müssen klar an die Personen adressiert werden, die diese übernehmen sollen.

Nach Möglichkeit sind keine Dokumente zu versenden, sondern auf diese im Projekt-Laufwerk zu verweisen.

Berichtswesen

Statusberichte des System-Eng. sind regelmäßig (mind. 1x pro Woche) für alle Disziplinen zu erstellen und an definierter Stelle abzulegen.

Statusberichte des PL‘s sind regelmäßig (mind. 1x pro Woche) für alle Disziplinen zu erstellen und an definierter Stelle abzulegen. Dieser Bericht an die Stakeholder ist als Datei zu versenden.

Umgang mit erkannten Risiken

Wird ein Risiko im Projekt erkannt, wird dieses direkt an den Syst.-Eng. schriftlich gemeldet mit einem Vorschlag zur Gegenmaßnahme.

OPL (open points list)

Es gibt eine vom PL und Sys.-Eng. gemeinsam geführte OPL.

Alle Punkte sind selbstständig von den Entwicklern abzuarbeiten.

In den Statusrunden werden diese offenen Punkte dann nach Ergebnispräsentation geschlossen.

Arbeitszeit

Wenn nichts anderes abgestimmt wurde, gilt die gesetzliche und vertragliche Arbeitszeit.

Private Angelegenheiten (z.B. Handy, Emails, Internet-Surfen, längere private Telefonate) sind zu unterlassen und nur in den vorgesehenen Pausen erlaubt.

Urlaubsplanung

Jedes Projektteam-Mitglied hat frühzeitig (mind. 1 Monat vorher) zusammenhängenden Urlaub (mind. 2 Tage) anzumelden.

Eine Urlaubsplanung während der Projektlaufzeit ist aktuell zu halten und dringend erforderlich, um Kapazitätsengpässe frühzeitig zu erkennen.

Änderungshistorie

Letzte Version: 01

Datum	Version	Autor	Kommentar (ausführlich, verständlich, auf Seite referenziert)
06.12.2019	01	GRZ	Erstellung Template und Ablage im MAB Wiki

Tabelle 1: Änderungshistorie

Dokument Status: vorläufig (vorläufig, freigegeben, Kopie, geändert)