- Benutzerbeiträge [de-ch]

Projektmanagement Grundlagen

2019-12-08T12:20:12Z

PeterChristen: /* Gängige Methoden im agilen Projektmanagement */

__NOTOC__
[[IT-Projektmanagement]]
==Projektmanagement Grundlagen==
===Was ist ein Projekt===
Nach DIN 69901 wird ein Projekt wie folgt definiert: 

„Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation.“

===Projektmanagement Modelle===
Ganz grundsätzlich werden heute im Projektmanagement zwei Hauptmodelle unterschieden:
* Das klassische Projektmanagement → Sehr starr, aber mit einer hohen Planungssicherheit
* Das agile Projektmanagement → Sehr dynamisch, dafür mit einer hohen Flexibilität

Alle Modelle haben aber die grundlegenden Charakteristiken von Projekten gemeinsam:
* Ein Projekt hat einen Startzeitpunkt und einen Endzeitpunkt
* Ein Projekt ist ein in sich geschlossenes, einmaliges Vorhaben

====Klassisches Projektmanagement====
Der bekannteste Vertreter dieser Gattung ist das Wasserfall-Model. Die Idee hierbei ist, ein Projekt Phase um Phase, wie ein Wasserfall, abzuarbeiten. Es ist nicht vorgesehen, wieder in vergangene Phasen zurückzuspringen. D.h. das Projekt verläuft immer starr in eine Richtung.
Somit hat ein Projekt nach dem Wasserfall-Model fixe Phasen, welche einen klaren Start- und Endzeitpunkt haben.
{| class="wikitable"
|-
| Phasen || Analyse || Entwicklung || Umsetzung || Testing || Rollout
|-
| Aufwand || Hoch || Hoch || Mittel || Gering || Gering
|}

Bei solchen Projekten ist es somit wichtig, dass während der Analysephase genau überlegt wird, was man machen will, während in der Planungs-/Entwicklungsphase genau definiert werden muss, wie man es machen will. D.h. man erstellt eine klare Spezifikation, welche dann in der Umsetzungsphase entsprechend umgesetzt wird. Nach einem kurzen Testing und dem Beheben von allfälligen Fehlern geht des Produkt in den Rollout (auf den Markt, in die Produktion etc.). Erste Priorität hat in solchen Projekten die geplanten Funktionalitäten zum geplanten Zeitpunkt umzusetzen, wenn nötig zu einem höheren Preis oder einer reduzierten Qualität. 

Vorteile des Wasserfall-Modells
* Der Kunde weiss genau was er kriegt
* Bei sich wiederholenden Projekten (z.B. Bauprojekten) fällt die Analyse- und Planungs-/Entwicklungsphase nur einmal an, danach muss nur noch die Umsetzung mit dem Testing und Rollout wiederholt werden
* Es besteht ein klarer Projektplan mit fixen Laufzeiten, Kosten und klar definierten Terminen

Nachteile des Wasserfall-Modells
* Denkfehler während der Analyse oder Planungs-/Entwicklungsphase werden oft erst mach dem Rollout entdeckt
* Es kann kaum auf Veränderungen von Anforderungen im Markt oder beim Kunden reagiert werden
* Es besteht eine hohe Gefahr, dass das ganze Projekt in den "Sand" gesetzt wird, da der Kunde in der Regel sehr spät involviert wird, oder weil sich die Anforderungen im Verlauf des Projektes verändert haben. 

Mögliche Einsatzgebiete für das Wasserfall-Model
* Ein klassisches Einsatzgebiet für das Wasserfall-Model ist die Baubranche. Dies deshalb, weil hier verschiedene Akteure ihre Arbeiten in einer bestimmten Reihenfolge zu einem bestimmten Zeitpunkt erledigt haben müssen. So kann der Maler z.B. mit seiner Arbeit erst anfangen, wenn der Maurer die Wand erstellt und der Elektriker die Stromkabel eingezogen hat.
* Bei jedem Vorhaben mit Werkverträgen, da hier ein klar definiertes Werk zu einem klar definierten Zeitpunkt und einem fixen Preis abgeliefert werden muss.

====Agiles Projektmanagement====
Unter agilem Projektmanagement summieren sich alle Projekte, welche mit agil, lean etc. bezeichnet werden. Hiervon gibt es eine ganze Reihe von Modellen. Gemeinsam haben sie aber alle, dass sie sich auf eine hohe Flexibilität durch kurze Schritte (Iterationen) fokussieren. Die Phasen sind meistens dieselben, aber der Ablauf und die Verteilung des Aufwandes ist ganz anders.

{|
|-
|
[[File:AgilesProjektmanagement.png|left|750px]]
|}

In agilen Projekten wird das Ergebnis in Etappen (Sprints, Iterationen) erarbeitet. Nach einer kurzen Analysephase wird ein sogenanntes "Minimum Viable Product" (minimal überlebensfähiges Produkt) geplant. Dies ist die erste minimal funktionsfähige Iteration eines Produkts, welches entwickelt werden muss, um mit minimalem Aufwand den Kunden-, Markt- oder Funktionsbedarf zu decken und handlungsrelevantes Feedback zu gewährleisten. Basierend auf diesen (Kunden)-Feedbacks werden dann die weiteren Funktionen entwickelt. Das Ziel ist somit, möglichst nahe am Kunde zu sein und möglichst schnell etwas funktionsfähiges in der Hand zu haben. Im Gegensatz zum klassischen Projektansatz, reduziert man bei agilen Projekten lieber die Features oder Funktionalität anstatt die Laufzeit zu verlängern oder die Kosten zu erhöhen.

==== Gängige Methoden im agilen Projektmanagement ====
Es gibt viele verschiedene agile Projektmethoden, welche sich aber im Kern kaum gross unterscheiden und meist einfach einen anderen Fokus haben. Hier einige Beispiele: 

{| class="wikitable"
|-
! Methode !! Erklärung
|-
| DSDM ||
Die Dynamic systems development method (DSDM) ist der Ansatz, wie er bei Educa verfolgt wird. Es ist ein in sich geschlossenes Regelwerk mit klar definierten Prinzipien, Phasen und Rollen. Dieser Ansatz wurde 1994 entwickelt und ist somit wohl die erste und älteste agile Projektmanagementmethode. Dieser Ansatz umfasst das gesamte Projekt vom Anfang bis zum Schluss.
|-
| Lean ||
Lean kommt aus der japanischen Autoindustrie aus der Zeit nach dem Zweiten Weltkrieg, als die Ressourcen sehr knapp waren. Daher liegt der Hauptfokus in diesem Ansatz darin, unnötige Arbeiten (Waste) zu vermeiden und alle Aktivitäten vollumfänglich auf das Endprodukt auszurichten. Auch werden in diesem Ansatz die Menschen (Projektmitarbeiter) und ihre Fähigkeiten in das Zentrum gestellt. Die Grundlage des Strebens nach Perfektion ist die Vision, die dem Projekt zugrunde liegt. Dieser Ansatz umfasst das gesamte Vorhaben vom Anfang bis zum Schluss. Es muss aber nicht zwingend ein explizites Projekte sein.
|-
| Kanban ||
Kanban kommt ebenfalls aus der japanischen Autoindustrie aus der Zeit nach dem Zweiten Weltkrieg. Obwohl es auch die Werte aus Lean beinhaltet, liegt der Fokus mehr auf einer klaren Planung und Visualisierung der Produktion. Alle Produktionsschritte werden auf einer Wand aufgezeichnet und es wird klar definiert, zu welchem Zeitpunkt wie viele Produkte (Min./Max.) in den jeweiligen Schritten in Arbeit sein dürfen. Dabei geht es darum, den Materialfluss gut planen zu können, einen stehen Produktionsfluss zu gewähren und die Lagerkosten möglichst tief halten zu können. Kanban konzentriert sich primär auf Teams in einer Produktionsumgebung.
|-
| Scrum ||
Dieser Ansatz wird heute vor allem in der Softwareentwicklung angewendet und hat viele Parallelen zu Lean Production. Der Fokus liegt hier aber mehr darin, Produktinkremente in kleinen Teilschritten (Sprints) iterativ zu erstellen. Die Sprints und Abläufe sind klar definiert und werden in fixe Zeitspannen (meist zwei Wochen) aufgeteilt. Zudem gibt es klar definierte Rollen und Meetings. Die Grundlagen dieses Rahmenwerk sind im "Scrum Guide" beschreiben (http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf). Scrum wird sehr häufig mit anderen Methoden wie z.B. Kanban, XP etc. kombiniert. Scrum ist auf den Einsatz von Teams mit spezifischen Grössen zugeschnitten.
|-
| SaFE ||
Das Scaled Agile Framework for EnterpriseTM (SAFe) ist ähnlich wie DSDM ein in sich geschlossenes Regelwerk. Im Gegensatz zu den meisten anderen agilen Methoden, welche primär auf einzelne kleine, voneinander getrennten Teams oder Vorhaben zugeschnitten sind, bietet SAFe eine umfassende Beschreibung zu allen Rollen, Teams, Tätigkeiten etc. welche für ein ganzes Unternehmen nötig sind. Es beinhaltet die Lean, Kanban und Scrum Ansätze, bettet diese aber in eine abgestimmte Organisation ein.
|}

Die meisten agilen Ansätze orientieren sich heute am Agilen Manifest (Agile Manifesto) welches vier Basisregeln propagiert:
* Individuen und Interaktionen stehen über Prozessen und Werkzeugen
* Funktionierende Software steht über einer umfassenden Dokumentation
* Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
* Reagieren auf Veränderung steht über dem Befolgen eines Plans
Obwohl die Werte auf der rechten Seite wichtig sind, werden die Werte auf der linken Seite höher eingeschätzt. [http://agilemanifesto.org/iso/de/manifesto.html Agiles Manifesto] 

Vorteile von agilen Projektmethoden
* Es kann sehr schnell auf Veränderungen reagiert werden
* Der Kunde ist schon sehr früh in die Entwicklung eingebunden
* Das Projekt orientiert sich an den Bedürfnissen des Kunden und folgt nicht einem starren Plan
Nachteile von agilen Projektmethoden
* Agile Projektmethoden brauchen ein hohes Mass an Eigenverantwortung, da sie praktisch alle keine strikten Linienorganisation, sondern sehr flache Strukturen verfolgen. In sehr hierarchischen Organisationen kann dies zu Konflikten führen.
* In einem Vorhaben mit starken zeitlichen Abhängigkeiten und vertraglichen Verpflichtungen tun sich agile Methoden schwer, da ihr Fokus auf den einzelnen Inkrementen und einer möglichst effizienten Umsetzung liegt und weniger auf dem Gesamtprojekt.
* Agile Teams/Projekte zu bilden braucht viel Zeit, da es hierbei nicht nur um eine Methode sondern auch um eine Denkweise und Kultur geht, welche zuerst entstehen muss.
Mögliche Einsatzgebiete für agilen Methoden
* Das Hauptgebiet ist klar die Softwareentwicklung
* Auch im Umfeld von Dienstleistungen kommen immer wie mehr Projekte oder Abläufe nach agilen Methoden zum Einsatz
Organisationen für das Projektmanagement
* Project Management Institute [http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-pmi PMI]
* International Project Management Association [http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-ipma IPMA]
* Länderspezifische Ansätze:
** [http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-prince2 PRINCE2], England
** [http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-hermes HERMES 5], Schweiz
** [http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-v-modell V-Modell XT], Deutschland

Projektmanagement Grundlagen

2019-12-08T12:19:02Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==Projektmanagement Grundlagen==
===Was ist ein Projekt===
Nach DIN 69901 wird ein Projekt wie folgt definiert: 

„Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation.“

===Projektmanagement Modelle===
Ganz grundsätzlich werden heute im Projektmanagement zwei Hauptmodelle unterschieden:
* Das klassische Projektmanagement → Sehr starr, aber mit einer hohen Planungssicherheit
* Das agile Projektmanagement → Sehr dynamisch, dafür mit einer hohen Flexibilität

Alle Modelle haben aber die grundlegenden Charakteristiken von Projekten gemeinsam:
* Ein Projekt hat einen Startzeitpunkt und einen Endzeitpunkt
* Ein Projekt ist ein in sich geschlossenes, einmaliges Vorhaben

====Klassisches Projektmanagement====
Der bekannteste Vertreter dieser Gattung ist das Wasserfall-Model. Die Idee hierbei ist, ein Projekt Phase um Phase, wie ein Wasserfall, abzuarbeiten. Es ist nicht vorgesehen, wieder in vergangene Phasen zurückzuspringen. D.h. das Projekt verläuft immer starr in eine Richtung.
Somit hat ein Projekt nach dem Wasserfall-Model fixe Phasen, welche einen klaren Start- und Endzeitpunkt haben.
{| class="wikitable"
|-
| Phasen || Analyse || Entwicklung || Umsetzung || Testing || Rollout
|-
| Aufwand || Hoch || Hoch || Mittel || Gering || Gering
|}

Bei solchen Projekten ist es somit wichtig, dass während der Analysephase genau überlegt wird, was man machen will, während in der Planungs-/Entwicklungsphase genau definiert werden muss, wie man es machen will. D.h. man erstellt eine klare Spezifikation, welche dann in der Umsetzungsphase entsprechend umgesetzt wird. Nach einem kurzen Testing und dem Beheben von allfälligen Fehlern geht des Produkt in den Rollout (auf den Markt, in die Produktion etc.). Erste Priorität hat in solchen Projekten die geplanten Funktionalitäten zum geplanten Zeitpunkt umzusetzen, wenn nötig zu einem höheren Preis oder einer reduzierten Qualität. 

Vorteile des Wasserfall-Modells
* Der Kunde weiss genau was er kriegt
* Bei sich wiederholenden Projekten (z.B. Bauprojekten) fällt die Analyse- und Planungs-/Entwicklungsphase nur einmal an, danach muss nur noch die Umsetzung mit dem Testing und Rollout wiederholt werden
* Es besteht ein klarer Projektplan mit fixen Laufzeiten, Kosten und klar definierten Terminen

Nachteile des Wasserfall-Modells
* Denkfehler während der Analyse oder Planungs-/Entwicklungsphase werden oft erst mach dem Rollout entdeckt
* Es kann kaum auf Veränderungen von Anforderungen im Markt oder beim Kunden reagiert werden
* Es besteht eine hohe Gefahr, dass das ganze Projekt in den "Sand" gesetzt wird, da der Kunde in der Regel sehr spät involviert wird, oder weil sich die Anforderungen im Verlauf des Projektes verändert haben. 

Mögliche Einsatzgebiete für das Wasserfall-Model
* Ein klassisches Einsatzgebiet für das Wasserfall-Model ist die Baubranche. Dies deshalb, weil hier verschiedene Akteure ihre Arbeiten in einer bestimmten Reihenfolge zu einem bestimmten Zeitpunkt erledigt haben müssen. So kann der Maler z.B. mit seiner Arbeit erst anfangen, wenn der Maurer die Wand erstellt und der Elektriker die Stromkabel eingezogen hat.
* Bei jedem Vorhaben mit Werkverträgen, da hier ein klar definiertes Werk zu einem klar definierten Zeitpunkt und einem fixen Preis abgeliefert werden muss.

====Agiles Projektmanagement====
Unter agilem Projektmanagement summieren sich alle Projekte, welche mit agil, lean etc. bezeichnet werden. Hiervon gibt es eine ganze Reihe von Modellen. Gemeinsam haben sie aber alle, dass sie sich auf eine hohe Flexibilität durch kurze Schritte (Iterationen) fokussieren. Die Phasen sind meistens dieselben, aber der Ablauf und die Verteilung des Aufwandes ist ganz anders.

{|
|-
|
[[File:AgilesProjektmanagement.png|left|750px]]
|}

In agilen Projekten wird das Ergebnis in Etappen (Sprints, Iterationen) erarbeitet. Nach einer kurzen Analysephase wird ein sogenanntes "Minimum Viable Product" (minimal überlebensfähiges Produkt) geplant. Dies ist die erste minimal funktionsfähige Iteration eines Produkts, welches entwickelt werden muss, um mit minimalem Aufwand den Kunden-, Markt- oder Funktionsbedarf zu decken und handlungsrelevantes Feedback zu gewährleisten. Basierend auf diesen (Kunden)-Feedbacks werden dann die weiteren Funktionen entwickelt. Das Ziel ist somit, möglichst nahe am Kunde zu sein und möglichst schnell etwas funktionsfähiges in der Hand zu haben. Im Gegensatz zum klassischen Projektansatz, reduziert man bei agilen Projekten lieber die Features oder Funktionalität anstatt die Laufzeit zu verlängern oder die Kosten zu erhöhen.

==== Gängige Methoden im agilen Projektmanagement ====
Es gibt viele verschiedene agile Projektmethoden, welche sich aber im Kern kaum gross unterscheiden und meist einfach einen anderen Fokus haben. Hier einige Beispiele: 

{| class="wikitable"
|-
! Methode !! Erklärung
|-
| DSDM ||
Die Dynamic systems development method (DSDM) ist der Ansatz, wie er bei Educa verfolgt wird. Es ist ein in sich geschlossenes Regelwerk mit klar definierten Prinzipien, Phasen und Rollen. Dieser Ansatz wurde 1994 entwickelt und ist somit wohl die erste und älteste agile Projektmanagementmethode. Dieser Ansatz umfasst das gesamte Projekt vom Anfang bis zum Schluss.
|-
| Lean ||
Lean kommt aus der japanischen Autoindustrie aus der Zeit nach dem Zweiten Weltkrieg, als die Ressourcen sehr knapp waren. Daher liegt der Hauptfokus in diesem Ansatz darin, unnötige Arbeiten (Waste) zu vermeiden und alle Aktivitäten vollumfänglich auf das Endprodukt auszurichten. Auch werden in diesem Ansatz die Menschen (Projektmitarbeiter) und ihre Fähigkeiten in das Zentrum gestellt. Die Grundlage des Strebens nach Perfektion ist die Vision, die dem Projekt zugrunde liegt. Dieser Ansatz umfasst das gesamte Vorhaben vom Anfang bis zum Schluss. Es muss aber nicht zwingend ein explizites Projekte sein.
|-
| Kanban ||
Kanban kommt ebenfalls aus der japanischen Autoindustrie aus der Zeit nach dem Zweiten Weltkrieg. Obwohl es auch die Werte aus Lean beinhaltet, liegt der Fokus mehr auf einer klaren Planung und Visualisierung der Produktion. Alle Produktionsschritte werden auf einer Wand aufgezeichnet und es wird klar definiert, zu welchem Zeitpunkt wie viele Produkte (Min./Max.) in den jeweiligen Schritten in Arbeit sein dürfen. Dabei geht es darum, den Materialfluss gut planen zu können, einen stehen Produktionsfluss zu gewähren und die Lagerkosten möglichst tief halten zu können. Kanban konzentriert sich primär auf Teams in einer Produktionsumgebung.
|-
| Scrum ||
Dieser Ansatz wird heute vor allem in der Softwareentwicklung angewendet und hat viele Parallelen zu Lean Production. Der Fokus liegt hier aber mehr darin, Produktinkremente in kleinen Teilschritten (Sprints) iterativ zu erstellen. Die Sprints und Abläufe sind klar definiert und werden in fixe Zeitspannen (meist zwei Wochen) aufgeteilt. Zudem gibt es klar definierte Rollen und Meetings. Die Grundlagen dieses Rahmenwerk sind im "Scrum Guide" beschreiben (http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf). Scrum wird sehr häufig mit anderen Methoden wie z.B. Kanban, XP etc. kombiniert. Scrum ist auf den Einsatz von Teams mit spezifischen Grössen zugeschnitten.
|-
| SaFE ||
Das Scaled Agile Framework for EnterpriseTM (SAFe) ist ähnlich wie DSDM ein in sich geschlossenes Regelwerk. Im Gegensatz zu den meisten anderen agilen Methoden, welche primär auf einzelne kleine, voneinander getrennten Teams oder Vorhaben zugeschnitten sind, bietet SAFe eine umfassende Beschreibung zu allen Rollen, Teams, Tätigkeiten etc. welche für ein ganzes Unternehmen nötig sind. Es beinhaltet die Lean, Kanban und Scrum Ansätze, bettet diese aber in eine abgestimmte Organisation ein.
|}

Die meisten agilen Ansätze orientieren sich heute am Agilen Manifest (Agile Manifesto) welches vier Basisregeln propagiert:
* Individuen und Interaktionen stehen über Prozessen und Werkzeugen
* Funktionierende Software steht über einer umfassenden Dokumentation
* Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
* Reagieren auf Veränderung steht über dem Befolgen eines Plans
Obwohl die Werte auf der rechten Seite wichtig sind, werden die Werte auf der linken Seite höher eingeschätzt. [http://agilemanifesto.org/iso/de/manifesto.html Agiles Manifesto] 

Vorteile von agilen Projektmethoden
* Es kann sehr schnell auf Veränderungen reagiert werden
* Der Kunde ist schon sehr früh in die Entwicklung eingebunden
* Das Projekt orientiert sich an den Bedürfnissen des Kunden und folgt nicht einem starren Plan
Nachteile von agilen Projektmethoden
* Agile Projektmethoden brauchen ein hohes Mass an Eigenverantwortung, da sie praktisch alle keine strikten Linienorganisation, sondern sehr flache Strukturen verfolgen. In sehr hierarchischen Organisationen kann dies zu Konflikten führen.
* In einem Vorhaben mit starken zeitlichen Abhängigkeiten und vertraglichen Verpflichtungen tun sich agile Methoden schwer, da ihr Fokus auf den einzelnen Inkrementen und einer möglichst effizienten Umsetzung liegt und weniger auf dem Gesamtprojekt.
* Agile Teams/Projekte zu bilden braucht viel Zeit, da es hierbei nicht nur um eine Methode sondern auch um eine Denkweise und Kultur geht, welche zuerst entstehen muss.
Mögliche Einsatzgebiete für agilen Methoden
* Das Hauptgebiet ist klar die Softwareentwicklung
* Auch im Umfeld von Dienstleistungen kommen immer wie mehr Projekte oder Abläufe nach agilen Methoden zum Einsatz
Organisationen für das Projektmanagement
* Project Management Institute [ http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-pmi PMI ]
* International Project Management Association [ http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-ipma IPMA ]
* Länderspezifische Ansätze:
** [ http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-prince2 PRINCE2 ], England
** [ http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-hermes HERMES 5 ], Schweiz
** [ http://www.guteprojekte.ch/grundlagen/projektmanagement-methoden/methoden-v-modell V-Modell XT ], Deutschland

Projektmanagement Grundlagen

2019-12-08T12:06:14Z

PeterChristen: /* Agiles Projektmanagement */

Datei:AgilesProjektmanagement.png

2019-12-08T12:02:34Z

PeterChristen: PeterChristen lud eine neue Version von Datei:AgilesProjektmanagement.png hoch

Projektmanagement Grundlagen

2019-12-08T12:01:43Z

PeterChristen: /* Agiles Projektmanagement */

Projektmanagement Grundlagen

2019-12-08T11:55:31Z

PeterChristen:

Datei:AgilesProjektmanagement.png

2019-12-08T11:47:08Z

PeterChristen:

Projektmanagement Grundlagen

2019-12-08T11:46:48Z

PeterChristen:

Projektmanagement Grundlagen

2019-12-07T15:55:39Z

PeterChristen:

Projektmanagement Grundlagen

2019-12-07T15:54:54Z

PeterChristen:

Projektmanagement Grundlagen

2019-12-07T15:53:39Z

PeterChristen: Die Seite wurde neu angelegt: «__NOTOC__ IT-Projektmanagement ==Projektmanagement Grundlagen== ===Was ist ein Projekt=== Nach DIN 69901 wird ein Projekt wie folgt definiert: „Ein Pr…»

IT-Projektmanagement

2019-12-07T15:39:53Z

PeterChristen: /* Wichtige Links: */

__NOTOC__
{{ITPT-Navigation}}

{|class="wikitable" style="width: 100%;"
|- style="vertical-align:top;
|
==Übersicht==
Kontrollstrukturen II + Anwendungen 
Kontrollstrukturen III, Datei-I/O 
Kontrollstrukturen IV, Arrays 
Funktionen und Signale 
Fallstudie
| style="width: 50%" |

== Wichtige Links: ==
[http://www.hermes.admin.ch/onlinepublikation/index.xhtml Hermes5 Online] 
[https://www.isb.admin.ch/dam/isb/de/dokumente/themen/hermes/Hermes_Handbuch_IH.pdf.download.pdf/Hermes_Handbuch_IH.pdf Hermes5 PDF Download] 
 
[[ Projektmanagement Grundlagen ]] 
[[ Stakeholder Analyse ]] 
[[ Umfeldanalyse ]] 
[[ Performance Matrix ]] 
[[ Key Performance Indicators ]] 
[[ Kritische Erfolgsfaktoren ]] 
[[ Risk Management ]] 
|}

Risk Management

2019-12-07T15:34:34Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==ISO 31000:2018==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben, bestehend aus: 
* Anwendungsbereich, Kontext und Kriterien 
* Risikobeurteilung 
** Risikoidentifizierung -> Erfassen in einer Risikoliste
** Risikoanalyse -> Was ist das Problem
** Risikobewertung -> Was ist die Auswirkung
* Risikobehandlung 
* Risikoüberwachung 
* Risikoberichterstattung 

|style="text-align: center"| [[File:iso31000.png|center|300px]] ISO31000:2018 Prozess
|}

===Risiken Identifizieren ===
Um überhaupt eine Liste von Risiken zu erhalten, eignet sich ein Brainstorming ganz gut. Die so gefundenen Risiken können anschliessend im Team besprochen und analysiert, bewertet und behandelt werden. Um Risiken oder Ursachen zu erörtern gibt es verschiedene Methoden. Hier ein Beispiel: 

==== Methode Fehlerbaumanalyse (Fault Tree Analysis), nach DIN 25424 ====
Die Fehlerbaumanalyse baut auf der sogenannten negativen Logik auf. Das heißt, der Fehlerbaum beschreibt eine Ausfallsfunktion die bei dem Zustand logisch-1 einen Ausfall ausdrückt, bei logisch-0 liegt ein funktionsfähiges System vor. Hier werden die selben Symbole verwendet wie in der Digitalelektronik. Mit dieser Methode können kausale Zusammenhänge dargestellt werden.
{|
|-
|
[[File:FaultTreeAnalysis.png|left|500px]]
|}

===Berechnung von Risiken===
Oft werden Risiken in Form eines Frankenbetrages ausgewiesen. Solche Berechnungen erfolgen meist nach dieser Formel:
* Risikobetrag = Wahrscheinlichkeit des Eintretens x Kostenfolgen bei Eintritt 
Bei einem wahrscheinlichen Schadensfall von Fr. 100'000.- und einem wahrscheinlichen Eintreten von 80% ergibt dies somit ein Risikobetrag von:
* Fr. 80'000.- (80% x Fr. 100'000.-)

===Risiko Behandlung===
Sind die Risiken erkannt, analysiert und bewertet, kann eine entsprechende Behandlung geplant werden. Hierbei wird zwischen dem Initialrisiko und dem Restrisiko unterschieden. 

Beispiel
* Ein Mitarbeiter hat erkannt, dass die bestehende Version der Buchhaltungssoftware keine XML-Daten verarbeiten kann.
* Ohne diese XML-Verarbeitung können keine Verrechnungen aus "bookwell" direkt in die FIBU übermittelt werden.
* Dies wird ein Problem bei der Inbetriebnahme von "bookwell" sein.
Entsprechend muss dieses Risiko behandelt werden.

{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}

Das Resultat dieser Risikobehandlung sieht somit wie folgt aus:
* Initialrisiko: Sehr Hoch 
* Restrisiko: Mittel
Nun muss der Auftraggeber entscheiden, ob er dieses Restrisiko so tragen will.

===Risikomatrix===
Die so behandelten Risiken können am Schluss in einer Risikomatrix eingetragen werden.
{|
|-
|
[[File:Risikomatrix.png|left|500px]]
|}

== Methode des Grösstmöglichen Schadens ==
Es kann Situationen geben, in welchen gewisse Tasks oder Vorhaben so viele Risiken haben, dass es nicht mehr Zielführend ist, diese alle aufzuführen. In solchen Fällen eignet sich auch die Methoden des Grösstmöglichen Schadens.
* Hierbei wird beurteilt, welches der grösste mögliche Schaden ist, welcher mit dem entsprechenden Vorhaben verursacht werden kann.
* Anschliessend werden verschiedene Szenarien geklärt:
** Welche Möglichkeiten gibt es, beim Eintreten des Risikos wieder zurück auf eine stabile Ausgangslage zu kommen
** Welche flankierenden Massnahmen sind möglich um den Schaden zu reduzieren
** Gibt es alternative Vorgehensweisen
* Wurden alle diese Punkte geklärt, entscheidet das Team ob es nun dieses Risiko eingehen will

Risk Management

2019-12-07T15:30:24Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==ISO 31000:2018==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben, bestehend aus: 
* Anwendungsbereich, Kontext und Kriterien 
* Risikobeurteilung 
** Risikoidentifizierung -> Erfassen in einer Risikoliste
** Risikoanalyse -> Was ist das Problem
** Risikobewertung -> Was ist die Auswirkung
* Risikobehandlung 
* Risikoüberwachung 
* Risikoberichterstattung 

|style="text-align: center"| [[File:iso31000.png|center|300px]] ISO31000:2018 Prozess
|}

===Risiken Identifizieren ===
Um überhaupt eine Liste von Risiken zu erhalten, eignet sich ein Brainstorming ganz gut. Die so gefundenen Risiken können anschliessend im Team besprochen und analysiert, bewertet und behandelt werden. Um Risiken oder Ursachen zu erörtern gibt es verschiedene Methoden. Hier ein Beispiel: 

==== Methode Fehlerbaumanalyse (Fault Tree Analysis), nach DIN 25424 ====
Die Fehlerbaumanalyse baut auf der sogenannten negativen Logik auf. Das heißt, der Fehlerbaum beschreibt eine Ausfallsfunktion die bei dem Zustand logisch-1 einen Ausfall ausdrückt, bei logisch-0 liegt ein funktionsfähiges System vor. Hier werden die selben Symbole verwendet wie in der Digitalelektronik. Mit dieser Methode können kausale Zusammenhänge dargestellt werden.
[[File:FaultTreeAnalysis.png|left|500px]]
 

===Berechnung von Risiken===
Oft werden Risiken in Form eines Frankenbetrages ausgewiesen. Solche Berechnungen erfolgen meist nach dieser Formel:
* Risikobetrag = Wahrscheinlichkeit des Eintretens x Kostenfolgen bei Eintritt 
Bei einem wahrscheinlichen Schadensfall von Fr. 100'000.- und einem wahrscheinlichen Eintreten von 80% ergibt dies somit ein Risikobetrag von:
* Fr. 80'000.- (80% x Fr. 100'000.-)

===Risiko Behandlung===
Sind die Risiken erkannt, analysiert und bewertet, kann eine entsprechende Behandlung geplant werden. Hierbei wird zwischen dem Initialrisiko und dem Restrisiko unterschieden. 

Beispiel
* Ein Mitarbeiter hat erkannt, dass die bestehende Version der Buchhaltungssoftware keine XML-Daten verarbeiten kann.
* Ohne diese XML-Verarbeitung können keine Verrechnungen aus "bookwell" direkt in die FIBU übermittelt werden.
* Dies wird ein Problem bei der Inbetriebnahme von "bookwell" sein.
Entsprechend muss dieses Risiko behandelt werden.

{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}

Das Resultat dieser Risikobehandlung sieht somit wie folgt aus:
* Initialrisiko: Sehr Hoch 
* Restrisiko: Mittel
Nun muss der Auftraggeber entscheiden, ob er dieses Restrisiko so tragen will.

===Risikomatrix===
Die so behandelten Risiken können am Schluss in einer Risikomatrix eingetragen werden. 
[[File:Risikomatrix.png|left|500px]]
 

== Methode des Grösstmöglichen Schadens ==
Es kann Situationen geben, in welchen gewisse Tasks oder Vorhaben so viele Risiken haben, dass es nicht mehr Zielführend ist, diese alle aufzuführen. In solchen Fällen eignet sich auch die Methoden des Grösstmöglichen Schadens.
* Hierbei wird beurteilt, welches der grösste mögliche Schaden ist, welcher mit dem entsprechenden Vorhaben verursacht werden kann.
* Anschliessend werden verschiedene Szenarien geklärt:
** Welche Möglichkeiten gibt es, beim Eintreten des Risikos wieder zurück auf eine stabile Ausgangslage zu kommen
** Welche flankierenden Massnahmen sind möglich um den Schaden zu reduzieren
** Gibt es alternative Vorgehensweisen
* Wurden alle diese Punkte geklärt, entscheidet das Team ob es nun dieses Risiko eingehen will

Risk Management

2019-12-07T15:27:40Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==ISO 31000:2018==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben, bestehend aus: 
* Anwendungsbereich, Kontext und Kriterien 
* Risikobeurteilung 
** Risikoidentifizierung -> Erfassen in einer Risikoliste
** Risikoanalyse -> Was ist das Problem
** Risikobewertung -> Was ist die Auswirkung
* Risikobehandlung 
* Risikoüberwachung 
* Risikoberichterstattung 

|style="text-align: center"| [[File:iso31000.png|center|300px]] ISO31000:2018 Prozess
|}

===Risiken Identifizieren ===
Um überhaupt eine Liste von Risiken zu erhalten, eignet sich ein Brainstorming ganz gut. Die so gefundenen Risiken können anschliessend im Team besprochen und analysiert, bewertet und behandelt werden. Um Risiken oder Ursachen zu erörtern gibt es verschiedene Methoden. Hier ein Beispiel: 

==== Methode Fehlerbaumanalyse (Fault Tree Analysis), nach DIN 25424 ====
Die Fehlerbaumanalyse baut auf der sogenannten negativen Logik auf. Das heißt, der Fehlerbaum beschreibt eine Ausfallsfunktion die bei dem Zustand logisch-1 einen Ausfall ausdrückt, bei logisch-0 liegt ein funktionsfähiges System vor. Hier werden die selben Symbole verwendet wie in der Digitalelektronik. Mit dieser Methode können kausale Zusammenhänge dargestellt werden.
[[File:FaultTreeAnalysis.png|left|500px]]

===Berechnung von Risiken===
Oft werden Risiken in Form eines Frankenbetrages ausgewiesen. Solche Berechnungen erfolgen meist nach dieser Formel:
* Risikobetrag = Wahrscheinlichkeit des Eintretens x Kostenfolgen bei Eintritt 
Bei einem wahrscheinlichen Schadensfall von Fr. 100'000.- und einem wahrscheinlichen Eintreten von 80% ergibt dies somit ein Risikobetrag von:
* Fr. 80'000.- (80% x Fr. 100'000.-)

===Risiko Behandlung===
Sind die Risiken erkannt, analysiert und bewertet, kann eine entsprechende Behandlung geplant werden. Hierbei wird zwischen dem Initialrisiko und dem Restrisiko unterschieden. 

Beispiel
* Ein Mitarbeiter hat erkannt, dass die bestehende Version der Buchhaltungssoftware keine XML-Daten verarbeiten kann.
* Ohne diese XML-Verarbeitung können keine Verrechnungen aus "bookwell" direkt in die FIBU übermittelt werden.
* Dies wird ein Problem bei der Inbetriebnahme von "bookwell" sein.
Entsprechend muss dieses Risiko behandelt werden.

{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}

Das Resultat dieser Risikobehandlung sieht somit wie folgt aus:
* Initialrisiko: Sehr Hoch 
* Restrisiko: Mittel
Nun muss der Auftraggeber entscheiden, ob er dieses Restrisiko so tragen will.

===Risikomatrix===
Die so behandelten Risiken können am Schluss in einer Risikomatrix eingetragen werden. 
[[File:Risikomatrix.png|left|500px]]

== Methode des Grösstmöglichen Schadens ==
Es kann Situationen geben, in welchen gewisse Tasks oder Vorhaben so viele Risiken haben, dass es nicht mehr Zielführend ist, diese alle aufzuführen. In solchen Fällen eignet sich auch die Methoden des Grösstmöglichen Schadens.
* Hierbei wird beurteilt, welches der grösste mögliche Schaden ist, welcher mit dem entsprechenden Vorhaben verursacht werden kann.
* Anschliessend werden verschiedene Szenarien geklärt:
** Welche Möglichkeiten gibt es, beim Eintreten des Risikos wieder zurück auf eine stabile Ausgangslage zu kommen
** Welche flankierenden Massnahmen sind möglich um den Schaden zu reduzieren
** Gibt es alternative Vorgehensweisen
* Wurden alle diese Punkte geklärt, entscheidet das Team ob es nun dieses Risiko eingehen will

Risk Management

2019-12-07T15:25:03Z

PeterChristen: /* Risiken Identifizieren */

__NOTOC__
[[IT-Projektmanagement]]
==ISO 31000:2018==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben, bestehend aus: 
* Anwendungsbereich, Kontext und Kriterien 
* Risikobeurteilung 
** Risikoidentifizierung -> Erfassen in einer Risikoliste
** Risikoanalyse -> Was ist das Problem
** Risikobewertung -> Was ist die Auswirkung
* Risikobehandlung 
* Risikoüberwachung 
* Risikoberichterstattung 

|style="text-align: center"| [[File:iso31000.png|center|300px]] ISO31000:2018 Prozess
|}

===Risiken Identifizieren ===
Um überhaupt eine Liste von Risiken zu erhalten, eignet sich ein Brainstorming ganz gut. Die so gefundenen Risiken können anschliessend im Team besprochen und analysiert, bewertet und behandelt werden. Um Risiken oder Ursachen zu erörtern gibt es verschiedene Methoden. Hier ein Beispiel: 

==== Methode Fehlerbaumanalyse (Fault Tree Analysis), nach DIN 25424 ====
Die Fehlerbaumanalyse baut auf der sogenannten negativen Logik auf. Das heißt, der Fehlerbaum beschreibt eine Ausfallsfunktion die bei dem Zustand logisch-1 einen Ausfall ausdrückt, bei logisch-0 liegt ein funktionsfähiges System vor. Hier werden die selben Symbole verwendet wie in der Digitalelektronik. Mit dieser Methode können kausale Zusammenhänge dargestellt werden.
FaultTreeAnalysis.png

===Berechnung von Risiken===
Oft werden Risiken in Form eines Frankenbetrages ausgewiesen. Solche Berechnungen erfolgen meist nach dieser Formel:
* Risikobetrag = Wahrscheinlichkeit des Eintretens x Kostenfolgen bei Eintritt 
Bei einem wahrscheinlichen Schadensfall von Fr. 100'000.- und einem wahrscheinlichen Eintreten von 80% ergibt dies somit ein Risikobetrag von:
* Fr. 80'000.- (80% x Fr. 100'000.-)

===Risiko Behandlung===
Sind die Risiken erkannt, analysiert und bewertet, kann eine entsprechende Behandlung geplant werden. Hierbei wird zwischen dem Initialrisiko und dem Restrisiko unterschieden. 

Beispiel
* Ein Mitarbeiter hat erkannt, dass die bestehende Version der Buchhaltungssoftware keine XML-Daten verarbeiten kann.
* Ohne diese XML-Verarbeitung können keine Verrechnungen aus "bookwell" direkt in die FIBU übermittelt werden.
* Dies wird ein Problem bei der Inbetriebnahme von "bookwell" sein.
Entsprechend muss dieses Risiko behandelt werden.

{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}

Das Resultat dieser Risikobehandlung sieht somit wie folgt aus:
* Initialrisiko: Sehr Hoch 
* Restrisiko: Mittel
Nun muss der Auftraggeber entscheiden, ob er dieses Restrisiko so tragen will.

===Risikomatrix===
Die so behandelten Risiken können am Schluss in einer Risikomatrix eingetragen werden. 
[[File:Risikomatrix.png|left|500px]]

Datei:FaultTreeAnalysis.png

2019-12-07T15:23:06Z

PeterChristen:

Risk Management

2019-12-07T15:21:08Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==ISO 31000:2018==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben, bestehend aus: 
* Anwendungsbereich, Kontext und Kriterien 
* Risikobeurteilung 
** Risikoidentifizierung -> Erfassen in einer Risikoliste
** Risikoanalyse -> Was ist das Problem
** Risikobewertung -> Was ist die Auswirkung
* Risikobehandlung 
* Risikoüberwachung 
* Risikoberichterstattung 

|style="text-align: center"| [[File:iso31000.png|center|300px]] ISO31000:2018 Prozess
|}

===Risiken Identifizieren ===
Um überhaupt eine Liste von Risiken zu erhalten, eignet sich ein Brainstorming ganz gut. Die so gefundenen Risiken können anschliessend im Team besprochen und analysiert, bewertet und behandelt werden. Um Risiken oder Ursachen zu erörtern gibt es verschiedene Methoden. Hier ein Beispiel: 

==== Methode Fehlerbaumanalyse (Fault Tree Analysis), nach DIN 25424 ====
Die Fehlerbaumanalyse baut auf der sogenannten negativen Logik auf. Das heißt, der Fehlerbaum beschreibt eine Ausfallsfunktion die bei dem Zustand logisch-1 einen Ausfall ausdrückt, bei logisch-0 liegt ein funktionsfähiges System vor. Hier werden die selben Symbole verwendet wie in der Digitalelektronik. Mit dieser Methode können kausale Zusammenhänge dargestellt werden.

===Berechnung von Risiken===
Oft werden Risiken in Form eines Frankenbetrages ausgewiesen. Solche Berechnungen erfolgen meist nach dieser Formel:
* Risikobetrag = Wahrscheinlichkeit des Eintretens x Kostenfolgen bei Eintritt 
Bei einem wahrscheinlichen Schadensfall von Fr. 100'000.- und einem wahrscheinlichen Eintreten von 80% ergibt dies somit ein Risikobetrag von:
* Fr. 80'000.- (80% x Fr. 100'000.-)

===Risiko Behandlung===
Sind die Risiken erkannt, analysiert und bewertet, kann eine entsprechende Behandlung geplant werden. Hierbei wird zwischen dem Initialrisiko und dem Restrisiko unterschieden. 

Beispiel
* Ein Mitarbeiter hat erkannt, dass die bestehende Version der Buchhaltungssoftware keine XML-Daten verarbeiten kann.
* Ohne diese XML-Verarbeitung können keine Verrechnungen aus "bookwell" direkt in die FIBU übermittelt werden.
* Dies wird ein Problem bei der Inbetriebnahme von "bookwell" sein.
Entsprechend muss dieses Risiko behandelt werden.

{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}

Das Resultat dieser Risikobehandlung sieht somit wie folgt aus:
* Initialrisiko: Sehr Hoch 
* Restrisiko: Mittel
Nun muss der Auftraggeber entscheiden, ob er dieses Restrisiko so tragen will.

===Risikomatrix===
Die so behandelten Risiken können am Schluss in einer Risikomatrix eingetragen werden. 
[[File:Risikomatrix.png|left|500px]]

Risk Management

2019-12-07T15:15:30Z

PeterChristen:

Datei:Risikomatrix.png

2019-12-07T15:13:21Z

PeterChristen:

Risk Management

2019-12-07T15:09:34Z

PeterChristen: /* Risiko Behandlung */

Risk Management

2019-12-07T15:08:15Z

PeterChristen: /* ISO 31000:2018 */

Risk Management

2019-12-07T06:34:40Z

PeterChristen: /* Risiko Behandlung */

Risk Management

2019-12-07T06:34:00Z

PeterChristen: /* Risiko Behandlung */

Risk Management

2019-12-06T20:46:44Z

PeterChristen:

Risk Management

2019-12-06T20:45:29Z

PeterChristen: /* Berechnung von Risiken */

Risk Management

2019-12-06T20:44:28Z

PeterChristen: /* ISO 31000:2018 */

Risk Management

2019-12-06T20:43:13Z

PeterChristen: /* Risiko Behandlung */

Risk Management

2019-12-06T20:42:48Z

PeterChristen: /* Risiko Behandlung */

Risk Management

2019-12-06T20:41:05Z

PeterChristen:

Risk Management

2019-12-06T20:10:42Z

PeterChristen: /* ISO 31000:2018 */

Risk Management

2019-12-06T18:43:20Z

PeterChristen: /* Risk Management */

Risk Management

2019-12-06T18:42:35Z

PeterChristen: /* Risk treatment */

__NOTOC__
[[IT-Projektmanagement]]
==Risk Management==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben.
|| [[File:iso31000.png|left|200px]]
|}

===Risk Treatment===
{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}
 
Resultat 
Initialrisiko: Sehr Hoch 
Restrisiko: Mittel

Risk Management

2019-12-06T18:42:10Z

PeterChristen: /* Risk Management */

__NOTOC__
[[IT-Projektmanagement]]
==Risk Management==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben.
|| [[File:iso31000.png|left|200px]]
|}

===Risk treatment===
{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}
 
Resultat 
Initialrisiko: Sehr Hoch 
Restrisiko: Mittel

Datei:Iso31000.png

2019-12-06T18:36:42Z

PeterChristen:

Risk Management

2019-12-06T18:35:51Z

PeterChristen: /* Risk Management */

__NOTOC__
[[IT-Projektmanagement]]
==Risk Management==
{|
|-
|
Die ISO 31000:2018 ist eine ISO-Norm, die sich mit Risikomanagement beschäftigt. Dabei legt die Norm Leitlinien fest, die den Umgang mit Risiken in einer Organisation beschreiben. 
In dieser Norm wird das Risikomanagement als wiederkehrender Prozess beschreiben.
|| sd
|}

{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Vermeiden, Vermindern, Transferieren || Vermindern
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}
 
Resultat 
Initialrisiko: Sehr Hoch 
Restrisiko: Mittel

Risk Management

2019-12-06T18:03:51Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==Risk Management==
Mit der Erörterung der Kritischen Erfolgsfaktoren sollen diejenigen Faktoren bestimmt werden, welche vorhanden oder erreicht sein müssen, damit das Projekt erfolgreich umgesetzt werden kann. 
Jedes Projekt hat seine eigenen spezifischen KEF. Ganz generell lassen sich aber folgende KEF auflisten:
{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Umgehen, Reduzieren, Transferieren || Reduzieren
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}
 
Resultat 
Initialrisiko: Sehr Hoch 
Restrisiko: Mittel

Risk Management

2019-12-06T18:03:35Z

PeterChristen: Die Seite wurde neu angelegt: «__NOTOC__ IT-Projektmanagement ==Risk Management== Mit der Erörterung der Kritischen Erfolgsfaktoren sollen diejenigen Faktoren bestimmt werden, welche vorh…»

__NOTOC__
[[IT-Projektmanagement]]
==Risk Management==
Mit der Erörterung der Kritischen Erfolgsfaktoren sollen diejenigen Faktoren bestimmt werden, welche vorhanden oder erreicht sein müssen, damit das Projekt erfolgreich umgesetzt werden kann. 
Jedes Projekt hat seine eigenen spezifischen KEF. Ganz generell lassen sich aber folgende KEF auflisten:
{| class="wikitable"
|-
! Feld !! Inhalt !! Beispiel
|- style="vertical-align:top"
| Zusammenfassung || Kurzbeschreibung des Risikos || Keine automatische Datenübertragung zu Buchhaltung bei GoLive
|- style="vertical-align:top"
| Auswirkung bei Eintreffen || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Wahrscheinlichkeit des Eintreffens || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Hoch
|- style="vertical-align:top"
| Behandlung des Risikos || Akzeptieren, Umgehen, Reduzieren, Transferieren || Reduzieren
|- style="vertical-align:top"
| Beschreibung der Behandlung || Wie gehen wir das Risiko an… || Ein Upgrade der Buchhaltungssoftware wurde bestellt. -> Task 325
|- style="vertical-align:top"
| Restauswirkung || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Hoch
|- style="vertical-align:top"
| Restwahrscheinlichkeit || Keine, sehr tief, tief, mittel, hoch, sehr hoch || Sehr Tief
|- style="vertical-align:top"
| Notfallplan || Was machen wir wenn… || Daten müssen in CSV-Format exportiert und in Buchhaltung importiert werden
|- style="vertical-align:top"
| Risiko ist eingetreten || Ja, Nein || Nein
|}
 
Resultat
Initialrisiko: Sehr Hoch 
Restrisiko: Mittel

IT-Projektmanagement

2019-12-06T17:47:21Z

PeterChristen:

__NOTOC__
{{ITPT-Navigation}}

{|class="wikitable" style="width: 100%;"
|- style="vertical-align:top;
|
==Übersicht==
Kontrollstrukturen II + Anwendungen 
Kontrollstrukturen III, Datei-I/O 
Kontrollstrukturen IV, Arrays 
Funktionen und Signale 
Fallstudie
| style="width: 50%" |

== Wichtige Links: ==
[http://www.hermes.admin.ch/onlinepublikation/index.xhtml Hermes5 Online] 
[https://www.isb.admin.ch/dam/isb/de/dokumente/themen/hermes/Hermes_Handbuch_IH.pdf.download.pdf/Hermes_Handbuch_IH.pdf Hermes5 PDF Download] 
 
[[ Stakeholder Analyse ]] 
[[ Umfeldanalyse ]] 
[[ Performance Matrix ]] 
[[ Key Performance Indicators ]] 
[[ Kritische Erfolgsfaktoren ]] 
[[ Risk Management ]] 
|}

IT-Projektmanagement

2019-12-03T20:41:00Z

PeterChristen: /* Wichtige Links: */

__NOTOC__
{{ITPT-Navigation}}

{|class="wikitable" style="width: 100%;"
|- style="vertical-align:top;
|
==Übersicht==
Kontrollstrukturen II + Anwendungen 
Kontrollstrukturen III, Datei-I/O 
Kontrollstrukturen IV, Arrays 
Funktionen und Signale 
Fallstudie
| style="width: 50%" |

== Wichtige Links: ==
[http://www.hermes.admin.ch/onlinepublikation/index.xhtml Hermes5 Online] 
[https://www.isb.admin.ch/dam/isb/de/dokumente/themen/hermes/Hermes_Handbuch_IH.pdf.download.pdf/Hermes_Handbuch_IH.pdf Hermes5 PDF Download] 
 
[[ Stakeholder Analyse ]] 
[[ Umfeldanalyse ]] 
[[ Performance Matrix ]] 
[[ Key Performance Indicators ]] 
[[ Kritische Erfolgsfaktoren ]] 
|}

IT-Projektmanagement

2019-12-03T20:40:23Z

PeterChristen:

__NOTOC__
{{ITPT-Navigation}}

{|class="wikitable" style="width: 100%;"
|- style="vertical-align:top;
|
==Übersicht==
Kontrollstrukturen II + Anwendungen 
Kontrollstrukturen III, Datei-I/O 
Kontrollstrukturen IV, Arrays 
Funktionen und Signale 
Fallstudie
| style="width: 50%" |

== Wichtige Links: ==
[http://www.hermes.admin.ch/onlinepublikation/index.xhtml Hermes5 Online] 
[https://www.isb.admin.ch/dam/isb/de/dokumente/themen/hermes/Hermes_Handbuch_IH.pdf.download.pdf/Hermes_Handbuch_IH.pdf Hermes5 PDF Download]
 
[[ Stakeholder Analyse ]] 
[[ Umfeldanalyse ]] 
[[ Performance Matrix ]] 
[[ Key Performance Indicators ]] 
[[ Kritische Erfolgsfaktoren ]] 
|}

IT-Projektmanagement

2019-12-03T20:35:30Z

PeterChristen:

__NOTOC__
{{ITPT-Navigation}}

{|class="wikitable" style="width: 100%;"
|- style="vertical-align:top;
|
==Übersicht==
[[ Stakeholder Analyse ]] 
[[ Umfeldanalyse ]] 
[[ Performance Matrix ]] 
[[ Key Performance Indicators ]] 
[[ Kritische Erfolgsfaktoren ]] 

Kontrollstrukturen II + Anwendungen 
Kontrollstrukturen III, Datei-I/O 
Kontrollstrukturen IV, Arrays 
Funktionen und Signale 
Fallstudie
| style="width: 50%" |

== Wichtige Links: ==
[https://wunnox.ch/fragen/fragen.php?topic=ITBM Fragen] 
[https://wunnox.ch/fragen/uebungen.php?topic=ITBM Übungen]
|}

Key Performance Indicators

2019-12-03T20:34:18Z

PeterChristen: /* Key Performance Indicators (KPI) */

__NOTOC__
[[IT-Projektmanagement]]
==Key Performance Indicators (KPI)==
Mit Key Performance Indicators werden zwei Ziele verfolgt:
# Fortschritte von Projekten messen können
# Projekte miteinander vergleichen können

Jedes Projekt hat seine eigenen spezifischen KPI. Ganz generell lassen sich aber folgende KPI auflisten:
{| class="wikitable"
|-
! Kategorie !! Beispiel
|-
|
* Finanzielle Kennzahlen
* Terminliche Kennzahlen
* Kennzahlen zu Ergebnisqualität
* Kennzahlen zu Projektfortschritt
* Kennzahlen zu Teamperformance

|style="vertical-align:top"|
Budget, Sollkosten, Istkosten, Stückkosten, Earned Value, etc. 
Geplante Termine, aktuelle Termine, Schedule Performance Index, Termintreue, etc. 
Prozentualer Zielerreichungsgrad, Fehlerquote, Anzahl Rückfragen, Aufwand Nachbesserung, etc. 
Prozent Dauer abgeschlossen, Prozent Arbeit abgeschlossen, Fortschrittsgrad, etc. 
Motivationsgrad, Abarbeitungsrate, … 
|}

==Voraussetzung für eine klare Aussage, Messung==
Damit KPI aussagekräftig und verständlich sind, müssen folgende Voraussetzungen geschaffen werden:
* Vollständigkeit der Daten muss sichergestellt sein
* Messbarkeit der Daten (quantitativ/qualitativ) ist gegeben
* Vergleichbarkeit und Nachvollziehbarkeit der Daten ist gegeben
* Verständlichkeit und Widerspruchsfreiheit der Daten ist gegeben
* Standardisierte Nomenklatur der Bezeichnungen ist vereinbart
* Zuordnung der Kennzahlen zu Zielen ist sichergestellt
* Transparenz der Darstellung ist gegeben

Key Performance Indicators

2019-12-03T20:32:53Z

PeterChristen: Die Seite wurde neu angelegt: «__NOTOC__ IT-Projektmanagement ==Key Performance Indicators (KPI)== Mit Key Performance Indicators werden zwei Ziele verfolgt: # Fortschritte von Projekten m…»

__NOTOC__
[[IT-Projektmanagement]]
==Key Performance Indicators (KPI)==
Mit Key Performance Indicators werden zwei Ziele verfolgt:
# Fortschritte von Projekten messen können
# Projekte miteinander vergleichen können
 
Jedes Projekt hat seine eigenen spezifischen KPI. Ganz generell lassen sich aber folgende KPI auflisten:
{| class="wikitable"
|-
! Kategorie !! Beispiel
|-
|
* Finanzielle Kennzahlen
* Terminliche Kennzahlen
* Kennzahlen zu Ergebnisqualität
* Kennzahlen zu Projektfortschritt
* Kennzahlen zu Teamperformance

|style="vertical-align:top"|
Budget, Sollkosten, Istkosten, Stückkosten, Earned Value, etc. 
Geplante Termine, aktuelle Termine, Schedule Performance Index, Termintreue, etc. 
Prozentualer Zielerreichungsgrad, Fehlerquote, Anzahl Rückfragen, Aufwand Nachbesserung, etc. 
Prozent Dauer abgeschlossen, Prozent Arbeit abgeschlossen, Fortschrittsgrad, Fortschrittswert, etc. 
Motivationsgrad, Abarbeitungsrate, … 
|}

==Voraussetzung für eine klare Aussage, Messung==
Damit KPI aussagekräftig und verständlich sind, müssen folgende Voraussetzungen geschaffen werden:
* Vollständigkeit der Daten muss sichergestellt sein
* Messbarkeit der Daten (quantitativ/qualitativ) ist gegeben
* Vergleichbarkeit und Nachvollziehbarkeit der Daten ist gegeben
* Verständlichkeit und Widerspruchsfreiheit der Daten ist gegeben
* Standardisierte Nomenklatur der Bezeichnungen ist vereinbart
* Zuordnung der Kennzahlen zu Zielen ist sichergestellt
* Transparenz der Darstellung ist gegeben

Kritische Erfolgsfaktoren

2019-12-03T20:24:23Z

PeterChristen: /* Kritische Erfolgsfaktoren (KEF) */

__NOTOC__
[[IT-Projektmanagement]]
==Kritische Erfolgsfaktoren (KEF)==
Mit der Erörterung der Kritischen Erfolgsfaktoren sollen diejenigen Faktoren bestimmt werden, welche vorhanden oder erreicht sein müssen, damit das Projekt erfolgreich umgesetzt werden kann. 
Jedes Projekt hat seine eigenen spezifischen KEF. Ganz generell lassen sich aber folgende KEF auflisten:
{| class="wikitable"
|-
! KEF im Einfluss des Projektleiters !! KEF ausserhalb des Einflusses des Projektleiters
|-
|
* Führung (Erfahrung, Methodenkompetenz)
* Projektorganisation (Aufteilung Rollen und Verantwortlichkeiten)
* Team (Fachlich kompetent, Motiviert)
* Planung (Vorausschauend, Abgewogenes Risiko, Zielorientiert)
* Stakeholder Management (Unterstützer, Bremser)
* Kommunikation (Proaktiv, zielgerichtet)
* Best Practices (Pragmatisch, nichts Neues erfinden wo nicht nötig)
|style="vertical-align:top"|
* Projektsteuerung (Überprüfen von KPI, Reporting)
* Verfügbare Ressourcen
* Unterstützung durch Management
* Günstiges Projektumfeld
|}

Kritische Erfolgsfaktoren

2019-12-03T20:23:24Z

PeterChristen: Die Seite wurde neu angelegt: «__NOTOC__ IT-Projektmanagement ==Kritische Erfolgsfaktoren (KEF)== Mit der Erörterung der Kritischen Erfolgsfaktoren sollen diejenigen Faktoren bestimmt wer…»

__NOTOC__
[[IT-Projektmanagement]]
==Kritische Erfolgsfaktoren (KEF)==
Mit der Erörterung der Kritischen Erfolgsfaktoren sollen diejenigen Faktoren bestimmt werden, welche vorhanden oder erreicht sein müssen, damit das Projekt erfolgreich umgesetzt werden kann. 
Jedes Projekt hat seine eigenen spezifischen KEF. Ganz generell lassen sich aber folgende KEF auflisten:
{| class="wikitable"
|-
! KEF im Einfluss des Projektleiters !! KEF ausserhalb des Einflusses des Projektleiters
|-
|
* Führung (Erfahrung, Methodenkompetenz)
* Projektorganisation (Aufteilung Rollen und Verantwortlichkeiten)
* Team (Fachlich kompetent, Motiviert)
* Planung (Vorausschauend, Abgewogenes Risiko, Zielorientiert)
* Stakeholder Management (Unterstützer, Bremser)
* Kommunikation (Proaktiv, zielgerichtet)
* Best Practices (Pragmatisch, nichts Neues erfinden wo nicht nötig)
||
* Projektsteuerung (Überprüfen von KPI, Reporting)
* Verfügbare Ressourcen
* Unterstützung durch Management
* Günstiges Projektumfeld
|}

Performance Matrix

2019-12-03T20:14:38Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==Performance und Potenzial Matrix==
Mit der Performance und Potenzial Matrix lassen sich Projekte in ihrem Lifecycle einstufen.
 
{|
|-
| [[File:PerformanceMatrix.png|left|500px]]
|style="vertical-align:top"|
Einstufung von Projekten:
* Rechts oben, investieren
* Rechts unten, weiterführen
* Links oben, unterstützen
* Links unten, terminieren
 
Nutzen:
* Einstufen der Wichtigkeit
* Planung der Ressourcenzuteilung
* Projekt-Lifecycle

|}

Datei:PerformanceMatrix.png

2019-12-03T20:11:47Z

PeterChristen:

Performance Matrix

2019-12-03T20:09:56Z

PeterChristen: Die Seite wurde neu angelegt: «__NOTOC__ IT-Projektmanagement ==Performance und Potenzial Matrix== Mit der Performance und Potenzial Matrix lassen sich Projekte in ihrem Lifecycle einstufe…»

Umfeldanalyse

2019-12-03T20:06:50Z

PeterChristen:

__NOTOC__
[[IT-Projektmanagement]]
==Umfeldanalyse==
{|
|-
| [[File:Umfeldanalyse.png|left|500px]]
|style="vertical-align:top"|
Eine Umfeldanalyse wird durchgeführt, um:
* „über den Tellerrand zu schauen“
* äußere Einflüsse auf das Projekt zu erkennen
* bereits bestehende Anforderungen zu ermitteln
* eventuelle Probleme zu erkennen
* Schnittstellen nach außen zu identifizieren
* die Stakeholderanalyse vorzubereiten
* die Risikoanalyse vorzubereiten.
 
Hilfreiche Fragen zur Ermittlung von Umfeldfaktoren:
* Worauf müssen wir achten?
* Wo findet das Projekt statt?
* Welche übergeordneten Ziele sind zu beachten?
* Welche Personen(gruppen) können den Erfolg des Projekts beeinflussen?
* Welche rechtlichen Aspekte sind zu berücksichtigen?
|-
|
Aus den Sachlichen Faktoren lassen sich Risiken ableiten 
Aus den sozialen Faktoren lassen sich Stakeholder ableiten.
||
|}