Nicht-Systeme/Nicht-IT BRD

Sind BRD- und FRD-Dokumente für Nicht-System-/Nicht-IT-Projekte erforderlich? Wir sind an einem Service-Migrationsprojekt beteiligt, bei dem verwaltete Website-Hosting-Services von einem vollständig verwalteten externen Anbieter auf intern umgestellt werden, damit wir diese selbst verwalten können. Da dies ein Übergangsprojekt ist, das keine Entwicklung oder den Aufbau von IT-Systemen oder Infrastruktur erfordert (wir haben bereits die Server zur Unterstützung der Website), kann es mit einem Bau- oder Ingenieurprojekt verglichen werden, bei dem BRD- und FRD-Dokumente dies nicht tun in der Regel bestehen.

Normalerweise basieren die Anforderungen auf Geschäftszielen und dann basieren funktionale und nicht funktionale Anforderungen auf Anforderungen. Wenn es sich um ein Übergangsprojekt handelt, bei dem ein Dienst von Anbieter A (extern) zu Anbieter B (intern) verschoben wird, ist dann wirklich eine BRD erforderlich?

Das primäre Geschäftsziel besteht darin, die Managed Services von extern auf intern umzustellen. Wenn wir uns die eigentlichen Aufgaben und Werkstücke ansehen, die am Projekt beteiligt sind, um das Geschäftsziel erfolgreich zu erreichen, sind einige davon auf sehr hohem Niveau:

  • Dokumentation: Unterstützungsdokumentation identifizieren und übertragen.
  • HR: Einstellung neuer Mitarbeiter oder Beschäftigung vorhandener Mitarbeiter von Anbietern zur Verwaltung des intern bereitgestellten Hostings.
  • Prozesse: Vom Anbieter beziehen und neue Prozesse einführen, um denselben Managed Service bereitzustellen.

Die primären Einschränkungen oder nicht funktionalen Anforderungen, wenn es sich um ein System-/IT-Projekt handeln würde, wären:

  • Kein Verlust der Servicebereitstellung während des Übergangs.
  • Einhaltung von Unternehmensprozessen und SLAs.

Sind BRD- und FRD-Dokumente erforderlich oder würde eine Reihe von Plänen (Implementierungsplan, Übergangsplan, Kontinuitätsplan, SLA usw.) ausreichen?

Update: Vielen Dank für die bisherigen Antworten und Kommentare. Ich fordere mehr Standpunkte und Kommentare auf, die dazu beitragen können, da solche Projekte nicht ungewöhnlich sind, aber es im Internet kaum Informationen gibt, auf die man sich beziehen kann.

Antworten (3)

Der Zweck dieser Dokumente besteht nicht darin, eine Prozessanforderung zu erfüllen (obwohl Sie möglicherweise von Ihrem Prozess dazu aufgefordert werden), sondern zu klären, was zu tun ist, und alle auf dieselbe Seite zu bringen.

Die Dokumente, die Sie am Ende Ihrer Frage erwähnt haben (Implementierungsplan, Übergangsplan, Kontinuitätsplan, SLA usw.), sind nützlich, aber die Dokumente, mit denen Sie "erledigt" erklären können, sind Ihre Anforderungsdokumente. Ich würde Sie ermutigen, dies zu tun, unabhängig davon, ob Ihre Stakeholder darauf bestehen oder nicht.

Danke Scott. Wenn wir uns für eine BRD entscheiden, können Sie einige Beispiele dafür geben, was tatsächliche Geschäftsanforderungen, funktionale Anforderungen und nicht-funktionale Anforderungen sein würden/könnten? Aus diesem Projekt erwarten wir die Entwicklung und/oder den Erwerb von Hunderten von Dokumenten darüber, wie derselbe Webhosting-Service bereitgestellt werden kann. Hätten wir Hunderte von Geschäftsanforderungen, um jedes Dokument zu adressieren?
Wenn beispielsweise das Geschäftsziel darin besteht, verwaltete Website-Hosting-Dienste von extern auf intern umzustellen, und um dies erfolgreich zu tun, dürfen wir keine Ausfallzeiten haben oder den Geschäftsbetrieb beeinträchtigen, in welche Dokumente würden wir die Arbeit einfügen: • Identifizierung und Übertragung von Support-Dokumentation • Einstellung neuer Mitarbeiter oder Beschäftigung vorhandener Mitarbeiter des Anbieters zur Verwaltung des intern bereitgestellten Hostings • Beschaffung vom Anbieter und Einführung neuer Prozesse zur Bereitstellung des gleichen verwalteten Dienstes usw.

Ich schlage vor, dass Sie ohne irgendeine Form von Anforderungsdokument keine klaren Erwartungen haben, daher ist es sehr sinnvoll, sogar ein Dokument auf hoher Ebene zu entwickeln, das sagt, was Sie in diesem Projekt tun werden, und einige Kriterien zu definieren an denen das Projekt gemessen wird - Bedingungen der Zufriedenheit, wenn Sie so wollen. Bei der Art des Projekts, das Sie beschreiben, haben Sie Erwartungen in Bezug auf Leistung, Kosten, Zuverlässigkeit und Funktionalität. Selbst die ausdrückliche Aussage, dass die Leistung, die Kosten und die Zuverlässigkeit gleich oder besser als die des aktuellen ausgelagerten Dienstes sein werden und dass die Funktionalität identisch sein wird, ist ein guter Anfang. Andernfalls stellen Sie möglicherweise fest, dass Ihre technischen Teams Änderungen im Rahmen des Projekts vornehmen, nur weil sie es können und weil es nichts gibt, was sie davon abhalten könnte.

Grundsätzlich brauchen Sie eine gewisse Struktur, um zu definieren, was in dem Projekt drin ist und was nicht, und dann arbeiten Sie entweder daran oder ändern es bewusst und absichtlich. In jedem Fall haben Sie einen Ausgangspunkt, von dem aus Sie das Projekt darauf konzentrieren können, den erwarteten Geschäftswert zu liefern.

Danke Iain. Mir ist noch unklar, in welche konkrete Richtung ich gehen soll. Es gibt einen definierten Projektumfang, der definiert, was innerhalb und außerhalb des Umfangs liegt, und Aufgaben und Aktivitäten werden im PSP basierend auf dem Umfang definiert. Wenn wir eine BRD erstellen, enthält sie einige Anforderungen, die oben aufgeführt sind. Gibt es eine Möglichkeit, alle Dokumente, die wir erstellen müssen, als Geschäftsanforderungen einzubeziehen? Wenn wir einen Kontinuitätsplan, mehrere SLAs, Betriebsverfahren usw. erstellen müssen, um das interne Website-Hosting zu unterstützen, wie könnten diese in funktionale Anforderungen umgewandelt werden, die zur Überprüfung der Anforderungen verwendet werden?
Das Dokument zum Projektumfang kann jedoch ausreichend sein, solange Sie das Risiko angesprochen haben, dass Ihre Sicht auf die Leistungen und die geschäftliche Sicht auf die Leistungen übereinstimmen. Beginnen Sie mit dem Risiko und arbeiten Sie sich dann rückwärts vor, bis Sie sicher sind, dass alle auf derselben Seite sind, was das Verständnis betrifft, und hören Sie dann auf. Tun Sie nicht mehr als Sie müssen. Hängen Sie sich auch nicht an Dokumentnamen auf: Es kommt auf den Inhalt und Wert der Dokumente an, nicht darauf, wie Sie sie nennen. Wenn Ihr Scope-Dokument die Anforderungen erfüllt, dann produzieren Sie nichts anderes, was Sie nicht wirklich brauchen!
Danke Iain. Wo würden wir die tatsächlichen Hunderte von zu liefernden Einzeldokumenten angeben, wie z. B. Support-Dokumentation, SLAs usw.? Diese unterstützen den Übergang selbst, damit wir ihn intern verwalten können. Die Schwierigkeit wird darin bestehen, den Stakeholdern und dem PM mitzuteilen, dass wir nur ein Scope-Dokument und keine tatsächlichen Anforderungen haben? Die Erwartung besteht darin, aus all diesen Dokumenten irgendwie Hunderte von „Ergebnissen“ zu erstellen, damit jedes verifiziert werden kann, um sicherzustellen, dass der Übergang erfolgreich ist und nichts übersehen oder verpasst wurde. Das Projekt ist kritischer Natur.
Es gibt keine richtige oder falsche Antwort darauf, wo Sie die einzelnen Dokumente definieren – aber ein Business Requirement Document kann der richtige Ort sein. Ich zögere, dass Sie am Ende Dutzende oder Hunderte von Dokumenten produzieren, die der Organisation keinen Mehrwert bringen, aber wenn Sie sie alle im Voraus definieren und gegen diese Liste liefern, könnten Sie Dinge liefern, die nie gelesen werden und am Ende verstauben . Lassen Sie mich nur eine Frage stellen - und ich brauche keine Antwort: Definiert die Dokumentation den Erfolg oder definiert ein zuverlässiges, sicheres, robustes und funktionierendes System den Erfolg? Das kannst nur du beantworten!
Danke Iain und ein paar gute Denkanstöße. Obwohl die zu erbringenden Leistungen möglicherweise auf einer höheren Ebene liegen, sind unterstützende Dokumentationen und andere Ressourcen vorhanden, um den Service zu unterstützen und sicherzustellen, dass er zuverlässig, sicher, robust und funktionsfähig ist. Es ist positiv, wenn diese Dokumente selten abgerufen und verwendet werden.

Ich denke, dass jedes Projekt/Feature/Aufgabe, egal wie klein sie sind, geplant werden sollte.

Was ist, wenn eine der Websites, die Sie migrieren möchten, auf einen Drittanbieter angewiesen ist, dessen Sie sich nicht bewusst sind? Wenn Sie Ihre Anforderungen in einem Dokument haben, können Sie es an die zuständigen Personen weiterleiten und deren Genehmigung (Abzeichnung) einholen. Das schützt nicht nur Ihren Rücken, sondern gibt Ihnen möglicherweise auch ein besseres Verständnis für ein Problem.

Woher wissen Sie, wann das Projekt abgeschlossen ist, wenn Sie nirgendwo gesagt haben, was als „abgeschlossen“ gilt?

Dokumente, die Sie erwähnt haben, würde ich als Analysedokument bezeichnen. Das Analysedokument sollte jemandem, der neu ist, genügend Informationen liefern, um die Aufgabe zu übernehmen, falls Sie sich entscheiden, das Unternehmen zu verlassen. Wenn es sich um ein Dokument mit wenigen Seiten handelt, würde ich es einfach ein Analysedokument nennen. Wenn es ein 40-seitiges Dokument wäre, dann würde ich in Betracht ziehen, es in kleinere Dokumente aufzuteilen.

Dank CodeWorks und Ihrem Feedback haben wir einen guten Überblick über das Problem. Es sieht so aus, als wäre eine Kombination aus Analysedokumenten, Geschäftsanforderungen und einigen anderen Dingen der richtige Weg.
Nicht-Systeme/Nicht-IT BRD
AntwortenHierDatenschutz-Bestimmungen1y, 0v