Was sollte in einem umfassenden „Angriffsplan“-Dokument enthalten sein?

Es ist üblich, dass die meisten Softwareentwicklungsprozesse mit einem Angriffsplan beginnen, in dem Sie die folgenden Themen finden können:

  1. Der Kontext des Kundenunternehmens
  2. Eine Zusammenfassung der zu verbessernden Geschäftsprozesse
  3. Der aktuelle Geschäftsstand (was automatisiert werden soll)
  4. Eine klare Beschreibung der anstehenden Aufgabe
  5. Die Projektaktivitäten
  6. Der Umfang des Projekts
  7. Die Planung
  8. Die zu liefernden Produkte
  9. Die Projektrisiken und die Bemühungen, die Auswirkungen zu minimieren.

Momentan mache ich meinen Angriffsplan. Ich frage mich, ob die oben genannten Informationen ausreichen oder ob es besser ist, weitere Informationen in diesen Plan aufzunehmen.

Meine Frage an Sie alle ist, was halten Sie von der Erwähnung der oben genannten Themen im Angriffsplan, welche Informationen würden Sie beschreiben und welche Erwartungen würden Sie haben, wenn Sie in der Rolle eines Kunden oder eines sind Projektmitglied?

Wir können nicht beurteilen, ob es für Ihren Anwendungsfall "ausreicht". Warum sagen Sie uns nicht, ob Sie der Meinung sind, dass die Schritte, die Sie haben, Ihnen genügend Informationen liefern, um an Ihrem Projekt zu arbeiten? Wenn nein, warum nicht?
Das Projekt ist mein erstes formelles Projekt, ich habe bereits Pläne, die das oben Erwähnte beinhalten. Ich habe mich gefragt, ob es ausreicht, da sich das Projekt in einem Lernkontext befindet und es keinen echten Kunden gibt. Aus diesem Grund wollte ich, dass erfahrene Leute ihre Meinung dazu äußern, was in einem Angriffsplan enthalten sein sollte und was nicht.
Vielleicht möchten Sie das Konzept einer „Projektcharta“ erforschen; Im Internet gibt es mehrere Beispiele. Es scheint, dass Sie versuchen, die Phasen des PMI-Projektmanagements neu zu erfinden. Obwohl nicht jeder sie liebt, halte ich es für einen Fehler, sie zu ignorieren.

Antworten (3)

Ich stimme Mark in Bezug auf das Artefakt der Projektcharta zu. Es richtet im Wesentlichen ein Projekt ein. In Bezug auf Pläne im Allgemeinen gilt jedoch: Wenn Sie das Wer, Was, Wo, Wann, Warum und Wie beantworten können, haben Sie einen Plan. Egal, ob Sie sich noch in der Strategiephase befinden oder zur Taktik hinunterfahren, diese Fragen müssen so beantwortet und beantwortet werden, dass eine andere Person sie greifen und loslegen kann. Alles andere hinzuzufügen (das ist kein zerlegtes Thema dieser grundlegenden Fragen) ist das Sahnehäubchen.

Ich weiß nicht, ob ich eine „Wo“-Frage für die Projektplanung formulieren kann, abgesehen von einer Ressourcenfrage wie „Haben wir einen Ort, an dem wir das Team unterbringen oder unsere Widgets aufbewahren können?“ Ich stimme Ihrer Prämisse (offensichtlich) zu, aber ich würde gerne ein praktisches Beispiel für eine Wo -Planungsfrage sehen.
Ihre Beispiele sind genau das. Wo wird gearbeitet? Wohin müssen die Rohstoffe? Wo bewahre ich dieses Artefakt auf? Wo finde ich xxx oder yyy?

TL;DR

Sie erfinden Ihre eigenen Begriffe für gängige Projektmanagement-Artefakte. Was Sie beschreiben, ist allgemein als Projektauftrag oder Projektmandat bekannt, obwohl einige Methoden möglicherweise andere Begriffe für diese Art von Ergebnis der Projektinitialisierung verwenden.

Wenn Ihre Organisation hierfür noch keinen Prozess definiert, fragen Sie Ihre Stakeholder , welchen Detaillierungsgrad sie benötigen. Niemand außerhalb der Organisation kann diese Entscheidung für Sie treffen.

Formale Methoden der Projektinitiierung

Eine Quelle beschreibt zwei der formalen Methoden zur Dokumentation der Projektinitiierung und zitiert Beispiele aus dem PMBOK und PRINCE2. Es enthält sogar Vorlagen für Projektcharta und Projektmandat .

Diese Vorlagen sind nicht unbedingt kanonisch, aber sie liefern sicherlich nützliche Beispiele. Sie können Ihre eigene Checkliste und Ihr eigenes Format verwenden, wenn diese Ihren Anforderungen besser entsprechen.

Das Notwendigste

Unabhängig von Ihrer Methodik sollte ein Projektinitiierungsdokument die folgenden wesentlichen Punkte abdecken:

  • Was ist das Ziel des Projekts?
  • Wann muss das Projekt abgeschlossen sein?
  • Wer ist an dem Projekt beteiligt?
  • Wie messen Sie den Erfolg oder Misserfolg des Projekts?

Andere Elemente wie Budget, Ressourcen, Umfang usw. sind wirklich zusätzliche Detailebenen, die sich mit dem Vorhergehenden befassen. Es liegt an der Organisation und dem Projektmanager zu bestimmen, welcher Detaillierungsgrad zur Definition des Projekts erforderlich ist.

Und vor dem Ersten Tag war Nichts.

Dann blickte das Führungsteam auf das Nichts und sagte: „Los, das ist nicht gut, da unsere Wettbewerbsfähigkeit gefährdet ist.“

Und so entwickelte der Sponsor am ersten Tag sein Mandat und gab es seinem Champion und Projektmanager, um es richtig zu machen.

Und am zweiten Tag arbeiteten der Champion und der Projektmanager mit dem Führungsteam zusammen, um die wichtigsten Stakeholder zu identifizieren, die konsultiert werden müssen. Und sie blickten auf diese Liste und sagten: „Das reicht in diesem Stadium“.

Und am Ende des dritten Tages ermöglichten der Champion und der Projektmanager eine Diskussion zwischen den Hauptakteuren, um die Vision zu identifizieren, die die Identifizierung von Wünschen und Bedürfnissen einleitete. Und die Wants wurden kurzerhand als zu kostspielig eingestuft, aber die Needs wurden so gehalten, wie sie notwendig waren.

Am vierten Tag wurden die Anforderungen zu einer Projektproduktbeschreibung entwickelt, sodass sich alle darauf einigen konnten, was gebaut werden sollte, und einen allgemeinen Projektansatz sowie Kosten, Ressourcen und Zeitplan auf sehr hohem Niveau in einem zusammenfassenden Business Case abschätzen konnten das Führungsteam am fünften Tag.

Und das Führungsteam sagte: „Wir könnten hier etwas haben.“

Und mit dieser Genehmigung am sechsten Tag begann eine detailliertere Untersuchung der Projektprodukte, ihrer Kosten und Vorteile, bis zu dem Punkt, an dem die Planung für das Projekt durchgeführt wurde, einschließlich der Definition von Umfang, Budget, Ressourcen, Zeitplan, Risiko, Vertragsabschluss, Nutzen und Kommunikation , Governance und Qualität initiiert werden könnten.

Und dann, am siebten Tag, begann die eigentliche Arbeit….

Heh. Ich versuche zu entscheiden, ob ich das positiv bewerten soll. Ich mag es wirklich (sehr gut geschrieben, Doug!), Aber ich bin mir nicht sicher, ob es die Frage des OP direkt beantwortet. Es beschreibt gut den politischen Prozess der Erstellung einer Projektcharta, aber ich habe verstanden, dass sich die Frage des OP eher auf ein bestimmtes Artefakt bezieht. --Wenn nichts anderes, müssen Sie dies irgendwo bloggen. Es ist toll!