\chapter{Change Management im Projekt}
\label{sec:change_mgmt}

\section{Abgrenzung}
Wir behandeln nur Änderungen an \textbf{Projekt}anforderungen. Änderungen, welche keinen Bezug zum Projekt haben, wie Änderungen an \textbf{Produktiv}systemen gehören nicht dazu. Dies können bspw. Ergebnisse von Wartungsfällen, Erweiterungen oder Notfallmassnahmen nach Produktionsproblemen sein.

\section{Grundlagen}
Anforderungen ändern im Laufe der Zeit. Wir Menschen lernen dazu, Situationen ändern sich oder neue Gegebenheiten treten ein. Geänderte Anforderungen haben immer Auswirkung auf die Spezifikation. Sie können jedoch auch massive Auswirkung auf folgende Elemente haben:
\begin{itemize}
	\item Projektziel, Funktionalität des Zielsystems
	\item Architektur
	\item Projektdauer
	\item Projektkosten und Projektfolgekosten (Betrieb)
\end{itemize}

\textbf{Scope Creep} ist einer der häufigsten Gründe warum Projekte scheitern. In diesem Zusammenhang geraten die Anforderungen ausser Kontrolle, wenn unkontrollierte Änderungen zugelassen werden. Dies im Auge zu behalten ist daher sehr wichtig, besonders bei Festpreisprojekten.

Merksatz: \textit{''Wer alles reinlässt, kann nicht ganz dicht sein.''}. Unabgestimmte Änderungen am Projektrahmen (Spezifikation, Planung) sind absolut \textbf{verboten}.

\section{Ziele}
\begin{description}
	\item[Hemmschwelle] Bewusste Schwelle gegenüber unvermittelten Änderungen aufbauen. Jeder Änderungswunsch muss über die ''Latte''. So weiss jeder, dass man nicht einfach kommen kann und noch das und jenes ''gratis'' beantragen kann.
	\item[Angemessen behandeln] Änderungswünsche werden angemessen behandelt. Machbare Änderungen werden berücksichtigt, die Konsequenzen auf Scope, Budget und Zeit ist mit allen Betroffenen abgesprochen. Alle nicht machbaren Änderungen werden herausgehalten und am besten auch klar kommuniziert.
\end{description}

\section{Verfahren}
\label{sec:change_mgmt_verfahren}

\begin{itemize}
	\item Zu jedem Projekt gehören klare Festlegungen wie ein Change Requests abgewickelt wird.
	\item Solche Verfahren und die dazugehörigen Checklisten lassen sich in der Regel wiederverwenden.
\end{itemize}

Nachfolgen mögliche Checkliste bzw. ein Verfahren wie ein Change Management aufgesetzt werden könnte:
\begin{itemize}
	\item Es wird eine Gesamtliste aller beantragten CRs geführt einschliesslich Status jedes einzelnen CRs.
	\item Für jeden beantragten CR wird ein eigenes Dokument erstellt, in dem Folgendes festgehalten wird:
	\begin{itemize}
		\item Eindeutiger Identifikator des CRs
		\item Änderungshistorie des Dokuments
		\item Genaue Beschreibung der gewünschten Änderung. Hierzu gehören
		auch die Versionsnummern der betroffenen Dokumente, d. h. der
		Bezugspunkt für die beantragte Änderung!
		\item Machbarkeit (K. O.-Kriterium)
		\item Auswirkungen (Spezifikation und alle anderen betroffenen Dokumente, Aufwand (auch Gesamtprojekt), Kosten, Termine)
		\item Risiken
		\item Ziel-Release (wann soll der CR ausgeliefert werden?)
	\end{itemize}
	\item Festlegung, wer einen CR beantragen darf.
	\item Festlegung von Kriterien, wann ein CR vorliegt und wer entscheidet, ob ein CR vorliegt.
	\item Festlegung, wer über die Implementierung eines CRs entscheidet; die	Entscheidungsträger unterzeichnen dazu das CR-Formular.
	\item Die Annahme eines CRs führt zur konsequenten Änderung von Projektplan und Spezifikation, dann zur Implementierung.
	\item Gegebenenfalls Fristen für die Durchführung der einzelnen Schritte des CR Verfahrens (nicht zwingend).
\end{itemize}

