BDD 2007: Planungs-, Erstellungs- und Bereitstellungshandbuch

Planung

Veröffentlicht: 30. Nov 2006

Die Planung ist die erste Phase des gesamten Bereitstellungsprozesses. Die Planungsphase besteht aus mehreren Schritten, von der Beschreibung der Bereitstellungsziele und des Bereitstellungskonzepts bis hin zum Sammeln von Daten und Ressourcen, die das Team während der folgenden Phasen verwenden wird. Der erste Schritt in dieser Phase ist die Beschreibung der Bereitstellung.

Auf dieser Seite

Die Projektbeschreibungsphase Die Projektbeschreibungsphase
Die Planungsphase Die Planungsphase

Die Projektbeschreibungsphase

Die Projektbeschreibungsphase vereinigt das Projektteam unter einer gemeinsamen Vision. Sie gipfelt in einem klar definierten Leistungsumfang und einer Projektstruktur, die die Übereinkunft des Teams und des Kunden über die Richtung des Projekts anzeigt.

Hauptaufgaben

In Tabelle 3 sind die Hauptaufgaben und -ergebnisse in der Projektbeschreibungsphase mit den jeweiligen Besitzern aufgeführt.

Tabelle 3: Hauptaufgaben in der Projektbeschreibungsphase mit ihren Ergebnissen und Besitzern

Hauptaufgaben

Ergebnisse

Besitzer

Zusammenstellen eines Teams

Alle sechs Teamrollen sind vertreten

Produktmanagement, Programmmanagement

Beurteilen der aktuellen Situation

Informationen über die Computerumgebung wurden zusammengetragen

Programmmanagement

Definieren der Geschäftsziele

Problembeschreibungen und Geschäftsziele (Teil des Dokuments zur Festlegung des Konzepts/Umfangs)

Produktmanagement

Erstellen des Konzeptpapiers und Definieren des Projektumfangs

Konzeptpapier und Definition des Projektumfangs (Teil des Dokuments zur Festlegung des Konzepts/Umfangs)

Produktmanagement

Erstellen von Benutzerprofilen

Identifizierung von Benutzern und ihren Anforderungen (Teil des Dokuments zur Festlegung des Konzepts/Umfangs)

Programmmanagement

Entwickeln des Lösungskonzepts

Das Lösungskonzept (Teil des Dokuments zur Festlegung des Konzepts/Umfangs)

Programmmanagement

Erstellen des Dokuments zur Risikoabschätzung

Ein vorläufiges Dokument zur Risikoabschätzung und eine Liste der größten Risiken (die Liste ist Teil des Dokuments zur Festlegung des Konzepts/Umfangs)

Programmmanagement

Festlegen einer Projektstruktur

Ein erster Satz von Standards (Teil des Dokuments zur Festlegung des Konzepts/Umfangs)

Programmmanagement

Abnehmen des Meilensteins

Das Dokument zur Festlegung des Konzepts/Umfangs wurde zusammengestellt, und alle Arbeiten der Projektbeschreibungsphase wurden abgenommen.

Alle Rollen

Schwerpunkte des Teams

In Tabelle 4 sind die wesentlichen Schwerpunktbereiche für die einzelnen Rollencluster während der Projektbeschreibungsphase aufgeführt.

Tabelle 4: Rollencluster und Schwerpunkte in der Projektbeschreibungsphase

Rollencluster

Schwerpunkt

Produktmanagement

  • Ermittlung der Bedürfnisse und Anforderungen des Kunden

  • Dokument zur Festlegung des Konzepts/Umfangs

Programmmanagement

  • Dokumentation der Entwurfsziele

  • Lösungskonzept

  • Projektstruktur

Entwicklung

  • Erstellung von Prototypen

  • Bewertung der Entwicklungs- und Technologieoptionen

  • Machbarkeitsanalyse

Test

  • Teststrategien

  • Testkriterien

  • Berichterstattung

Benutzererfahrung

  • Anforderungen an die Benutzerschulung und zugehörige Auswirkungen

Freigabeverwaltung

  • Bereitstellungsfaktoren

  • Betriebsverwaltung und Supportmöglichkeiten

  • Betriebliche Abnahme

  • Netzwerkermittlung

  • Anwendungs- und Hardwareinventur

  • Zusammenarbeit mit dem IT-Betriebspersonal und dem Feature-Team „Sicherheit“

Das IT-Betriebspersonal und das Feature-Team „Sicherheit“ sollten in die Bewertungen einbezogen werden, um sicherzustellen, dass mit einem genauen Bild ihrer jeweiligen Bereiche gearbeitet wird.

Zwischenmeilenstein

Die Projektbeschreibungsphase des MSF-Prozessmodells umfasst einen Zwischenmeilenstein. Verwenden Sie die Informationen und Verfahren aus diesem Handbuch, um diesen Meilenstein abzuschließen. Dabei handelt es sich um eine nach Priorität geordnete Liste von Anwendungen, für die die Geschäftsführung entschieden hat, sie in die Lösung aufzunehmen.

Feature-Team-Dokumente und Dokumente zur Arbeitshilfe

Die folgenden Dokumente werden in der Projektbeschreibungsphase verwendet:

  • Konzept/Umfang

  • Bewertungsvorlage

  • Deployment Feature-Team Guide

  • Operations Readiness Feature-Team Guide

  • Security Feature-Team Guide

  • Test Feature-Team Guide

Das MSF-Teammodell: Zusammenstellen des Teams

Microsoft hat das MSF-Teammodell über einen Zeitraum von mehreren Jahren hinweg entwickelt, um einige der Nachteile auszugleichen, die durch die hierarchische und lineare Struktur traditioneller Projektteams entstanden. Teams, die nach dem MSF-Teammodell organisiert werden, sind kleine, fachübergreifende Teams, in denen die Mitglieder die Verantwortung teilen und die Fähigkeiten des jeweils anderen ergänzen, um sich entschlossen auf das durchzuführende Projekt zu konzentrieren. Sie teilen eine gemeinsame Projektvision, die Konzentration auf die Bereitstellung des Projekts, hohe Qualitätsstandards (manchmal als Null-Fehler-Denkweise bezeichnet) und die Bereitschaft zu lernen. Das MSF-Teammodell schreibt keinen einzelnen Leiter vor. Die Mitglieder arbeiten als ein Team Gleichberechtigter mit jeweils eigenen festgelegten Rollen zusammen, wobei jede Rolle sich auf andere Schwerpunkte im Prozess konzentriert.

Rollencluster

Das MSF-Teammodell definiert sechs voneinander abhängige, fachübergreifende Rollen oder Rollencluster, die dafür verantwortlich sind, verschiedene Aspekte des Projekts zu implementieren (siehe Abbildung 3). Das Unternehmen kann die aufgeführten Zuständigkeiten passend zum Projekt ändern oder ergänzen, sofern alle sechs Rollen vertreten sind.

Abbildung  3: Das MSF-Teammodell
Rollencluster „Produktmanagement“

Der Produktmanager fungiert im Projektteam als Interessenvertreter des Kunden, indem er sicherstellt, dass das Team die Bedürfnisse des Kunden, seine Sorgen, Fragen und Rückmeldungen während des gesamten Projekts berücksichtigt. Gleichzeitig stellt der Produktmanager die Verbindungsperson des Teams zum Kunden dar, die für die allgemeine Kommunikation und die Steuerung der Erwartungen des Kunden zuständig ist.

In diesem Projekt ist der Produktmanager wahrscheinlich ein IT-Direktor oder eine höherrangige Führungskraft, die bevollmächtigt ist, Entscheidungen über den Projektumfang, die Kosten und die Projektressourcen zu treffen. Der Produktmanager muss über Führungsqualitäten verfügen sowie ehrlich an das Projekt und die aus seiner Umsetzung zu erzielenden Vorteile glauben.

Die Zuständigkeiten des Rollenclusters „Produktmanagement“ für ein BDD 2007-Projekt umfassen:

  • Marketing

  • Wirtschaftlicher Nutzen

  • Vertretung der Kundeninteressen

  • Produktplanung

Hinweis   Der Produktmanager sollte eine schriftliche Beschreibung für jede dieser Zuständigkeiten bereitstellen, damit sie für das restliche Team klar definiert sind.

Rollencluster „Programmmanagement“

Der Programmmanager fungiert als ein „Leiter der Beziehungen“, der die Aktivitäten der anderen Teammitglieder leitet und koordiniert. Der Rollencluster „Programmmanagement“ ist verantwortlich für die Festlegung des Projektzeitplans und für die Berichterstattung zum Projektstatus. Im Gegensatz zum Rollencluster „Produktmanagement“, der die externe Kommunikation zwischen dem Team und dem Kunden erleichtert, ist der Rollencluster „Programmmanagement“ verantwortlich dafür, die interne Kommunikation zwischen den Mitgliedern des Projektteams zu vereinfachen. Zu den Aufgaben des Rollenclusters „Produktmanagement“ gehören die Festlegung der Entwurfsziele, die Leitung der Erstellung der Funktionsbeschreibung und des Projektplans sowie die Koordination der Verwendung von Entwicklungsressourcen durch die Rollencluster „Entwicklung“ und „Test“.

Der Rollencluster „Programmmanagement“ erfordert ein klares Verständnis des gesamten Projekts: welche Aufgaben zu erledigen sind und wie, wann und von wem sie durchzuführen sind. Programmmanager sollten erfahrene Organisatoren sein und über gute technische Kenntnisse verfügen. Sie müssen nicht bis ins kleinste Detail mit der Arbeit des technischen Personals vertraut sein, jedoch über ein ausreichendes technisches Verständnis verfügen, damit sie sachkundig mit den Technikern zusammenarbeiten können.

Rollencluster „Entwicklung“

Die Teammitglieder, die die Entwicklungsrolle einnehmen, sind verantwortlich für das Entwerfen und Erstellen der Basis- und Imagingarchitektur sowie für das Durchführen entsprechender von Komponententests. Hierzu gehört das Schreiben und Anpassen von Skripts, um die unbeaufsichtigte Installation von Windows und 2007 Office System auf allen Hardwareplattformen, die im Projektumfang enthalten sind, zu ermöglichen. Neben der Durchführung der eigentlichen Entwicklungsaufgaben sind die Entwickler verantwortlich für das Dokumentieren ihrer Arbeit, einschließlich der Konfigurationsdetails und Installationsverfahren. Der Rollencluster „Entwicklung“ besteht in Abhängigkeit von der Art und der Komplexität des Projekts oft aus mehreren Personen.

Die Entwickler müssen über ausgezeichnete technische Kenntnisse verfügen sowie mit der Computerarchitektur des Unternehmens vertraut sein und wissen, wie sich Windows und 2007 Office System darin einfügen. Sie müssen zudem mit den bereitzustellenden Produkten, deren Features und den Komponenten, für die sie insbesondere verantwortlich sind, vertraut sein. Besetzen Sie die Rollencluster „Entwicklung“ und „Test“ nicht mit denselben Mitarbeitern, da ansonsten keine angemessene Überprüfung der Entwicklungsarbeit erreicht werden kann.

Entwickler sollten in Abhängigkeit von ihren Zuständigkeiten über Kenntnisse in den folgenden Bereichen verfügen:

  • Erstellung von Batchskripts

  • Kenntnisse in VBScript

  • Vertrautheit mit der Microsoft Windows-Vorinstallationsumgebung (Windows Preinstallation Environment, Windows PE)

  • Windows Setup-Methoden und -Tools

  • Verwendung und Konfiguration von Windows, einschließlich Sicherheit, Richtlinien, Diensten und Netzwerkeinstellungen

  • Verwendung, Bereitstellung, Konfiguration und Verwaltung von 2007 Office System

  • Verwendung des Microsoft Office 2007 Ressource Kit

  • Erstellung von Festplattenabbildern, einschließlich der Verwendung von Sysprep zur Vorbereitung von Datenträgern für die Abbilderstellung

  • Verwendung, Bereitstellung und Konfiguration von Tools zum Erstellen von Datenträgerabbildern

  • Konfiguration von Desktop- und Laptophardware, einschließlich des BIOS

  • Tools zum Verpacken von Anwendungsinstallationen

Der Rollencluster „Entwicklung“ kann für das Bereitstellungsprojekt in Unterteams unterteilt werden, die häufig als Feature-Teamsbezeichnet werden. Hierbei können die einzelnen Feature-Teams beispielsweise für die folgenden Bereiche verantwortlich sein:

  • System zum Erstellen von Computerabbildern

  • Anwendungsverwaltung

  • Wiederherstellung der Anwendungskompatibilität

  • LTI-Bereitstellungsprozess

Rollencluster „Test“

Die Teammitglieder, die den Rollencluster „Test“ ausfüllen, sind verantwortlich für das Testen der Architektur und der zugehörigen Dokumentation gegenüber der Funktionsbeschreibung. Sie stellen außerdem sicher, dass die Dokumentation die im Projektumfang vorgesehenen Anforderungen erfüllt.

Tester sollten Erfahrung auf diesem Gebiet sowie ein Verständnis dafür besitzen, welche Aufgaben mit dem Testen verbunden sind. Dementsprechend sollten sie sehr detailorientiert und technisch versiert sein, über ein Verständnis der Betriebsumgebung verfügen und sich dafür engagieren, Fehler proaktiv zu finden. Die Vertrautheit mit der Windows-Betriebssystemumgebung und den bereitzustellenden Anwendungen ist ein wertvoller Vorteil.

Rollencluster „Benutzererfahrung“

Die Teammitglieder, die den Rollencluster „Benutzererfahrung“ ausfüllen, sind verantwortlich dafür, Schulungs- und Kommunikationsanforderungen für die Benutzer festzulegen. Im Gegensatz zum Rollencluster „Produktmanagement“, der als Interessenvertreter des Kunden fungiert und im Namen der Personen handelt, die das Projekt in Auftrag gegeben haben oder dafür bezahlen, fungiert der Rollencluster „Benutzererfahrung“ als Interessenvertreter der Benutzer und handelt im Namen der Personen, die die Lösung täglich benutzen werden. Bei diesem Projekt ist der Rollencluster „Benutzererfahrung“ auch dafür verantwortlich, die Benutzer darüber zu unterrichten, welche Vorteile die Lösung bietet und wie sie mit ihr ihre Aufgaben effizienter erledigen können.

Experten für Benutzererfahrung sollten mit Benutzern und ihren Tätigkeiten vertraut sein und den Schulungs- und Kommunikationsbedarf der Benutzer einschätzen können. Sie sollten auch in der Lage sein, Schulungsprogramme zu entwickeln und durchzuführen.

Rollencluster „Freigabeverwaltung“

Der Rollencluster „Freigabeverwaltung“ ist verantwortlich für die Koordination der Aktivitäten, die zur Gewährleistung einer erfolgreichen Einführung erforderlich sind, sowie für die Definition und Dokumentation von Strategien und Prozessen für die Lebenszyklusverwaltung. Teammitglieder, die diese Rolle einnehmen, handeln im Team als Interessenvertreter des IT-Betriebspersonals. Dies schließt die Verwaltung von Funktionstests, die Einführung der Lösung und die Unterstützung der Übergabe der Lösung an das für den laufenden Betrieb zuständige Supportpersonal ein.

Der Rollencluster „Freigabeverwaltung“ muss mit der Betriebsumgebung vertraut sein, einschließlich technischem Support und Helpdesk. Die Teammitglieder müssen auch die Auswirkungen verstehen, die die Lösung auf die vorherige Umgebung haben wird.

Der Rollencluster „Freigabeverwaltung“ muss Ressourcen für die Verwaltung der Prozesse zur Computerinventur und Netzwerkanalyse umfassen. Die Teammitglieder stellen sicher, dass diese Informationen an die Entwicklungsteams weitergegeben werden.

Zuweisen von Rollen

Obwohl MSF sechs unterschiedliche Rollencluster für Teams definiert, muss nicht jedes Team aus sechs Personen bestehen. Abhängig von der Art und dem Umfang des Projekts kann das Unternehmen über ein zentrales Projektteam verfügen, das aus mehr oder weniger als sechs Personen besteht, von denen einige vielleicht nur in Teilzeit am Projekt mitarbeiten.

Innerhalb eines großen Unternehmens ist es oft sinnvoll, einige Projektmitglieder eigens für bestimmte Aufgaben abzustellen, um eine robuste und supportfähige Desktoparchitektur zu erstellen. Mitglieder, die dem Team fest zugeordnet wurden, widmen dem Projekt ihre gesamte Zeit und sind nicht für alltägliche betriebliche Abläufe verantwortlich, die nicht Teil des Projekts sind. Innerhalb kleinerer Unternehmen ist diese Vorgehensweise eventuell nicht möglich, und Teammitglieder, die ihre Zeit zwischen dem Projekt und den täglichen Routineaufgaben aufteilen, können auch den Umfang des Projekts verwalten. Berücksichtigen Sie diese Überlegungen, wenn Sie ein Team für das Projekt planen und zusammenstellen.

Das MSF-Teammodell: Skalieren der Teams

Die Größe der Teams hängt weitgehend von der Größe der Bereitstellung und der Komplexität der Zuständigkeitsbereiche jedes Teams ab.

Zusammenstellen kleiner Teams

Für kleine Projekte oder Projekte mit begrenzten Ressourcen sollten Sie ein kleines Kernteam zusammenstellen, in dem wenigstens eines der Mitglieder für zwei oder mehr Rollen verantwortlich ist. Einige der Möglichkeiten, um die Rollen für ein Desktopbereitstellungsprojekt miteinander zu kombinieren, sind:

  • Freigabeverwaltung und Benutzererfahrung

  • Test und Benutzererfahrung

  • Programmmanagement und Freigabeverwaltung

Einige Rollen sollten nicht kombiniert werden. Der Entwickler sollte nicht für das Testen verantwortlich sein, weil diese Kombination keine angemessene Überprüfung der Entwicklungsarbeit bietet. Auch sollte ein Teammitglied nicht gleichzeitig für die Rollen Programmmanagement und Produktmanagement verantwortlich sein. Obwohl Sie versucht sein könnten, diese Rollen der gleichen Person zuzuweisen, könnten ihre Interessen einander entgegengesetzt sein.

Für sehr kleine Projekte kann ein Kernprojektteam vorhanden sein, das nur aus drei Personen besteht: Eine ist für das Programmmanagement und die Freigabeverwaltung verantwortlich, eine für die Entwicklung und eine für Test, Benutzererfahrung und Produktmanagement. Das IT-Personal kann in Abhängigkeit von der Art des Projekts und den Fähigkeiten der Teammitglieder eine andere Kombination wählen, sofern die vorstehend beschriebenen Einschränkungen beachtet werden.

Zusammenstellen größerer Teams

Für größere Projekte sollte die IT-Abteilung ein Team zusammenstellen, in dem bestimmte Rollen von mehr als einem Teammitglied ausgefüllt werden. Dies gilt häufig für den Rollencluster „Entwicklung“, der je nach der Art des Projekts in mehrere Feature-Teams unterteilt werden kann.

Richten Sie die Feature-Teams auf der Basis einer logischen Arbeitsverteilung ein. Die IT-Abteilung könnte beispielsweise ein Feature-Team „Desktop“ zusammenstellen, das auf Windows bezogene Entwicklungsaktivitäten durchführt, ein Feature-Team „Anwendungen“, das mit 2007 Office System in Zusammenhang stehende Aktivitäten durchführt sowie ein Feature-Team „Messaging/Internet“, das Aktivitäten in Verbindung mit Microsoft Office Outlook® und Windows Internet Explorer® durchführt. Jedes dieser Feature-Teams kann aus einem oder mehreren Entwicklern bestehen, und jeder Entwickler kann in einem oder mehreren Feature-Teams arbeiten. Achten Sie beim Hinzufügen von weiteren Ressourcen zum Team darauf, dass das Team nicht für die effektive Zusammenarbeit als Gruppe zu groß wird.

Das MSF-Teammodell: Zuweisen von Teammitgliedern zu Rollen

Obwohl jede Rolle in der Projektbeschreibungsphase vertreten sein sollte, ist es weder notwendig, das gesamte Team jetzt zusammenzustellen, noch ist es erforderlich, dass sich zu diesem Zeitpunkt jedes Teammitglied vollständig dem Projekt widmet. Jede Rolle sollte jedoch in der Projektbeschreibungsphase einen genau festgelegten Leiter haben.

Alle sechs Rollen sind wesentliche Bestandteile des Teams. Bemühen Sie sich deshalb darum, jeden Leiter von Anfang an vollständig für das Projekt abzustellen. Keiner von ihnen sollte an anderen Projekten arbeiten. Natürlich können in der Realität nicht immer alle Teammitglieder vollständig von ihren anderen Pflichten abgezogen werden, bevor die Arbeit am Desktopbereitstellungsprojekt beginnt.

Folgen Sie diesen Richtlinien, wenn Sie Rollen zuweisen:

  • Die Personen, die die Rollencluster „Produktmanagement“ und „Programmmanagement“ ausfüllen, sollten nach Möglichkeit bereits zu diesem Zeitpunkt nur für diese Aufgaben abgestellt sein.

  • Obwohl der Leiter des Rollenclusters „Entwicklung“ während der Projektbeschreibungsphase mit dem Abschluss anderer Projekte beschäftigt sein kann, sollte sich diese Person, wenn möglich, diesem Projekt vollständig widmen. Rechnen Sie damit, dem Rollencluster „Entwicklung“ während der Entwicklungsphase zusätzliche Teammitglieder hinzuzufügen.

  • Der Leiter des Rollenclusters „Test“ kann, falls notwendig, während der Projektbeschreibungsphase anderen Projekten zugeordnet sein, sollte aber von Anfang an in das Projekt einbezogen werden und verfügbar sein, um wichtigen Entscheidungen zuzustimmen. Rechnen Sie damit, falls notwendig, dem Rollencluster „Test“ während der Entwicklungs- und Stabilisierungsphase zusätzliche Teammitglieder hinzuzufügen.

  • Der Leiter des Rollenclusters „Benutzererfahrung“ sammelt während der Projektbeschreibungsphase Benutzerprofilinformationen. Diese Person kann bei Bedarf während der Projektbeschreibungsphase anderen Projekten zugewiesen werden. Rechnen Sie damit, falls notwendig, dem Rollencluster „Benutzererfahrung“ während der Entwicklungs- und Stabilisierungsphase zusätzliche Teammitglieder hinzuzufügen.

  • Der Leiter des Rollenclusters „Freigabeverwaltung“ unterstützt während der Projektbeschreibungsphase die Beurteilung der aktuellen Situation. Diese Person kann bei Bedarf während der Projektbeschreibungsphase anderen Projekten zugewiesen werden. Rechnen Sie damit, dem Rollencluster „Freigabeverwaltung“ während der Bereitstellungsphase zusätzliche Teammitglieder hinzuzufügen.

Alle Teammitglieder, die während der Projektbeschreibungsphase an anderen Projekten arbeiten, müssen die Fähigkeit besitzen, ihre Zeit und ihre Aufmerksamkeit gut zu koordinieren, damit sie ihre Pflichten im Projekt nicht vernachlässigen. Es ist ein Risiko, Teammitglieder an anderen Projekten arbeiten zu lassen. Daher sollte dieser Umstand auch als Risiko erfasst und überwacht werden.

Wenn der Leiter des Rollenclusters „Programmmanagement“ oder andere Leiter im Voraus wissen, welche Personen zu einem späteren Zeitpunkt zum Team hinzukommen werden, notieren Sie dies im Dokument zur Festlegung des Konzepts/Umfangs. Es ist noch nicht entscheidend, diese zukünftigen Teammitglieder im Projekt zu beschäftigen. Stellen Sie ihnen gegebenenfalls die Projektdokumentation zur Verfügung, damit sie sie in Ruhe lesen können.

Beurteilen der aktuellen Situation

Eine Karte ist für Reisende nur dann wertvoll, wenn sie wissen, wo sie sind. Analog dazu kann die IT-Abteilung ein Desktopbereitstellungsprojekt nicht effektiv beschreiben, ohne den aktuellen Status der Computerumgebung des Unternehmens genau zu kennen. Dies umfasst exakte und aktuelle Informationen z. B. über die Systemarchitektur des Unternehmens, einschließlich der bereits bereitgestellten Hardware und Software und ihrer speziellen Kombinationen, und die derzeit im Unternehmen vorhandenen betrieblichen Verfahren.

Stellen Sie sich das Bereitstellungsprojekt als eine Phase im laufenden Prozess der Technologie-Lebenszyklusverwaltung vor, die Jahre oder sogar Jahrzehnte dauern kann. Wenn das Projekt beginnt, sollten sich die Teams daher auf bereits getane Arbeit und vor langer Zeit gewonnene Erfahrungen stützen können. Nach Abschluss des Projekts lassen die Teams diese Arbeiten und Erfahrungen in zukünftige Maßnahmen der Lebenszyklusverwaltung einfließen.

Im Rahmen der Entscheidung über die Bereitstellung von Windows oder 2007 Office System sollte ein Mitarbeiter der IT-Abteilung als Ausgangspunkt für die Entscheidungsfindung die aktuelle Computerumgebung beurteilt haben. Die IT-Abteilung kann sich entschieden haben, diese Beurteilung selbst vorzunehmen oder eine Beratungsfirma damit beauftragt haben. Das Ergebnis einer solchen Beurteilung ist gewöhnlich ein Dokument, das die Erkenntnisse des Gutachters detailliert beschreibt und Empfehlungen für zukünftige Maßnahmen umfassen kann. Dieses Dokument sollte genügend Informationen über die Computerumgebung enthalten, einschließlich Informationen zu Netzwerk, Domänen und physischen Standorten, damit eine sachkundige Planung möglich ist.

Während der Projektbeschreibungsphase ist es die Aufgabe des Projektteams, relevante Informationen zur aktuellen Situation zu sammeln und nach Mängeln Ausschau zu halten, die mit dem Projekt behoben werden können. Der Prozess der Informationssammlung kann unter Umständen einfach aus dem Beschaffen von Dokumenten wie der oben beschriebenen Beurteilung der IT-Abteilung bestehen. Wenn keine solchen Dokumente existieren, muss das Team unter Umständen vorhandene Dokumentation aus verschiedenen Quellen innerhalb des Unternehmens zusammentragen und sie auf Richtigkeit und Vollständigkeit prüfen oder eine eigene kurze Überprüfung durchführen.

Dieser Zeitpunkt ist oft ideal, um mit der Netzwerkermittlung und den Prozessen zur Computerinventur beginnen und ein genaueres Bild der Umgebung zu erhalten. Der Rollencluster „Freigabeverwaltung“ übernimmt normalerweise beim Beurteilen der aktuellen Situation die Leitung.

Dokument zur Festlegung des Konzepts/Umfangs

Das primäre Ergebnis der Projektbeschreibungsphase ist das Dokument zur Festlegung des Konzepts/Umfangs, das eine klare Richtung für das Projekt vorgibt und die Erwartungen innerhalb des Unternehmens sowie seitens der Geldgeber und Projektverantwortlichen festschreibt. Es besteht aus folgenden Elementen:

  • Geschäftsziele: Umfasst Problembeschreibungen, die die Probleme definieren, die mit dem Projekt gelöst werden sollen, sowie Geschäftsziele

  • Konzeptpapier: Legt ein Konzept für das Projekt fest

  • Definition des Projektumfangs: Legt den Projektumfang fest

  • Benutzerprofile: Identifiziert die Benutzer, die von der Lösung profitieren werden

  • Lösungskonzept: Skizziert den Ansatz, den das Team bei der Planung des Projekts verfolgen wird

  • Projektstruktur und -standards: Vom Team zu befolgender Leitfaden

  • Risiken: Führt die größten erkannten Risiken aus dem Dokument zur Risikoabschätzung auf

Definieren der Geschäftsziele

Unternehmen führen Infrastrukturbereitstellungen durch, um geschäftlichen Anforderungen Rechnung zu tragen. Wenn das Projekt die MSF-Projektbeschreibungsphase erreicht hat, sollten diese Anforderungen ausreichend klar sein, damit sie in Form von Problembeschreibungen und entsprechenden Geschäftszielen ausgedrückt und definiert werden können.

Mit Problembeschreibungen werden in der Computerumgebung festgestellte Mängel angegeben. Die Geschäftsziele definieren die Ziele, die das Team zu erreichen hofft, indem Maßnahmen vorgeschlagen werden, mit denen die festgestellten Probleme verringert werden können. Diese Probleme werden manchmal als Geschäftschancenbezeichnet, weil sie dem Unternehmen die Gelegenheit bieten, seine Prozesse zu verbessern.

Das Team sollte das Projekt nicht nur durchführen, um die neueste Technologie bereitzustellen. Stattdessen muss das Team konkrete Mängel und Chancen in der Computerinfrastruktur des Unternehmens und im Geschäft selbst identifizieren und das Projekt direkt auf diese Bereiche abstimmen. Der Rollencluster „Produktmanagement“ übernimmt die Leitung beim Definieren der Geschäftsziele, die maximal eine Seite umfassen sollten.

Eine typische Problembeschreibung und ein Geschäftsziel für dieses Projekt könnten folgendermaßen lauten:

Das Unternehmen besitzt derzeit keinen definierten Betriebssystemstandard. Mehrere Fusionen und Übernahmen führten dazu, dass verschiedene Niederlassungen Microsoft Windows Me , Windows 2000 Professional und Windows 98 ausführen. Diese fehlende Standardisierung führte zu erhöhten Supportkosten. Der Wechsel zu einem einzigen Betriebssystemstandard würde eine Gelegenheit bieten, eine messbare Senkung der Supportkosten zu erzielen.

Die Problembeschreibung ist hier die Beschreibung der bekannten Nachteile, die der Einsatz mehrerer Betriebssysteme innerhalb des Unternehmens hat. Das Geschäftsziel ist dabei, diese Nachteile durch Einführung eines einzigen Standards zu minimieren oder zu beseitigen.

Definieren des Konzepts und Projektumfangs

Zu den zentralen Schritten während der Planungsphase gehören die Erstellung des Konzeptpapiers und die Definition des Projektumfangs. Der Projektumfang ergibt sich aus dem Konzeptpapier.

Erstellen des Konzeptpapiers

Mit dem Konzeptpapier wird ein langfristiges Konzept für die Lösung der Problembeschreibungen und die Erreichung der Geschäftsziele festgelegt. Das Konzeptpapier besteht in der Regel nur aus ein oder zwei Absätzen und ist nicht an die konkreten Arbeiten gebunden, die das Team im Rahmen des aktuellen Projekts vermutlich ausführen wird. Es sollte aber konkurrierende Interessen gegeneinander abwägen, um ein Konzept bereitzustellen, das von den Teammitgliedern geteilt werden kann, und einen Kontext für zukünftige Entscheidungen liefern.

Eine typisches Konzeptpapier für ein Windows-Bereitstellungsprojekt könnte folgendermaßen lauten:

Die IT-Abteilung wird eine einzelne unternehmensweite Computerplattform auswählen und implementieren, damit das Anrufvolumen beim Supportcenter um 10 Prozent verringert wird und dadurch die Außendiensttechniker mindestens 15 Prozent ihrer Zeit mit wertschöpfenden Projekten statt mit reaktivem Support verbringen können.

Definieren des Projektumfangs

Im Projektumfang wird das im Konzeptpapier ausgedrückte allgemeine Projektkonzept übernommen, wobei die durch Zeit, Ressourcen, Budget und andere Einschränkungen auferlegten Grenzen einbezogen werden. Dieser Prozess umfasst normalerweise die Verwendung unterschiedlicher Versionen, um einen iterativen Ansatz für das Projekt zu definieren. Dabei identifiziert das Projektteam die wichtigsten Anforderungen des Unternehmens und setzt auf der Grundlage dieser Einschätzung Prioritäten für die Bereitstellung.

Das Konzept könnte zum Beispiel die unternehmensweite Bereitstellung von Windows Vista, 2007 Office System und einer Suite nicht von Microsoft stammender Anwendungen vorsehen. Zeit- und Budgetbeschränkungen könnten es unmöglich machen, das gesamte Konzept im Rahmen eines einzigen Projekts umzusetzen. Der Projektumfang könnte daher das aktuelle Projekt darauf beschränken, Windows Vista unternehmensweit auf Desktopcomputern und tragbaren Computern sowie 2007 Office System auf Desktopcomputern im gesamten Unternehmen bereitzustellen. Weitere Projekte könnten in Zukunft die Bereitstellung von 2007 Office System auf tragbaren Computern sowie von zusätzlicher Software auf allen Computern im Unternehmen umfassen. Abhängig von den Anforderungen des Unternehmens könnte der Umfang der Bereitstellung durch Abteilungen, Computerhersteller, geografische Standorte oder durch andere Faktoren eingeschränkt werden.

Das in Abbildung 4 dargestellte Kompromissdreieck ist eine wichtige Komponente von MSF und hilft dabei, den Projektumfang festzulegen. Das Kompromissdreieck bestimmt, dass Ressourcen, Zeitplan und Features drei miteinander verbundene Elemente jedes Projekts sind. Wird eines oder mehrere dieser Elemente eingeschränkt oder erweitert, sind Kompromisse bei den anderen Elementen notwendig. Wen sich z. B. ein Projektteam mit begrenzten Ressourcen (z. B. Personal, Budget oder Einrichtungen) auf einen frühen Fertigstellungstermin festlegt, wird es wahrscheinlich Kompromisse beim Funktionsumfang eingehen, um den Termin einzuhalten: Vielleicht wird die Bereitstellung an einigen Remotestandorten oder auf bestimmten Systemen auf einen späteren Zeitpunkt verschoben.

Abbildung 4: Das MSF-Kompromissdreieck

Erstellen von Benutzerprofilen

Der Projekterfolg hängt davon ab, dass jedes Mitglied des Teams über eine genaue Kenntnis der Benutzer und ihrer Anforderungen verfügt. Benutzerprofile identifizieren die Benutzer, damit das Team die Erwartungen, Projektrisiken und -ziele sowie die Einschränkungen beurteilen kann. Diese Profile umfassen normalerweise Informationen wie die geografischen Standorte, Aufgabenbereiche, Organisationsstruktur und Kommunikationsmuster der Benutzer.

Der Zweck der Benutzerprofile besteht in einem Überblick darüber, wer die Benutzer der Lösung sind und wie ihre Beziehung zur Lösung aussehen wird. IT-Mitarbeiter möchten wahrscheinlich unterschiedliche Profile für die Benutzer(als diejenigen definiert, die mindestens einen Teil der Lösung zur Erfüllung ihrer Aufgaben im Unternehmen verwenden werden) und die IT-Spezialisten, die für die Bereitstellung und Wartung der Lösung verantwortlich sein werden, definieren. Es könnte deshalb notwendig sein, unterschiedliche Klassen von Benutzern zu identifizieren und Profile für sie alle zu entwickeln.

Entwickeln des Lösungskonzepts

Mit dem Lösungskonzept wird ein Ansatz skizziert, der die Basis für das Planen und Abstecken der Analysen und Untersuchungen bildet, die zum Erstellen einer Spezifikation erforderlich sind. Nachdem das Team jetzt die Geschäftsprobleme identifiziert sowie das Konzept und den Projektumfang definiert hat, erstellt es das Lösungskonzept, das allgemein erklärt, wie das Team die Anforderungen des Projekts zu erfüllen beabsichtigt. Der Rollencluster „Programmmanagement“ übernimmt die Leitung beim Entwickeln des Lösungskonzepts, das kurz und bündig (vielleicht ein paar Seiten lang) gehalten werden sollte.

Während der Projektumfang beschreibt, welche Aufgaben das Team durchführen möchte, beschreibt das Lösungskonzept, wie es sie durchführen möchte. Das Lösungskonzept sollte relativ allgemein gehalten sein und kann beispielsweise die folgenden Elemente beinhalten:

  • Die Aufgaben jeder der sechs Teamrollen und der Personen, die ihnen zugewiesen wurden (zu diesem Zeitpunkt wenigstens die des Leiters)

  • Ein Überblick über das Projekt, einschließlich der Phasen und der zugehörigen Meilensteine und Ergebnisse auf Basis des MSF-Prozessmodells

  • Faktoren, die beschreiben, wie der Erfolg des Projekts definiert und gemessen wird

  • Beispielszenarien dafür, wann und wie das System implementiert wird und wie die Benutzer die neue Technologie einsetzen

  • Eine Checkliste der Anforderungen, die erfüllt sein müssen, bevor die Lösung produktiv wird

  • Ein erster allgemeiner Entwurf des Zeitplans für die Planungsphase

Erstellen einer Projektstruktur

Die Projektstruktur definiert, wie das Team das Projekt verwaltet und unterstützt, und sie beschreibt die administrative Struktur des Projektteams für den Übergang zur Planungsphase. Die Hauptfunktion der Projektstruktur besteht darin, Standards zu definieren, die das Team während des Projekts verwenden wird. Diese Standards umfassen Kommunikationsstandards, Dokumentationsstandards und Verfahren zur Änderungssteuerung. Ziehen Sie die Erstellung einer Intranetwebsite für die Kommunikation und Überwachung des Fortschritts in Betracht.

Der Rollencluster „Programmmanagement“ übernimmt die Leitung beim Definieren der Projektstruktur, die normalerweise als eine Komponente im Dokument zur Festlegung des Konzepts/Umfangs enthalten ist.

Planen der Projektkommunikation

Der Rollencluster „Programmmanagement“ sollte die Projektstruktur verwenden, um Standards für die Kommunikation der Teammitglieder untereinander zu definieren. Diese Standards könnten Folgendes umfassen: eine Definition der Berichtstruktur, mit der die Teammitglieder arbeiten, Verfahren für das Weitermelden von Problemen, regelmäßige Statusbesprechungen sowie weitere projektspezifische und auf die Kommunikation bezogene Standards, die während der Projektbeschreibungsphase definiert werden müssen.

Das Dokument kann ebenso E-Mail-Adressen, Aliasnamen, Telefonlisten, Postadressen, Serverfreigabenamen, Verzeichnisstrukturen und andere Informationen enthalten, die für die Organisation des Teams notwendig sind. Sie sollten die Einrichtung einer internen Webseite in Betracht ziehen, auf der diese Informationen zur Verfügung gestellt und bei Bedarf aktualisiert werden können.

Planen der Dokumentationsstandards

In der Projektstruktur können auch Vorgaben dazu definiert werden, wie Schulungsmaterialien und Dokumentation, die sich auf das Projekt beziehen, zu erstellen sind, einschließlich Standards, die die Anwendungen und Arbeitshilfen (Vorlagen) vorschreiben, die das Team zum Erstellen von Dokumenten verwenden sollte.

Planen der Änderungssteuerung

Änderungen oder die Möglichkeit von Änderungen sind ein integraler Faktor in jedem Hightech-Bereitstellungsprojekt. Hersteller veröffentlichen oft neue Softwareversionen oder Updates und Service Packs für vorhandene Versionen. Durch die Steuerung aller Änderungen, die den Umfang des Projekts betreffen können, kann das Team zur Gewährleistung beitragen, dass das Projekt pünktlich und innerhalb des Budgetrahmens abgeschlossen wird. Gleichzeitig kann es ein schleichendes Anwachsen des Projektumfangs (Scope Creep) verhindern – die Tendenz, dem Projekt solange stufenweise Features hinzuzufügen, bis die kombinierten Auswirkungen der Änderungen den Erfolg des Projekts gefährden.

Die Rolle „Programmverwaltung“ sollte die Aufnahme der Standards zur Änderungssteuerung in die Projektstruktur in Betracht ziehen. Diese Standards würden sowohl für Änderungen an Projektstruktur und -umfang als auch für Änderungen an Skripts gelten. Zu diesen Standards können vorgeschriebene tägliche Builds und die Verwendung von Software zur Quellcodeverwaltung wie z. B. Microsoft Visual SourceSafe® 6.0 zur Kontrolle des Zugriffs auf Skripts gehören.

Erstellen des Dokuments zur Risikoabschätzung

Das Projektrisikooder die Möglichkeit negativer Ergebnisse, die mit einzelnen Aspekten des Projekts verbunden ist, ist Teil jedes Bereitstellungsprojekts. Risikomanagement ist der Prozess, mit dem Risiken vorhergesehen, berücksichtigt, verringert und verhindert werden. Im Rahmen von MSF wird das Risikomanagement vom Team kontinuierlich während des gesamten Projekts und nicht nur in vorgegebenen Intervallen praktiziert.

Das Risikomanagement ist proaktiv: Das Team konzentriert sich auf eine kontinuierliche Abschätzung, was schief gehen könnte und wie dies verhindert bzw. der entstehende Verlust minimiert werden kann, anstatt darauf zu warten, dass ein Problem auftritt und dann seine Auswirkungen aufzufangen.

Hinweis   BDD bietet als Arbeitshilfe das Woodgrove Risk Template Tool (Risikovorlagentool), um die Erkennung und Priorisierung von Risiken zu unterstützen.

Erste Risikoabschätzung

Während der Projektbeschreibungsphase praktiziert das Team Risikomanagement, indem es ein erstes Dokument zur Risikoabschätzung erstellt, in dem alle bekannten Risiken zusammengefasst und nach Wahrscheinlichkeit (die Chance, dass das Risiko eintreten wird) und Auswirkung (die Größe des beim Eintreten des Risikos entstehenden Verlusts) bewertet werden. Der Rollencluster „Programmmanagement“ übernimmt beim Erstellen des Dokuments zur Risikoabschätzung die Leitung.

Wenn Teams numerische Bewertungsmaßstäbe verwenden, um Risikowahrscheinlichkeit und Auswirkungen einzuschätzen, können sie den Gefährdungsfaktor jedes Risikos berechnen, indem sie die beiden Zahlen miteinander multiplizieren: Wahrscheinlichkeit x Auswirkung = Gefährdungsfaktor. Diese Berechnung macht es möglich, Risiken miteinander zu vergleichen, um ihre relative Schwere und Priorität zu bestimmen, die möglicherweise nicht sofort offensichtlich ist, wenn z. B. ein Risiko eine hohe Wahrscheinlichkeit, aber geringe Auswirkungen und ein anderes eine niedrige Wahrscheinlichkeit, aber gravierende Auswirkungen hat. Beispiel: Wenn ein Team eine Zahl zwischen 1 und 4 verwendet, um die Wahrscheinlichkeit und Auswirkungen jedes Risikos zu kennzeichnen, wobei 4 der höchste und 1 der niedrigste Wert ist, ergibt die Multiplikation der beiden Zahlen für jedes Risiko einen Gefährdungsfaktor zwischen 1 und 16. Dadurch können sich die Teammitglieder zuerst auf die größten Risiken konzentrieren.

Teams müssen nicht den gleichen numerischen Bewertungsmaßstab für die Abschätzung der Wahrscheinlichkeit und der Auswirkungen verwenden. Wenn Teammitglieder den finanziellen Verlust genau berechnen können, der durch die einzelnen Risiken verursacht wird, können sie die Auswirkung als Geldbetrag ausdrücken. Es ist jedoch wichtig, dass sie einen einheitlichen Bewertungsmaßstab für die Berechnung der Wahrscheinlichkeit jedes Risikos sowie einen einheitlichen Bewertungsmaßstab für die Berechnung der Auswirkungen jedes Risikos verwenden. Die Verwendung eines Geldbetrags, um die Auswirkung einiger Risiken auszudrücken, und eines numerischen Bewertungsmaßstabs, um andere Risiken auszudrücken, macht es unmöglich, Risiken miteinander zu vergleichen.

Nachdem das Team das Dokument zur Risikoabschätzung erstellt und jedes Risiko anhand seines Gefährdungsfaktors eingestuft hat, kann sich das Team durch eine Liste der größten Risiken auf diejenigen mit der größten Priorität konzentrieren. Oft als Top-10-Listebezeichnet, muss diese Liste nicht genau 10 Risiken enthalten. Sie kann aber mehr oder weniger Risiken enthalten, was von der Anzahl der erkannten Risiken sowie von der speziellen Art der Risiken und von der Art des Projekts allgemein abhängt. Der Rollencluster „Programmmanagement“ sollte diese Liste regelmäßig während des gesamten Projekts überprüfen sowie Risiken hinzufügen und entfernen, wenn sich ihre Bedeutung ändert und wenn neue Risiken erkannt werden.

Potenzielle Risiken

Einige der Risiken, die das Team möglicherweise beim Bereitstellen von Windows, 2007 Office System und anderen Anwendungen steuern muss, sind:

  • Komponenten der ausgewählten Technologie könnten Fehler enthalten, die verhindern, dass sie so wie geplant funktionieren.

  • Der für das Projekt vorgesehene Zeitrahmen könnte zu knapp bemessen sein, sodass das Team das Projekt nicht angemessen implementieren kann.

  • Die Teammitglieder könnten nicht mit den Konzepten und Prinzipien von MSF sowie ihren auszufüllenden Rollen vertraut sein.

  • Die dem Projekt zugewiesenen Teammitglieder könnten mit anderen Aufgaben ausgelastet sein.

  • IT-Manager im gesamten Unternehmen, besonders jene an Remotestandorten, könnten gewohnt sein, in bestimmtem Maße selbständig zu arbeiten und die von den Managern vorgeschriebenen Standards nicht anwenden.

  • Einige interne Anwendungen könnten unter Windows XP oder Windows Vista nicht ordnungsgemäß funktionieren.

Es ist nahezu unwahrscheinlich, dass das Projektteam mit all diesen Risiken konfrontiert wird. Jedoch ist es mehr als wahrscheinlich, dass Risiken auftauchen, die nicht auf der Liste stehen. Denken Sie auch daran, dass das Risikomanagement ein kontinuierlicher Prozess ist und einige Risiken erst später im Prozess offensichtlich werden.

Weitere Informationen zur Risikoabschätzung

Die richtige Durchführung einer Risikoabschätzung erfordert ein Verständnis der Philosophien, die dem Risikomanagement im Allgemeinen und speziell dem MSF-Risikomanagement zugrunde liegen. Ein ausführliches Whitepaper über die MSF-Risikomanagementdisziplin ist unter http://www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942 (auf Englisch) verfügbar. Außerdem ist eine Arbeitshilfe (Vorlage) für das Dokument zur Risikoabschätzung in dieser Lösung enthalten.

Hauptmeilenstein: Konzept/Umfang genehmigt

Mit dem Meilenstein „Konzept/Umfang genehmigt“ endet die Projektbeschreibungsphase. Zu diesem Zeitpunkt haben sich das Projektteam und der Kunde über die Gesamtrichtung des Projekts, einschließlich der Features, die die Lösung umfassen bzw. nicht umfassen soll, und auf einen allgemeinen Zeitplan für die Lieferung geeinigt.

Nachdem die Rollen im Team festgelegt und die Ergebnisse der Projektbeschreibungsphase erstellt wurden, kann der Programmmanager sie in das Dokument zur Festlegung des Konzepts/Umfangs einfügen. Dieses Dokument wird dann als Basis verankert (der Änderungssteuerung unterstellt) und dient als Grundlage für die Planung des Projekts.

Checkliste für die Projektbeschreibungsphase

Bevor Sie zur Planungsphase übergehen, sollten die folgenden Elemente behandelt worden sein:

  • Geschäftsmodell

  • Zentrale Teams wurden identifiziert:

    • Programmmanagement

    • Produktmanagement

    • Entwicklung

    • Test

    • Benutzererfahrung

    • Freigabeverwaltung

  • Feature-Teams wurden identifiziert:

    • Anwendungskompatibilität

    • System zum Erstellen von Computerabbildern

    • Anwendungsverwaltung

    • Bereitstellung

    • Wiederherstellung der Infrastruktur

    • Betriebsbereitschaft

    • Sicherheit

    • Test

    • Benutzerstatusmigration

  • Netzwerkermittlung kann erledigt worden sein

  • IT-Betriebspersonal wurde in das Projekt einbezogen

  • Projektstruktur wurde genehmigt

  • Risikoabschätzung abgeschlossen

  • Das Feature-Team „Sicherheit“ wurde in das Projekt einbezogen

  • Das Dokument zur Festlegung des Konzepts/Umfangs wurde genehmigt

  • Die Computerinventur kann durchgeführt worden sein

Nachdem alle Aufgaben der Projektbeschreibungsphase abgeschlossen wurden, muss das Team formell darin übereinkommen, dass das Projekt den Meilenstein „Konzept/Umfang genehmigt“ erreicht hat. Durch die Abnahme dieses Meilensteins erklären die Teammitglieder, dass sie mit den Arbeiten in ihren jeweiligen Zuständigkeitsbereichen zufrieden sind.

Die Projektteams bestätigen das Erreichen eines Meilensteins in der Regel mit einer formellen Abnahme (Abzeichnung). Wichtige Projektverantwortliche, normalerweise Vertreter jeder Teamrolle und einige wichtige Vertreter des Kunden, die nicht Teil des Projektteams sind, signalisieren die Abnahme des Meilensteins, indem sie ein Dokument über die Erreichung des Meilensteins unterschreiben oder abzeichnen. Das Abnahmedokument wird zu einem Projektergebnis und für zukünftige Zwecke archiviert. Das Projekt kann jetzt in die Planungsphase übergehen.

Die Planungsphase

Die Planungsphase ist die Periode, in der das Team die Lösung definiert: was erstellt werden soll, wie es zu erstellen ist und wer es erstellen wird. Die Planungsphase gipfelt im Meilenstein „Projektpläne genehmigt“. Dieser zeigt an, dass sich das Projektteam, der Kunde und wichtige Projektverantwortliche über die Details des Plans einig sind.

Das Ziel des Teams während der Planungsphase besteht darin, die Lösung in einer Reihe von Plänen hinreichend zu dokumentieren, sodass das Team die richtige Lösung rechtzeitig und kostengünstig herstellen und bereitstellen kann. Hierbei handelt es sich um so genannte „lebende“ Dokumente, die vom Team während der gesamten Entwicklungsphase fortlaufend aktualisiert werden.

Die Planungsphase weist vier Hauptergebnisse auf: die Funktionsbeschreibung, die den Lösungsentwurf enthält, den Projektplan, den Projektzeitplan sowie die Entwicklungs- und Testumgebung.

Hauptaufgaben

In Tabelle 5 sind die Hauptaufgaben und -ergebnisse in der Projektplanungsphase mit den jeweiligen Besitzern aufgeführt.

Tabelle 5: Hauptaufgaben in der Planungsphase mit ihren Ergebnissen und Besitzern

Hauptaufgaben

Ergebnisse

Besitzer

Entwickeln des Lösungsentwurfs

Das Dokument mit dem Lösungsentwurf

Programmmanagement (mit einem großen Beitrag der Entwickler)

Erstellen der Funktionsbeschreibung

Ein erster Entwurf der Funktionsbeschreibung

Programmmanagement (mit einem großen Beitrag der Entwickler)

Entwickeln des Projektplans

Der Projektplan (eine Zusammenfassung aller Einzelpläne)

Programmmanagement (wobei jeder Rolle die ihr zugewiesenen Abschnitte gehören)

Erstellen des Projektzeitplans

Der Projektzeitplan

Programmmanagement (wobei jeder Rolle die ihr zugewiesenen Abschnitte gehören)

Identifizieren und Priorisieren von Anwendungen

Liste der Anwendungen, Experten für das Fachgebiet (Subject Matter Experts, SME), Medien und Einstellungen

Freigabeverwaltung

Durchführen einer Inventur der Hardware und Anwendungen

Analysetool bereitgestellt, Berichte über die Anwendungskompatibilität und das Hardwareinventar wurden generiert

Freigabeverwaltung

Erstellen des Migrationsplans für die Kernanwendungen

Migrationsplan

Entwicklung

Erstellen der Sicherheitsrichtlinien und -strategien

Sicherheitsrichtlinien, Strategien und Konfiguration

Entwicklung

Analysieren des Netzwerks

Netzwerkdiagramme mit Topologie und Inventar der Netzwerkgeräte

Freigabeverwaltung

Erstellen des Testplans

Testplan

Test

Einrichten des Testlabors

Testlabor für die Tests bereit

Test, Entwicklung

Abnehmen des Meilensteins

Alle Arbeiten der Planungsphase wurden abgenommen

Alle Rollen

Schwerpunkte des Teams

Tabelle 6 zeigt die Hauptaktivitäten für die einzelnen Rollencluster während der Planungsphase.

Tabelle 6: Rollencluster und Schwerpunkte in der Planungsphase

Rollencluster

Schwerpunkt

Produktmanagement

  • Beitrag zum Konzeptentwurf

  • Analyse der Geschäftsanforderungen

  • Kommunikationsplan

Programmmanagement

  • Konzeptentwurf und logischer Entwurf

  • Funktionsbeschreibung

  • Projektplan und Projektzeitplan

  • Budget

Entwicklung

  • Technologiebewertungen

  • Logischer und physischer Entwurf

  • Entwicklungsplan und Entwicklungszeitplan

  • Einrichten des Labors

  • Migrationsstrategie

  • Sicherheitsrichtlinien und -strategie

Test

  • Teststrategie, Testtypen, Testplan und Zeitpläne

Benutzererfahrung

  • Verwendungsszenarien/Anwendungsfälle, Benutzeranforderungen und Lokalisierungs-/Zugriffsanforderungen

  • Benutzerdokumentation und Schulungsplan, Zeitpläne

Freigabeverwaltung

  • Entwurfsbewertung

  • Anforderungen an den Betrieb

  • Pilotversuch und Bereitstellungsplan/-zeitplan

  • Netzwerkermittlung

  • Anwendungs- und Hardwareinventur

  • Zusammenarbeit mit dem IT-Betriebspersonal und dem Feature-Team „Sicherheit“

Das IT-Betriebspersonal und das Feature-Team „Sicherheit“ werden in die Bewertungen eingebunden, um sicherzustellen, dass mit einem genauen Bild ihrer jeweiligen Bereiche gearbeitet wird. Die Benutzercommunity wird ebenfalls einbezogen, um sicherzustellen, dass die erstellten Pläne und Entwürfe ihren Anforderungen entsprechen.

Sofern dies nicht bereits erfolgt ist, wird eine Analyse der bereitgestellten Anwendungen durchgeführt, damit festgestellt werden kann, welche Anwendungen erneut bereitgestellt und welche ausgemustert werden können. Der Rollencluster „Freigabeverwaltung“ ordnet zunächst die Anwendungen nach Priorität, um eine Reihenfolge für die Automatisierung der Anwendungsbereitstellung festzulegen.

Zudem führt der Rollencluster „Freigabeverwaltung“ eine erste Prüfung des Hardwareinventars durch (wenn diese nicht bereits während der Planung des Technologielebenszyklus erfolgt ist), um zu bestimmen, welche Computer unverändert verwendet werden können, welche eventuell Änderungen erfordern (z. B. Arbeitsspeicher oder Datenträger) und welche ersetzt werden müssen.

Feature-Team-Dokumente und Dokumente zur Arbeitshilfe

Die folgenden Dokumente werden in der Planungsphase verwendet:

  • Funktionsbeschreibung

  • Risikoabschätzung

  • Projektzeitplan

  • Projektplan, einschließlich:

    • Entwicklungsplan

    • Testplan

    • Bereitstellungsplan

    • Pilotplan

    • Kommunikationsplan

    • Schulungsplan

    • Ausstattungs- und Hardwareplan

    • Budgetplan

  • Application Compatibility Feature-Team Guide

  • Application Management Feature-Team Guide

  • Computer Imaging System Feature-Team Guide

  • Deployment Feature-Team Guide

  • Desired Configuration Monitoring Feature-Team Guide

  • Infrastructure Remediation Feature-Team Guide

  • Operations Readiness Feature-Team Guide

  • Security Feature-Team Guide

  • Test Feature-Team Guide

  • User State Migration Feature-Team Guide

Einrichten des Labors

Es empfiehlt sich, eine dedizierte und isolierte Testumgebung einzurichten, die zum Entwickeln und Testen der Lösung verwendet werden kann (sofern die Teams nicht bereits über eine derartige Umgebung verfügen). Das Labor sollte die Produktionsumgebung so gut wie möglich widerspiegeln, damit sichergestellt werden kann, dass alle Aspekte der Produktionsumgebung im Entwicklungsprozess berücksichtigt werden können.

Das Labor sollte mindestens Folgendes umfassen:

  • Eine Microsoft Active Directory®-Verzeichnisdienstdomäne (Microsoft Windows Server® 2003 oder Windows 2000 Server) mit Administratorrechten

  • Windows Server 2003 mit SP1. (Windows Server 2003 R2 wird bevorzugt, da diese Version einen nützlichen Replikationsmechanismus bietet.)

  • Microsoft Virtual Server 2005 (optional)

  • DHCP-Dienste (Dynamic Host Configuration Protocol)

  • DNS-Dienste (Domain Name System)

  • WINS-Dienste (Windows Internet Naming Service, optional)

  • MOM 2005 (optional)

  • Microsoft Windows Deployment Services (Windows DS)

  • SMS 2003 mit SP1 und SMS Operating System Deployment (OSD) Feature Pack

  • SQL Server 2000

  • SQL Server 2000 Reporting Services Standard Edition

  • Internetzugang (zum Herunterladen von Aktualisierungen, Dateien und so weiter)

  • Ein Dateiserver mit ausreichender Kapazität zum Hosten des Imagingservers, 50 Gigabyte (GB) werden empfohlen

  • Testcomputer, die exakt den Produktionscomputern entsprechen

  • CD-Brenner und beschreibbare CDs (obligatorisch) oder DVD-Brenner und beschreibbare DVDs (optional)

  • Sicherungsmedien, beispielsweise ein Bandsicherungssystem und Bänder

  • Softwarebibliothek, einschließlich Windows, 2007 Office System, Anwendungen, Software zum Erstellen von Datenträgerabbildern, Windows PE und Hardwaretreibern

Entwickeln des Lösungsentwurfs

Der Lösungsentwurf ist das erste ausführliche Entwurfsdokument und Teil der Funktionsbeschreibung. Dieser Entwurf bereitet die Teammitglieder auf ihre Zuständigkeiten während der Entwicklungsphase vor. Er baut auf dem vom Team entwickelten Konzept sowie auf Technologieinformationen auf, die das Team während der Projektbeschreibungsphase gesammelt hat, und enthält die konzeptionellen, logischen und physischen Lösungsentwürfe. Stellen Sie sich die Prozesse, die diese Entwürfe ergeben, als drei sich überlappende Phasen eines Entwurfsprozesses vor, der bereits vor der Projektbeschreibungsphase beginnt und sich während des gesamten Projekts sowie danach fortsetzt, wobei das Projekt selbst nur eine Komponente eines größeren Prozesses zur Verwaltung des Technologielebenszyklus ist.

Der Entwurfsprozess

Der Entwurfsprozess ist mit einem Hausbauprojekt vergleichbar. Der Konzeptentwurf entspricht den groben Skizzen und Szenarien, die der Architekt zusammen mit dem Kunden erstellt. Der logische Entwurf wird vom Team des Architekten erstellt und formt die Struktur der Lösung sowie die Kommunikationspfade zwischen den Elementen. Er entspricht einem Grundriss und Aufriss, in dem Elemente wie die räumlichen Beziehungen ausgearbeitet werden. Der physische Entwurf entspricht dem Entwurf der Baufirma für die physischen Elemente eines Bauwerks – elektrische Leitungen, Wasserleitungen, Heizung und Belüftung. Die Pläne der Baufirma (physischer Entwurf) fügen den Plänen des Architekten (logischer Entwurf) Details hinzu und spiegeln reale Konstruktionseinschränkungen wider.

Konzeptentwurf

Der Konzeptentwurf umfasst das Verständnis der Geschäftsanforderungen und das Definieren der Features und Funktionen, die die Benutzer zur Erledigung ihrer Arbeit benötigen. Der Rollencluster „Produktmanagement“ übernimmt die Leitung bei der Erstellung des Konzeptentwurfs, die in der Projektbeschreibungsphase beginnt und sich während der gesamten Planungsphase fortsetzt. Der Konzeptentwurf dieses Projekts sollte Folgendes umfassen:

  • Entwurfsziele, die die Ziele des Projekts so beschreiben, dass den Problembeschreibungen und Geschäftschancen, die im Dokument zur Festlegung des Konzepts/Umfangs genannt wurden, Rechnung getragen wird.

  • Eine Liste von Features und Funktionen, aus denen die Lösung besteht. Im Konzeptentwurf wird diese Liste normalerweise mit dem Betriebssystem und den Anwendungen, die bereitgestellt werden sollen (in diesem Fall Windows und alle zusätzlichen Anwendungen), mit der Architektur für die unbeaufsichtigte Installation (einschließlich der Verteilungsserver) und mit der Architektur zum Erstellen von Datenträgerabbildern in Beziehung gesetzt.

  • Verwendungsszenarien, die der Art und Weise Rechnung tragen, in der die verschiedenen Benutzertypen die Lösung implementieren, verwalten und verwenden werden. Schauen Sie sich erneut die Benutzerprofile an, die im Dokument zur Festlegung des Konzepts/Umfangs definiert wurden, und beschreiben Sie, wie die identifizierten Benutzertypen mit der Lösung arbeiten werden. Zu den zu dokumentierenden Aufgaben können gehören: Verwaltung der Verteilungsarchitektur, Installation und Konfiguration der Lösung auf neuen Computern, Konfiguration von Windows für die erstmalige Verwendung und Verwendung unterschiedlicher Komponenten der Lösung zur Implementierung von Geschäftszielen.

Logischer Entwurf

Beim logischen Entwurf werden der Konzeptentwurf und der aktuelle Zustand der Technologieinfrastruktur zur grundlegenden Definition der neuen Architektur herangezogen. Der logische Entwurf dieses Projekts sollte Folgendes umfassen:

  • Eine grundlegende Definition der Architektur für die unbeaufsichtigte Installation, die das Feature-Team „Bereitstellung“ verwendet, um mit dem Bereitstellungsprozess auf jedem betroffenen Computer sowie mit der Konfiguration und Platzierung der Bereitstellungsserver zu beginnen. Diese Definition enthält nicht unbedingt den genauen physischen Standort jedes Bereitstellungsservers, sollte aber kurz den Grund für die Auswahl der gewünschten Standorte beschreiben.

  • Eine ähnliche Definition der Architektur zum Erstellen von Festplattenabbildern, einschließlich einer Begründung für die Verwendung von Datenträgerabbildern, einer Beschreibung der für die Datenträgerduplizierung notwendigen Einrichtungen und einer Beschreibung der Softwaretools, die das Team verwendet, um Festplatten auf die Duplizierung (normalerweise Sysprep) vorzubereiten.

Physischer Entwurf

Der physische Entwurf beschreibt die gewünschte Architektur ausführlicher und definiert die zu verwendenden Hardwarekonfigurationen und Softwareprodukte. Der physische Entwurf dieses Projekts sollte Folgendes umfassen:

  • Spezifikationen für die im Projektumfang enthaltenen Hardwarekonfigurationen

  • Spezifikationen für die zu installierende Software

  • Die Tools, die für die Projektentwicklung verwendet werden sollen

Der Lösungsentwurf sollte generell detailliert genug sein, damit das Team in der Lage ist, mit der Arbeit am Projektplan zu beginnen.

Das Team sollte den Konzeptentwurf und den logischen Entwurf bis zum Ende der Planungsphase abschließen. Der physische Entwurf wird als gültige Basis für den Lösungsentwurf herangezogen. Er wird jedoch während des gesamten restlichen Projekts weiter verfeinert und verändert, während das Team Entwicklungs- und Bereitstellungsentscheidungen trifft und überarbeitet.

Erstellen der Funktionsbeschreibung

Die Funktionsbeschreibung richtet sich auf die Elemente, die die Lösung enthalten muss. Sie bildet den Vertrag zwischen dem Kunden und dem Projektteam und ist die Basis für das Erstellen der Projekt- und Zeitpläne. Während der Planungsphase wird die Funktionsbeschreibung als Basis verankert und der Änderungssteuerung unterstellt. Der Rollencluster „Programmmanagement“ übernimmt die Leitung beim Erstellen der Funktionsbeschreibung, in die Beiträge der Rollenleiter entsprechend ihrer Verantwortungsbereiche einfließen. Die Rollencluster „Entwicklung“, „Produktmanagement“ und „Benutzererfahrung“ arbeiten oft aktiv an der Festlegung mit, was in der Funktionsbeschreibung enthalten sein soll.

Wie beim Projektplan und Projektzeitplan besteht der primäre Zweck der Funktionsbeschreibung in der Festlegung, welche Arbeiten während der Entwicklungs-, Stabilisierungs- und Bereitstellungsphase durchgeführt werden und wie diese Arbeiten erledigt werden.

„Baseline early , freeze late“ (Basislinie früh, Einfrieren spät) ist eine bewährte MSF-Methode. Die Funktionsbeschreibung ist ein lebendes Dokument, das vom Team während des gesamten Projekts aktualisiert und ergänzt wird. Der Rollencluster „Programmmanagement“ sollte die Funktionsbeschreibung als Basis verankern, damit sie genug Details enthält, um eine genaue Planung und Terminierung zu ermöglichen. Die Entwicklung der Funktionsbeschreibung ist ein iterativer Prozess: Der Rollencluster „Programmmanagement“ sollte davon ausgehen, dass er das Dokument im Laufe des Planungsprozesses und in bestimmtem Umfang während der Entwicklungs- und Bereitstellungsphase, wenn das Dokument der Änderungssteuerung unterliegt, verfeinern und ergänzen wird. Das Team friert die Funktionsbeschreibung am Ende der Entwicklungsphase ein, bevor zur Bereitstellungsphase übergegangen wird.

Normalerweise umfasst die Erstellung der Funktionsbeschreibung zunächst die Zusammenstellung der während der Projektbeschreibungs- und Planungsphase hervorgebrachten Ergebnisse und die Identifizierung der Bereiche, die später erweitert werden sollen.

Bestimmen der Inhalte der Funktionsbeschreibung

Die Funktionsbeschreibung dokumentiert den Entwurfsprozess unter Einbeziehung des konzeptionellen, logischen und physischen Entwurfs. Dementsprechend sollten grundlegende Entwurfsentscheidungen wie die Platzierung der Server und die Netzwerkkonfiguration sowie Aspekte des physischen Entwurfs wie Konfigurations- und Initialisierungsdokumente in der Funktionsbeschreibung dokumentiert werden. Das Team erstellt einige dieser Dokumente erst in der Entwicklungs-, Stabilisierungs- oder Bereitstellungsphase. Daher ist es nicht möglich, diese Komponenten als Teil der Basislinie einzubeziehen. Für die Funktionsbeschreibung können jedoch Komponenten angegeben werden, die das Team später entwickeln muss.

Die Funktionsbeschreibung sollte einige oder alle der folgenden Elemente umfassen:

  • Eine Zusammenfassung des vereinbarten und verfeinerten Dokuments zur Festlegung des Konzepts/Umfangs, einschließlich Hintergrundinformationen, um die Lösung in einen Geschäftskontext zu stellen

  • Alle zusätzlichen Benutzer- und Kundenanforderungen, die über die bereits im Dokument zur Festlegung des Konzepts/Umfangs genannten Anforderungen hinausgehen

  • Spezifikationen der Komponenten, die Bestandteil der Lösung sein werden, z. B. Windows und 2007 Office System

Während der Projektbeschreibungsphase hat das Projektteam den durch Zeit, Budget und andere Faktoren diktierten Projektumfang definiert. Die Entscheidung, welche speziellen Komponenten zum Umfang des Projekts gehören und welche nicht, ist Bestandteil der Erstellung der Funktionsbeschreibung. Dokumentieren Sie beispielsweise folgende Elemente:

  • Welche Hardwarekonfigurationen durch die Entwicklungsarbeit unterstützt werden (z. B. Festplatten, Grafikkarten und andere Peripheriegeräte)

  • Welche Anwendungen als Teil der Basislinie einzubeziehen sind

  • Versionsinformationen für die gesamte bereitzustellende Software

  • Die Methoden, die zur Bereitstellung der Basislinien zu verwenden sind (z. B. Server und/oder CD-ROMs, Abbilder und/oder unbeaufsichtigte Installationen)

Entwickeln des Projektplans

Der Projektplan ist eine Sammlung von Plänen und behandelt die Aufgaben, die die sechs Teamrollen wahrnehmen, um das Projekt entsprechend der Definition in der Funktionsbeschreibung durchzuführen. Nicht jedes Projekt erfordert jeden hier aufgeführten Plan, und einige Projekte können sogar zusätzliche Pläne erfordern. Dieser Abschnitt umfasst die folgenden Pläne:

  • Entwicklungsplan

  • Testplan

  • Bereitstellungsplan

  • Pilotplan

  • Kommunikationsplan

  • Schulungsplan

  • Ausstattungs- und Hardwareplan

  • Budgetplan

Die meisten Pläne im Projektplan sollten nur ein paar Seiten umfassen. Der Rollencluster „Programmmanagement“ übernimmt die Leitung beim Zuweisen der zu erstellenden Pläne an die entsprechenden Rollen, unterstützt bei Bedarf die Planerstellung und stellt den Projektplan zusammen.

Um das Entwickeln des Testplans zu erleichtern, enthält BDD 2007 die Beispielarbeitshilfen Test Plan (Testplan)Test Specification(Testspezifikation) und Test Cases Workbook (Arbeitsmappe „Testfälle“). Die Arbeitshilfen Client Build Requirements (Clientbuildanforderungen) und Vision/Scope (Konzept/Umfang) unterstützen den Entwicklungsplan. Ebenso enthalten sind die Arbeitshilfen Communications Plan (Kommunikationsplan), Pilot Plan(Pilotversuchungsplan) und Training Plan (Schulungsplan).

Erstellen des Entwicklungsplans

Der Entwicklungsplan ist eine entscheidende Komponente jedes Infrastruktur-Bereitstellungsprojekts. Er beschreibt den Ansatz, den das Projektteam bei der Entwicklung der Lösung in der nächsten Phase verfolgen wird, damit die Anforderungen des Konzepts und Projektumfangs erfüllt werden. Der Rollencluster „Entwicklung“ übernimmt beim Erstellen dieses Plans die Leitung.

Zu den Bereichen, die der Entwicklungsplan abdecken kann, gehören:

  • Teamrollen und Zuständigkeiten – beschreiben Sie insbesondere die Zuständigkeitsbereiche jedes Entwicklers genau.

  • Eine Liste und Beschreibung aller Ergebnisse, die die Entwickler liefern werden. Hierzu gehören in der Regel:

    • Die konkreten erstellten Skripts, einschließlich aller Änderungen an den Skripts und Konfigurationsdateien

    • Eine Beschreibung der Basisarchitektur und der Schritte, die das Team zu deren Bereitstellung unternimmt

    • Eine Liste der zusätzlichen Anwendungen, die als Teil der Basislinie bereitgestellt werden sollen, einschließlich 2007 Office System, zusammen mit allen Installationspaketen, die das Team erstellen oder anpassen muss

    • Die Art der Dokumente, z. B. Installationsverfahren und Softwarekonfigurationen, die der Rollencluster „Entwicklung“ während der Entwicklungsphase vermutlich erstellen wird

  • Eine kurze Darstellung des Ansatzes des Teams für die Verwendung von unbeaufsichtigten Installationen und Datenträgerabbildern Gehen Sie im Bereitstellungsplan genauer auf diesen Aspekt ein.

  • Pläne für vorläufige Builds, einschließlich wie viele zu erstellen sind und welche Aspekte der Lösung von jedem vorläufigen Build abgedeckt werden

Obwohl der Entwicklungsplan primär für die Entwickler vorgesehen ist, hat der Plan zusätzlich zum Ziel, Prozesse und Pläne zu formalisieren, die den Support und die laufende Verwaltung der Lösung unterstützen. Wenn das Projektteam die Verantwortung für die Lösung an das ständige Support- und Betriebspersonal übergibt, sollte die letztere Gruppe diese Dokumente (die Themen wie Installationsverfahren und Softwarekonfigurationen abdecken) verwenden können, um Windows auf neuen Computern bereitzustellen und technischen Support zur Verfügung zu stellen. Die Entwickler sollten sich bemühen, diese Dokumentation zur selben Zeit abzuschließen und vorzulegen, zu der sie die entsprechenden Lösungsskripts vorlegen, damit das Support- und Betriebspersonal sofortigen Zugriff auf alle verfügbaren Informationen zur Lösung hat.

Erstellen des Testplans

Der Testplan skizziert die Strategie, die das Team zum Testen der Lösung verwendet. Bei dieser Lösung werden verschiedene Testpläne generiert. Für die allgemeine Initiative richtet sich der Testplan auf die Überprüfung der Prozesse, Abbilder und Infrastruktur, die zur Bereitstellung der neuen Desktopabbilder und der erforderlichen zusätzlichen Anwendungen benötigt werden. Das Feature-Team „Anwendungskompatibilität“ benötigt einen ausführlichen Testplan, um die relevanten zu testenden Geschäftsanwendungen und die durchzuführenden Tests zu identifizieren. Das Feature-Team „System zum Erstellen von Computerabbildern“ muss die unterstützten Hardwareprofile der Zielinfrastruktur definieren und die verschiedenen Abbilder für spezifische Treiberanforderungen der Hardware testen. Ein wesentlicher Teil der Migrationsinitiative wird mit dem Testen verbracht. Nehmen Sie sich daher die Zeit, die Testanforderungen zu identifizieren und dementsprechend zu planen.

Der Rollencluster „Test“ übernimmt normalerweise beim Erstellen des Testplans die Leitung. Die zu behandelnden Bereiche umfassen:

  • Eine Beschreibung der Testumgebung. Diagramme und schematische Darstellungen können bei der Veranschaulichung der Umgebung helfen.

  • Die Änderungssteuerung und wie sie durchgesetzt wird

  • Verfahren zum Verfolgen von Problemen. Beschreiben Sie die Datenbank zur Problemverfolgung, die Sie verwenden werden, einschließlich des zu ihrer Erstellung verwendeten Programms, wer Zugriff darauf haben wird und die zu verwendenden Felder.

  • Die für das Testen der einzelnen Lösungsteile verantwortlichen Personen

  • Testmatrizen, die angeben, welche Komponenten der Lösung von den Teammitgliedern getestet werden müssen und wie sie zu testen sind. Ein Team kann z. B. planen, Testmatrizen für die Installation, die Konfiguration, das Betriebssystem und die Anwendungssuite zu entwickeln.

  • Die Materialien, die das Projektteam für die Entwicklungs- und Testumgebungen erstellen muss

Der Testplan sollte die Arten der Tests festlegen, die das Team während der Entwicklungsphase durchführt. Zu den typischen Testtypen gehören:

  • Installationstests: Installationstests stellen sicher, dass jede Komponente fehlerfrei installiert wurde. Der Tester installiert einen Build und überprüft, ob Windows Setup korrekt ausgeführt und abgeschlossen wird, ob das Setup der Anwendungen und die Konfigurationsprogramme korrekt ausgeführt und abgeschlossen werden und ob durch den Prozess jede im Build enthaltene Komponente korrekt installiert wird.

  • Konfigurationstests: Konfigurationstests stellen sicher, dass beim Installationsvorgang jede Komponente entsprechend der Beschreibung in der Konfigurationsdokumentation korrekt konfiguriert wird.

  • Funktionalitätstests: Funktionalitätstests stellen sicher, dass grundlegende Betriebssystem- und Anwendungsfunktionen wie erwartet fehlerfrei funktionieren. Die Funktionalitätstests stellen keine Wiederholung der Tests dar, die die Hersteller der Hardware und Software durchgeführt haben. Stattdessen werden typische Verwendungsszenarien überprüft. In dieser Hinsicht lassen sich Funktionalitätstests mit Benutzerakzeptanztests vergleichen, außer dass die Teammitglieder die Funktionalitätstests vor den Benutzerakzeptanztests durchführen.

  • Benutzerakzeptanztests: Benutzerakzeptanztests stellen sicher, dass das System als Ganzes in einer für die Benutzer geeigneten Weise funktioniert. Normalerweise wird bei diesen Tests die Lösung einigen Benutzern sowie IT-Bereitstellungspersonal zur Verfügung gestellt und überprüft, ob sie die Lösung für die Durchführung ihrer Aufgaben verwenden können.

Das Team kann auswählen, ob es gemäß den Anforderungen des Projekts weitere Arten von Tests durchführen möchte, z. B. Regressionstests und Konformitätstests.

Erstellen des Bereitstellungsplans

Der Bereitstellungsplan skizziert die Strategie, die das Team zum Bereitstellen der Lösung verwendet. Die Hauptfunktion des Plans besteht in der Festlegung, welche Aufgaben während der Bereitstellung durchgeführt werden müssen und von wem sie zu erledigen sind. Zu diesem Zweck kann der Bereitstellungsplan z. B. folgende Informationen umfassen:

  • Ob das Team plant, die Lösung phasenweise oder auf einmal bereitzustellen

  • Die Reihenfolge, in der die Standorte die Lösung, falls zutreffend, erhalten werden

  • Ob internes IT-Personal oder externe Berater die Bereitstellung durchführen werden

  • Checklisten, die die Teammitglieder zur Durchführung der Bereitstellungsaufgaben an den einzelnen Standort verwenden werden. Das Team erstellt diese Checklisten später im Projekt.

  • Pläne für eine Datenbank zur Verfolgung der Anforderungen der Benutzer

  • Zu verwendende Verfahren für die Migration von Daten und Anwendungen zu Windows nach einer sauberen Installation auf einem vorhandenen Computer und für das Testen migrierter Anwendungen

  • Umgang mit Feedback von Benutzern, die von der Bereitstellung betroffen sind

Der Rollencluster „Freigabeverwaltung“ übernimmt normalerweise beim Entwickeln dieses Plans die Leitung.

Erstellen des Pilotplans

Der Pilotplan beschreibt die Ziele des Teams für die Durchführung des Pilotversuchs, um die vollständige Bereitstellung optimal vorzubereiten. Der Rollencluster „Produktmanagement“ oder „Freigabeverwaltung“ übernimmt normalerweise beim Entwickeln dieses Plans die Leitung.

Dies stellt gewöhnlich einen guten Zeitpunkt im Planungsprozess für die Auswahl einer Gruppe für den Pilotversuch dar, sofern dies nicht durch politische, organisatorische oder andere Interessen verhindert wird. Um sicherzustellen, dass die Pilotgruppe optimales Feedback für das Feature-Team „Bereitstellung“ liefert, sollte die für den Pilotversuch ausgewählte Gruppe für das Unternehmen als Ganzes repräsentativ sein. Der Rollencluster „Produktmanagement“ (oder in einigen Fällen der Rollencluster „Freigabeverwaltung“) sollte die Bemühungen zum Finden einer Pilotgruppe leiten. Wenn das Team bereits eine gute Vorstellung davon hat, welche Gruppe für den Pilotversuch verpflichtet werden kann, fügen Sie dem Pilotplan diese Information hinzu. Andernfalls halten Sie die Kriterien des Teams für eine ideale Pilotgruppe fest, einschließlich Überlegungen wie:

  • Die Anzahl der Benutzer, die die Pilotbereitstellung umfassen soll

  • Die Hardwarekonfigurationen, die in der Pilotgruppe vertreten sein sollten

  • Alle Standortüberlegungen, z. B. ob Benutzer an einem einzigen physischen Standort oder über entfernte Büros verteilt verwendet werden sollen

  • Politische oder organisatorische Erwägungen

Der Pilotplan sollte neben der Beschreibung der Eigenschaften der Pilotgruppe die Merkmale des Pilotversuchs selbst angeben, beispielsweise:

  • Wie lange der Pilotversuch dauert

  • Welche Komponenten der Lösung in den Pilotversuch einbezogen werden

  • Wie das Feedback aus dem Pilotversuch zu behandeln ist, einschließlich der Festlegung, ob infolge des Feedbacks Änderungen an der Lösung vorgenommen werden sollen

  • Die Erfolgskriterien des Pilotversuchs

Erstellen des Kommunikationsplans

Der Kommunikationsplan beschreibt, wie das Team mit den Gruppen kommuniziert, die die Lösung betrifft. Geben Sie alle Personen, die ein Interesse an der Lösung haben, und den Grad der notwendigen Kommunikation an. Dies umfasst normalerweise nicht nur Benutzer, sondern auch Support- und Helpdeskpersonal, andere IT-Mitarbeiter, das für die Erstellung des Projektbudgets verantwortliche Verwaltungspersonal, Personal, dessen Arbeit durch projektbezogene Aktivitäten unterbrochen wird, und weitere Personen.

Der Kommunikationsplan sollte Kommunikationsstrategien für jede der identifizierten Personengruppen festlegen, die vom Projekt betroffen sind. Das Team besitzt wahrscheinlich eine große Auswahl an Kommunikationsoptionen, einschließlich:

  • Persönlichen Besprechungen

  • E-Mail, einschließlich Adressenlisten

  • Gedruckten oder elektronischen Newslettern. Dieser Schritt kann entweder die Veröffentlichung eines projektspezifischen Newsletters oder die Einbindung der Projektinformationen in vorhandene Newsletter des Unternehmens umfassen. Berücksichtigen Sie IT-Newsletter oder Bulletins, abteilungsspezifische oder standortspezifische Newsletter und unternehmensweite Bulletins.

  • Informativen Intranetwebsites

  • Voicemail

Der Kommunikationsplan sollte Strategien bereitstellen, mit denen sichergestellt werden kann, dass jede betroffene Gruppe die benötigten Informationen zum richtigen Zeitpunkt erhält, ohne dass sie mit zu vielen Informationen belastet wird. Teil dieser Aufgabe ist die Auswahl von Personen mit Kommunikationsgeschick für die Bereitstellung dieser Informationen. Im Plan sollten die Personen angegeben werden, die für die Weitergabe der gewünschten Botschaften an die Personen, die diese Informationen kennen müssen, verantwortlich sind.

Erstellen des Schulungsplans

Der Rollencluster „Benutzererfahrung“ übernimmt normalerweise beim Entwickeln des Schulungsplans die Leitung. Genau wie beim Kommunikationsplan sollte die Rolle die verschiedenen Zielgruppentypen betrachten, die eine Schulung benötigen. Im Grunde gibt es zwei weit gefasste Kategorien von Personen, die zu berücksichtigen sind: Benutzer und IT-Personal, einschließlich Systemadministratoren und Helpdeskpersonal. Die Rolle kann in Abhängigkeit von den Anforderungen des Projekts andere Kategorien identifizieren.

Für die Durchführung von Schulungen gibt es mehrere mögliche Methoden. Die Entwicklung eines Schulungsplans wird immer innerhalb der Grenzen des Projekts realisiert. Zu den Faktoren, die beeinflussen können, wie die Schulung durchgeführt wird, gehören das Vorwissen der Benutzer, Zeit, Budget und die Verfügbarkeit von qualifiziertem Schulungspersonal und von Mitarbeitern, die Schulungen entwickeln. Die Unternehmenskultur und die Art der Geschäftstätigkeit können bestimmte Schulungsmittel sowie die Dauer oder das technische Niveau der Schulung diktieren.

Wenn die Benutzer im Unternehmen zum Beispiel mit Windows XP und Windows 2000 vertraut sind, ist kein großer Schulungsaufwand nötig, damit sie mit Windows Vista die gleiche oder eine bessere Produktivität erzielen. Zusätzliche Schulungen können sie jedoch in die Lage versetzen, die Vorteile der neuen Features von Windows Vista besser zu nutzen und ihre Produktivität weiter zu steigern. IT-Spezialisten benötigen normalerweise intensivere Einführungen in die Unterschiede zwischen Windows 2000, Windows XP und Windows Vista.

Zudem sollten Benutzer, die Microsoft Office XP oder Office 97 verwendet haben, den Umgang mit späteren Versionen von Microsoft Office System ohne großen Schulungsaufwand erlernen können. Ein Ansatz zur Berücksichtigung dieser Fälle ist ein einfaches webbasiertes Ressourcenhandbuch, durch das die Benutzer die neuen Features von Windows Vista und 2007 Office System kennen lernen und erfahren können, wie sie damit ihre Produktivität verbessern können.

Wenn Benutzer nicht mit dem Windows-Betriebssystem und 2007 Office System vertraut sind und zusätzliche Schulungen benötigen, stehen mehrere Optionen zur Verfügung. Dazu gehören:

  • Praktische Schulungen, bei denen der Benutzer die Verwendung der Software erlernt, indem er damit arbeitet

  • Schulungen im Präsentationsstil, bei denen der Benutzer in der Verwendung der Software unterrichtet wird

  • Computerbasierte Schulungen (Computer-based Training, CBT) oder webbasierte Schulungen (WBT), bei denen sich der Benutzer anhand spezieller Schulungssoftware weiterbilden kann

  • Persönliche Schulungen

  • Arbeitshilfen oder Arbeitsblätter

Bei der Entwicklung von Schulungen für IT-Mitarbeiter sollten Sie überlegen, ob sie den gesamten unbeaufsichtigten Installationsvorgang oder nur Teile davon verstehen müssen, und ob sie wissen müssen, wie die Basiskonfiguration eines Computers wiederhergestellt wird. Berücksichtigen Sie praktische Schulungen und Methoden für das Selbststudium. Die Dokumente, die das Team im Rahmen der Funktionsbeschreibung erstellt, können für das IT-Personal eine wertvolle Lernhilfe sein.

Hinweis   Microsoft Learning Solutions ist eine kostengünstige Lern- und Bildungslösung, die wertvolle Softwareschulungen und Referenzmaterialien zu Microsoft-Produkten und -Technologien bietet. Weitere Informationen zu Microsoft Learning Solutions finden Sie unter http://www.microsoft.com/learning/mls. Darüber hinaus bietet Microsoft Press® verschiedene Bücher und Unterrichtsmittel an, die Sie für die Schulung berücksichtigen können. Weitere Informationen zu diesen Materialien, einschließlich Bestellinformationen, finden Sie auf der Microsoft Press-Website unter http://mspress.microsoft.com.

Der Schulungsplan sollte den Ansatz des Projektteams für die Schulung unter Berücksichtigung aller Einschränkungen oder Anforderungen beschreiben und erklären, warum das Team diesen Ansatz gewählt hat.

Erstellen des Ausstattungs- und Hardwareplans

Wenn das Projekt die Bereitstellung der Lösung auf vorhandenen Computersystemen umfasst, sollten Sie die Erstellung eines Ausstattungs- und Hardwareplans in Betracht ziehen, der detailliert beschreibt, wie viele Computersysteme im Unternehmen diese Voraussetzungen erfüllen und wie viele nicht. Wenn eine bedeutende Anzahl der Computer die Anforderungen von Windows Vista oder einer der bereitzustellenden Softwareanwendungen nicht erfüllt, beschreiben Sie mithilfe dieses Plans, wie das Team bei diesen Computern vorgehen wird. Mögliche Vorgehensweisen umfassen:

  • Die Bereitstellung nur auf den Computern vornehmen, die die Lösung ausführen können und die anderen unverändert lassen, bis sie später aktualisiert oder ersetzt werden

  • Updates und den Ersatz der weniger leistungsfähigen Computer im Laufe der Zeit planen und die Aktualisierungskosten in das Projektbudget einbeziehen

  • Neue Hardware erwerben, z. B. Arbeitsspeicher und Festplatten für die weniger leistungsfähigen Computer, um sie in Einklang mit der Projektspezifikation zu bringen

Genau wie bei den anderen Komponenten des Projektplans gibt es mehrere Möglichkeiten, um den Ausstattungs- und Hardwareplan zu entwickeln. Die von Zeit, Budget und anderen externen Faktoren auferlegten Beschränkungen diktieren zum Teil den Ansatz des Teams.

Der Rollencluster „Programmmanagement“ oder „Freigabeverwaltung“ übernimmt normalerweise beim Entwickeln dieses Plans die Leitung. Ein Bereich, der im Ausstattungs- und Hardwareplan sorgfältig berücksichtigt werden sollte, ist die eventuell während des Bereitstellungsprozesses erforderliche Speicherkapazität. Beim Bereitstellungsprozess können zwei Optionen die Größe des bei der Bereitstellung benötigten Serverspeicherplatzes erheblich beeinflussen. Die erste Option ist die Verwendung von USMT, um alle Benutzerdateien und Einstellungen des Computers auf einer Netzwerkfreigabe des Datenservers zu speichern. Diese Option kann die Größe des auf dem Datenserver erforderlichen Speicherplatzes schnell in die Höhe treiben. Bei der zweiten Option wird vor der Migration ein Sicherungsabbild des gesamten Computers erstellt. Pro Benutzer kann diese Option die Größe des erforderlichen Serverspeicherplatzes um Gigabytes erhöhen. Die meisten Unternehmen speichern diese Daten nur vorübergehend, sodass die Datenträgeranforderungen nur für kurze Zeit gelten. Teams können diese Optionen auf der Basis „Kann je nach Benutzer geändert werden“ realisieren.

Eine ausführliche Beschreibung der Kapazitätsanforderungen finden sie im Lite Touch-Installationshandbuch.

Erstellen des Budgetplans

Wenn die Kosten eine entscheidende Rolle dabei spielen, wie das Team die Lösung implementiert – was meistens der Fall ist – sollte das Team einen Budgetplan entwerfen, der genau beschreibt, wie das vorhandene Geld ausgegeben wird. Der Budgetplan sollte die letzte Komponente des Projektplans sein. Der Rollencluster „Programmmanagement“ übernimmt beim Entwickeln dieses Plans die Leitung und wartet, bis der restliche Projektplan vollständig ist, bevor das Budget festgelegt wird. Dadurch wird sichergestellt, dass im Budget alle Elemente so genau wie möglich berücksichtigt werden. Zu den Bereichen, die beim Erstellen eines Budgets für das Projekt zu berücksichtigen sind, gehören:

  • Die Software, die das Unternehmen für die Lösung erwerben oder lizenzieren muss, einschließlich Windows, 2007 Office System und sämtlicher Software, die nicht von Microsoft stammt und im Rahmen der Lösung bereitgestellt werden soll

  • Entwicklungstools oder andere Software, die das Projektteam im Rahmen des Bereitstellungsprozesses erwirbt

  • Hardware und Netzwerkgeräte, die das Team bereitstellt oder bei der Entwicklung verwendet

  • Lieferanten oder andere externe Spezialisten, die das Team mit der Unterstützung der Entwicklung, Tests, Schulungen oder anderen projektspezifischen Aktivitäten beauftragt.

  • Schulungskurse oder andere Schulungshilfen

Erstellen des Projektzeitplans

Der Projektzeitplan ist eine Zusammenstellung der Zeitpläne, die von den Teammitgliedern zur Planung ihrer Aktivitäten erstellt werden. Er kann, soweit erforderlich, einige oder alle der folgenden Zeitpläne enthalten:

  • Einen Entwicklungszeitplan

  • Einen Testzeitplan

  • Einen Benutzererfahrungszeitplan

  • Einen Freigabeverwaltungszeitplan

  • Einen Bereitstellungszeitplan

Jede Rolle kann ihren Zeitplan wahlweise nach Funktionsbereichen unterteilen. Wenn z. B. verschiedene Entwicklungsunterteams an den Imaging- und Anwendungspaketarchitekturen arbeiten, könnte jedes Unterteam einen eigenen Zeitplan erstellen.

Erstellen von Projektzeitplänen

Jeder Leiter einer Rolle nimmt eine funktionale Aufschlüsselung der Zuständigkeiten der Rolle vor und ordnet sie nach Priorität, während die Teammitglieder eine Einschätzung auf Aufgabenebene durchführen. Die Länge einer einzelnen Aufgabe sollte zwischen einem halben Tag und einer Woche liegen. Wenn die Aufgabendauer zu kurz ist, könnte der Aufwand beim Verwalten der Aufgabe zu hoch sein. Wenn die Aufgabendauer zu lang ist, ist es schwierig, den Umfang der Arbeiten zu verwalten.

Neben der Planung der Aufgabendauer sollten die Teammitglieder, die die Zeitpläne erstellen, den Aufgaben Namen zuweisen. Nachdem das Dokument zur Festlegung des Konzepts/Umfangs, das Dokument mit dem Lösungsentwurf und die Projektpläne erstellt wurden, sollten die Leiter der Rollen wissen, welche Teammitglieder für bestimmte Bereiche verantwortlich sein werden. Anhand von Zeitplänen lassen sich diese Aufgaben konkretisieren, sodass alle Teammitglieder wissen, was sie wann zu erledigen haben.

Projekte dieser Art können von einigen Wochen bis hin zu mehreren Monaten dauern. Wenn Sie die Zeitplanung für das Projekt durchführen, berücksichtigen Sie Faktoren wie:

  • Die Größe des Unternehmens

  • Den Umfang der Bereitstellung

  • Die Anzahl der betroffenen Hardwarekonfigurationen

  • Die Anzahl der zu unterstützenden Anwendungen

  • Die Methode für die Datenmigration

  • Die Verfügbarkeit von Ressourcen

  • Der erforderliche Grad der Anpassung

  • Die Anforderungen verschiedener Gruppen, die Änderungen der Funktionsbeschreibung bewirken

  • Ob das Projektteam von Drittanbietern unterstützt wird, z. B. von Beratern, die Erfahrung mit ähnlichen Projekten haben

Die Entwicklungsphase in typischen Desktopbereitstellungsprojekten in mittelgroßen (von 5000 bis 10.000 betroffenen Benutzern) und großen (mehr als betroffene 10.000 Benutzer) Unternehmen kann 6 - 10 Wochen dauern. Projektmanagementsoftware wie Microsoft Office Project kann bei der Erstellung des Projektzeitplans helfen. Projektmanagementsoftware bietet Features, mit denen die Teams den Aufgaben eine Dauer, Ressourcen und Voraussetzungen zuweisen können, und ermöglicht die automatische Berechnung wichtiger Termine.

Zusammenstellen des Projektzeitplans

Der Rollencluster „Programmmanagement“ sammelt und koordiniert die Zeitpläne, die die unterschiedlichen Rollen vorlegen, damit die Teammitglieder effektiv arbeiten können. Das resultierende Dokument ist der Projektzeitplan.

Der Rollencluster „Programmmanagement“ sollte Pufferzeiten in den Zeitplan einbauen, um Störungen des Zeitplans zu kompensieren, die durch unvorhergesehene Verzögerungen verursacht werden. Die Teammitglieder sollten die Pufferzeiten nicht als Entwicklungspolster ansehen und sie nur verwenden, wenn es unvermeidlich ist und im Ermessen des Programmmanagers liegt. Um die Pufferzeiten vor äußeren Einflüssen zu schützen, legen Sie interne Meilensteine fest, die nur das Team sehen kann und durch die Pufferzeiten von dem nach außen hin sichtbaren Meilenstein getrennt sind (siehe Abbildung 5). Das Team könnte z. B. planen, die Entwicklungsphase bis zum 10. April abzuschließen, aber den 17. April als nach außen hin sichtbares Meilensteindatum für den Abschluss der Entwicklungsphase festlegen. Die Zeitspanne zwischen dem 10. April und dem 17. April ist die Pufferzeit.

Abbildung 5: Planen der Pufferzeit

Erstellen der Entwicklungs- und Testumgebung

Eine Hauptaufgabe in der Planungsphase ist der Aufbau einer Umgebung, in der die Teammitglieder die Lösung entwickeln und testen können, ohne die tägliche Arbeit der anderen Benutzer zu stören. Die Entwicklungsumgebung sollte von der Testumgebung physisch getrennt sein, obwohl sie sich einige Ressourcen zu unterschiedlichen Zeiten teilen können.

Die Entwicklungs- und Testumgebung wird normalerweise als das Laborbezeichnet, obwohl sie vielleicht nicht immer von der vorhandenen Produktionsumgebung physisch getrennt ist. Bevor Sie das Labor einrichten, wägen Sie die Kosten und die Vorteile der physischen Trennung ab. Im Gegensatz dazu sollten alle Entwicklungs- und Testarbeiten nach Möglichkeit in einem isolierten Netzwerk oder in einem nicht für die Produktion genutzten Windows-Domänen- und Netzwerksegment stattfinden. Produktive Benutzer sollten keinen Zugriff auf die Computerressourcen im Labor erhalten, und die von den Entwicklern und Testern durchgeführten Arbeiten sollten die Arbeit der Benutzer nicht beeinträchtigen.

Das Labor sollte mindestens einen Computer für jede Hardwarekonfiguration enthalten, die im physischen Entwurf identifiziert wurde. Denken Sie daran, dass die Computer von den Rollenclustern „Entwicklung“ und „Test“ gemeinsam, jedoch nicht gleichzeitig, verwendet werden können. Verwenden Sie dieses Arrangement bei Bedarf, um die Entwicklungskosten zu senken. Der Rollencluster „Entwicklung“ könnte z. B. einige Computer und Domänen verwenden und sie später in der Entwicklungsphase an den Rollencluster „Test“ übergeben.

Entwerfen Sie die Testumgebung so, dass die Produktionsumgebung so gut wie möglich emuliert wird – wie im folgenden Beispiel:

Das WAN (Wide Area Network) des Unternehmens umfasst 540 Computer in sechs grundlegenden Hardwarekonfigurationen. Das WAN ist ein virtuelles privates Netzwerk (VPN) und besteht aus dem Hauptsitz in Minneapolis, fünf Vertriebsniederlassungen in Minnesota , Wisconsin und South Dakota, die über T-1-Leitungen mit dem Internet verbunden sind, und einem Kundendienstzentrum in Eden Prairie , Minnesota , mit einer ADSL-Verbindung (Asymmetric Digital Subscriber Line). Die Testumgebung wird einen Computer für jede Hardwarekonfiguration enthalten , und jeder von ihnen wird von Zeit zu Zeit entweder direkt mit dem lokalen Netzwerk (LAN) des Unternehmens oder mit dem Internet verbunden sein , entweder über eine T-1-Standleitung oder über eine im Testlabor installierte ADSL-Leitung.

Zwischenmeilenstein: Technologieüberprüfung abgeschlossen

Um diesen Meilenstein zu erreichen, muss das Projektteam die Technologiekomponenten der Lösung auf fabrikneuer Hardware in der am besten geeigneten Umgebung manuell installieren. Die Ziele dieses Meilensteins bestehen darin, fremde Variablen zu minimieren und sicherzustellen, dass die Technologiekomponenten funktionieren und der Funktionsbeschreibung entsprechen.

Hauptmeilenstein: Projektpläne genehmigt

Beim Meilenstein „Projektpläne genehmigt“ kommen das Projektteam und wichtige Projektverantwortliche überein, dass die Zwischenmeilensteine erfüllt wurden, die Fälligkeitstermine realistisch sind, die Projektrollen und Zuständigkeiten genau definiert wurden und Mechanismen für die Behandlung der Projektrisikobereiche vorhanden sind. Die Funktionsbeschreibung, der Projektplan und der Projektzeitplan bilden die Basis für zukünftige Entscheidungen über Kompromisse.

Nachdem das Team die Spezifikationen, Pläne und Zeitpläne genehmigt hat, werden die Dokumente zur Basislinie des Projekts. In der Basislinie werden die verschiedenen Entscheidungen berücksichtigt, die durch Konsens erreicht werden, indem die drei Projektplanungsvariablen angewendet werden: Ressourcen, Zeitplan und Features. Nachdem die Basislinie abgeschlossen und genehmigt wurde, wird sie der Änderungssteuerung unterstellt. Dies bedeutet nicht, dass alle in der Planungsphase erreichten Entscheidungen endgültig sind. Es bedeutet jedoch, dass das Team während des Fortschritts der Arbeiten in der Entwicklungsphase alle vorgeschlagenen Änderungen an der Basislinie formell überprüfen und genehmigen sollte.

Checkliste für die Planungsphase

Bevor Sie zur Entwicklungsphase übergehen, sollten die folgenden Elemente behandelt worden sein:

  • Anwendungsliste, SMEs und Medien

  • Erstellung der Anwendungspakete hat begonnen

  • Migrationsplan für die Kernanwendungen

  • Funktionsbeschreibung wurde genehmigt

  • Laborumgebung für Entwicklung und Tests eingerichtet

  • Netzwerkdiagramme erstellt und analysiert

  • Überprüfung/Bewertung der Funktionsbeschreibung im Hinblick auf die Betriebsabläufe

  • Projektplan erstellt

  • Projektzeitplan erstellt

  • Risikomanagementplan aktualisiert und überprüft

  • Sicherheitsrichtlinien, Strategien und Konfiguration

  • Überprüfung/Bewertung der Funktionsbeschreibung im Hinblick auf die Sicherheit

  • Technologischer Ansatz wurde überprüft

  • Testplan erstellt

  • Inventur der Computeranwendungen durchgeführt und überprüft

  • Inventur der Computerhardware durchgeführt und überprüft

Übergang in die Entwicklungsphase

Nachdem alle Aufgaben der Planungsphase abgeschlossen wurden, muss das Team formell darin übereinkommen, dass das Projekt den Meilenstein „Projektpläne genehmigt“ erreicht hat. Durch den Abschluss dieses Meilensteins erklären die Teammitglieder, dass sie mit den Arbeiten in ihren jeweiligen Zuständigkeitsbereichen zufrieden sind.

Wie zuvor bestätigen die Projektteams das Erreichen eines Meilensteins in der Regel mit einer formellen Abnahme (Abzeichnung), einschließlich der Abzeichnung durch den Kunden und andere wichtige Projektverantwortliche. Das Abnahmedokument wird zu einem Projektergebnis und für zukünftige Zwecke archiviert.

Anzeigen: