Ideale Anforderungen kommen zurück

In früheren Teilen

Im ersten Teil habe ich eine Reihe von Artikeln über die Arbeit des Analysten im Vorprojekt angekündigt. Es wurden die Probleme, Lösungen und Prinzipien aufgelistet, an die Sie sich beim Starten eines IT-Projekts erinnern müssen.

Im zweiten Teil habe ich über die häufigen Probleme des Vorprojekts gesprochen.

Im letzten Beitrag haben wir den ersten Teil der Grundprinzipien besprochen:

• Das Design von IT-Systemen und die Klassifizierung von IT-Produkten.
• V-Modellebenen und Systemlebenszyklus.
• Ein Blick auf das System als finanziellen Vermögenswert.

In diesem Hinweis werden wir mit einer Beschreibung der Vorgehensweise enden, um weiter zu diskutieren, was zu tun ist, wenn es nicht richtig funktioniert.

Was Sie aus dieser Notiz lernen werden:

• Auf dem Kegel der Unsicherheit und Entwurfsphasen.
• Wie die Bewertung funktioniert.
• Über den vollen Umfang der Aufgaben der Vorprojektphase und die gleichzeitig realisierten Werte.
• Informationen dazu, wie Sie genügend Ressourcen für ein Vorprojekt erhalten.

Wenn Sie nicht auf die nächsten Teile des Zyklus warten möchten, können Sie sich das Video meines Berichts ansehen , auf dessen Grundlage diese Artikelserie geschrieben wird.

Systemlebenszyklus und Kegel der Unsicherheit

Der Kegel der Unsicherheit ist eines der zentralen Konzepte für Design und modernes Projektmanagement. Das Wesentliche des Konzepts: Je weniger Informationen wir haben, desto größer ist die Unsicherheit, die sich in Form einer Streuung der Projektbedingungen und -kosten ausdrücken lässt.



Jede Phase des Aufbaus eines Systems beseitigt einen Teil der Unsicherheit. Wenn Sie typische Phasen eines Projekts durchlaufen, sinkt die Unsicherheit exponentiell:

• Wenn wir eine Idee haben, die in einem halbseitigen Brief ausgedrückt wird, kann die Streuung von Kosten und Rendite mehrere Größenordnungen erreichen.

• Wenn es Geschäftsanforderungen gibt, während der Geschäftsplan oder das Geschäftsmodell entwickelt wird, reduzieren wir die Streuung der Kosten / Rendite auf Bestellung.

• Um die Verbreitung weiter zu verringern, müssen Sie wichtige Entscheidungen über das Erscheinungsbild und das Design des Systems treffen. Diese Studie reduziert die Ausbreitung auf die halbe Ordnung. Trotz der Tatsache, dass die Streuung immer noch groß ist, gibt eine Analyse des Verhältnisses zwischen Rendite und Kosten die Hauptentscheidung - ob wir ein System aufbauen oder nach etwas rentablerem suchen.

• Durch die Angabe der Bedingungen, unter denen das System erstellt wird (wer wird es in welchem ​​Zeitraum ausführen), können wir die Kostenverteilung auf Werte reduzieren, an denen mithilfe von Projektmanagementmethoden gearbeitet werden kann, Reserven gebildet und Risiken gehandhabt werden. Die angegebenen Bedingungen sind in der Leistungsbeschreibung vermerkt.

• Nur das technische Design liefert eine nahezu genaue Schätzung mit einem für das Unternehmen akzeptablen Fehler.

Was folgt daraus:

• Unter dem Gesichtspunkt der Ressourcenallokation müssen wir Zeit haben, das Projekt zu kürzen, bevor wir einen erheblichen Teil der Kosten aufgewendet haben, wenn es nicht mehr rentabel ist. Die Phasen vom Auftrag bis zum technischen Entwurf sollten einen kleinen Bruchteil der Gesamtkosten des Systems ausmachen.

• Sie müssen auch verstehen, dass Sie keine Idee haben und die Kosten sofort festlegen können. Wenn Ihnen gesagt wird, dass es hier 20 Millionen gibt, und das ist sicher, wenn Sie nur eine kurze Beschreibung haben - glauben Sie es nicht, es ist nicht so.

• Geschäftsanforderungen und konzeptionelle Entwicklung müssen durchgeführt werden, da sie Unsicherheiten beseitigen. Dies kann jedoch möglicherweise nicht abgewehrt werden, wenn das Projekt nicht gestartet wird. Infolgedessen sollten die Phasen so billig wie möglich sein, aber die Unsicherheit auf qualitativ hochwertige Weise verringern.

Wie funktioniert die Evaluierung?

Es gibt ein weit verbreitetes Missverständnis, das den normalen Start der Arbeit vor dem Projekt verhindert: Wenn wir nicht schnell eine genaue Bewertung abgeben können, sollten wir uns überhaupt nicht mit den Anforderungen befassen. Das ist nicht wahr. Die Summe der ungenauen Schätzungen ist eine Tatsache aus der Wahrscheinlichkeitstheorie.



In diesem Fall sollte die Vorentwurfsstudie eine Aufteilung des Systems und des Arbeitsplans in mehrere Dutzend vergleichbare Teile enthalten, und die Bewertung für jedes Teil sollte analog oder mit einer genaueren Methode erfolgen. Die Summe der Bewertungen hat einen geringeren Spread als jede einzelne Bewertung.
Wenn die Qualität der konzeptionellen Studie es uns nicht ermöglicht, das System in Teile zu unterteilen, die für die Bewertung akzeptabel sind, verringern wir nicht die Streuung der Bewertung, und es macht keinen Sinn, sich mit einer solchen Studie zu verbinden.

Die Phasen des Projekts sind aus Sicht des Bewertungsmodus wie folgt:

• Wenn eine Idee in einem halbseitigen Brief zum Ausdruck kommt, können wir sie analog bewerten.

• Wenn wir die Geschäftsanforderungen, den Geschäftsplan oder das Geschäftsmodell ausgearbeitet haben, können wir die Schlüsselparameter des Systems hervorheben und eine analoge Bewertung unter Verwendung eines großen Faktors durchführen.

• Das Konzept gliedert sich in mehrere Dutzend Teile und Werke, mit denen Sie die analogen Schätzungen zusammenfassen und den wichtigsten Risikomanagementplan berechnen können.

• Die Leistungsbeschreibung ersetzt die Bewertung von Teilen des Systems in Analogie zu den Verpflichtungen der Lieferanten nach Art der Arbeit. Schätzungen von analog hergestellten Teilen werden in Expertenschätzungen umgewandelt. Die Fehlerrisiken bei der Bewertung werden an die Lieferanten weitergegeben.

• Das technische Design ermöglicht die Aufteilung des Systems in Hunderte und Tausende von Teilen, von denen jedes fachmännisch oder mithilfe von Statistiken zur Umsetzung früherer Projekte bewertet wird.

Wenn die oben beschriebene Essenz nicht in der Vorentwurfsarbeit enthalten ist, ist es besser, dies nicht zu tun. Um eine echte Verringerung der Unsicherheit zu erreichen, muss nicht nur die Dicke des Dokumentationsbündels für das System erhöht, sondern auch sichergestellt werden, dass dort messbare und realisierbare Anforderungen und Lösungen festgelegt werden.

Eine weitere verbreitete Idee lautet: „Geschäftsanforderungen sollten nicht messbar sein.“ Denken Sie daran - das ist eine Lüge!

Was Sie im Vorprojekt erreichen müssen

In den vorhergehenden Teilen wurde dies in Bezug auf Probleme erwähnt. Wiederholen Sie nun kurz, welche Aufgaben in einem Vorprojekt festgelegt und ausgeführt werden sollen:

1. Verstehen Sie die Zeit und die Kosten, um Kosten zu planen und eine Go / Not-Go-Entscheidung zu treffen. Es ist ratsam, den Effekt vorherzusagen und zurückzukehren, um diese Entscheidung zu beschleunigen.
2. So verkaufen Sie das System:
   
   
   • Zeigen Sie dem Kunden ein Verständnis für seine Ziele.
   • Zeigen Sie den Benutzern die Lösung für ihre Probleme.
   • Schließen Sie die Ausschreibung für das Budget erfolgreich ab (es ist immer da).
3. Um eine Grundlage für die Annahme zu schaffen (ein Vertrag über das Volumen und die Qualität des Ergebnisses ist eine technische Aufgabe), vergessen Sie nicht, die Validierung des resultierenden Systems unter dem Gesichtspunkt der praktischen Rechtfertigung der Erwartungen aller Parteien in den Plan aufzunehmen.
4. Entscheiden Sie sich für die Ressourcen: Typen, Phasen, Zeitpläne, Arbeitsvolumen und Ressourcenquellen, um die Schätzungen der ausübenden Künstler zu bestätigen und die Kosten des Systems festzulegen.

Wenn solche Aufgaben nicht explizit festgelegt sind und ihre Lösung nicht geplant ist, ist es besser, überhaupt keine Zeit zu verschwenden - dieses Projekt kann nur zufällig erfolgreich sein.

Warum es möglicherweise nicht funktioniert (oder sogar nicht funktionieren kann)

Aufgrund aller vorherigen Überlegungen haben wir drei widersprüchliche Bedingungen:

1. Die Predesign-Analyse muss schnell durchgeführt werden.
2. Die Predesign-Analyse sollte kostengünstig durchgeführt werden.
3. Die Pre-Design-Analyse muss qualitativ erfolgen.

Diejenigen, die mit der Design-Dreiecksregel vertraut sind, wissen, dass dies nicht der Fall ist.

Es gibt einige zusätzliche Schwierigkeiten:

1. Die Analyse vor dem Projekt zeigt möglicherweise eine geringe Rendite für die vorgeschlagene Lösung, was für den Kunden und den Sponsor nicht interessant ist.
2. Eine Analyse vor dem Projekt kann das Projektvolumen oder die Gesamtbetriebskosten im Vergleich zu den ursprünglichen Annahmen erhöhen, was für den Kunden und den Sponsor wiederum uninteressant wird.
3. Eine Analyse vor dem Projekt kann das Projektvolumen in Bezug auf anfängliche Annahmen reduzieren, und dies ist für den externen Auftragnehmer oft nicht interessant.

Im Zusammenhang mit all diesen Schwierigkeiten möchte ich, dass Sie und ich eines verstehen: Die Probleme des Vorprojekts sind unlösbar, wenn wir nicht auf der Seite des Sponsors stehen und das IT-Projekt nicht als finanziellen Vermögenswert betrachten.

In den vorletzten Kommentaren zum Artikel wurde die Meinung geäußert: „Das Vorprojekt muss so früh wie möglich eröffnet werden, es sollte jedoch berücksichtigt werden, dass der Umfang des Vorprojekts durch seine Wirksamkeit begrenzt ist. Ein solches Vorprojekt wird als effektiv angesehen, wonach das Projekt gestartet wird. Dies ist der Hauptindikator für die Wirksamkeit des Vorprojekts. “ (c) WizardryIB

Dies ist eine ziemlich verbreitete Sichtweise unter Projektmanagern, denn wenn Ihnen etwas anvertraut wird, müssen Sie sich umbringen, ein Team bis zum letzten Tropfen herausdrücken, Ihre Arme vor dem Brechen den Lieferanten zuwenden, den Kunden vergewaltigen, aber das Ziel erreichen.

Wenn der Projektmanager hingegen sein eigenes Projekt abschließt, reduziert er seinen eigenen Arbeitsplatz.

Der richtige Ansatz besteht darin, einen schlechten Vermögenswert so schnell wie möglich zu beseitigen. Die Aufgabe des Analysten und Managers im Vorprojekt besteht darin, dies zu tun.

So erhalten Sie ein Budget für ein Vorprojekt

Um den Weg zu einer konstruktiven und konsequenten Beseitigung von Unsicherheiten in Bezug auf ein IT-Projekt zu beschreiten, muss mit dem Kunden und dem Sponsor die allgemeine Position bezüglich der Einstellung zum Projekt als finanziellem Vermögenswert geklärt werden.

Das Bild zeigt das normale Verhältnis von Unsicherheit, Investition und Rendite.



Solange die Unsicherheit groß ist, müssen wir wenig investieren und sie reduzieren.

Sobald die Unsicherheit mit dem Verhältnis von Investitionen und Nutzen ein akzeptables Niveau erreicht hat, können Sie den Großteil der Ressourcen investieren, um eine Rendite zu erzielen. Am Ende jeder Phase muss eine ehrliche Entscheidung getroffen werden: das Projekt bearbeiten oder schließen.

Zu diesem Zweck sollte am Ende jeder Phase eine Bewertung des Verhältnisses von Investitionen und Rendite auf dem für die aktuelle Phase natürlichen Genauigkeitsniveau erfolgen.

Der Kunde muss den aktuellen Unsicherheitsgrad sowie die derzeit angemessene Einschätzung des Nutzens und der Kosten nachweisen. Wenn der Nutzen die Kosten übersteigt, ist es sinnvoll, die weitere Beseitigung der Unsicherheit zu erörtern.

Die Rhetorik könnte folgende sein: "Wir sehen eine Prognose der Vorteile, die die Kosten des Systems erheblich übersteigen. Lassen Sie uns einen kleinen Teil des prognostizierten Werts oder der Vorteile ausgeben, um die Schätzungen zu verfeinern und über den Start des Systems zu entscheiden."

Meine (sehr durchschnittlichen) Empfehlungen zum Verhältnis der Kosten von Teilen des Vorprojekts:

• Alles, was vor dem Bau passiert, sollte nicht mehr als 10-30% des Projekts kosten.

• Ein Vorprojekt sollte eine Größenordnung weniger kosten - dies sind 1-3% der projizierten Kosten des Systems.

• In der Anfangsphase, solange keine Geschäftsanforderungen vorliegen, gibt es möglicherweise keinen vorhergesagten Wert und muss von der berechneten Rendite abgewehrt werden. Sie können für die Lebensdauer des Systems 0,1 bis 0,2% des Budgets für die Erstellung von Geschäftsanforderungen verwenden (unter Berücksichtigung, dass es nicht startet) jedes vorgeschlagene Projekt).

Zum Beispiel, wenn wir ein System verkaufen, das (analog) ~ 100 Millionen kostet. Dies ist sinnvoll, wenn die Betriebsrendite angesichts der geringen Genauigkeit aller Schätzungen mindestens 300 bis 500 Millionen beträgt.

In diesem Fall können die folgenden Kosten als normal angesehen werden:

• Geschäftsanforderungen - 0,5-1 Millionen Rubel.

• Das Konzept ist 1-3 Millionen Rubel.

• Technisches Projekt - 10-30 Millionen Rubel.

Abweichungen in jede Richtung sind hier möglich. Das allgemeine Prinzip lautet jedoch: Die investierten Ressourcen sollten in Abhängigkeit von der aktuellen Unsicherheit mit dem prognostizierten Gewinn und der Wahrscheinlichkeit ihres Eingangs korreliert werden.

Kurze Zusammenfassung

Hier schließen wir die Überprüfung des richtigen Vorprojekts ab und wiederholen das Wichtigste:

1. Das Projekt muss als riskanter finanzieller Vermögenswert betrachtet werden.
2. Das Ausmaß der Unsicherheit sollte allen bekannt sein und zwischen allen interessierten Parteien diskutiert werden.
3. Die Analysekosten sollten sich auf den prognostizierten Nutzen und die Wahrscheinlichkeit des Eingangs beziehen.
4. Im Laufe der Entwicklung ist es notwendig, die Qualität der Anforderungen zu erreichen, die ausreicht, um die Kosten und Bedingungen mit der Genauigkeit zu bewerten, die der aktuellen Phase innewohnt.
5. Insbesondere sollten Geschäftsanforderungen bereits messbar sein.
6. Es ist notwendig, sich an die vollständige Liste der Aufgaben der Vorprojektphase zu erinnern, deren Auslassung die Wahrscheinlichkeit eines Projektversagens um Größenordnungen erhöht.

Das Leben zeigt, dass es aus verschiedenen Gründen nicht immer möglich ist, diese Prinzipien zu beachten. In einigen Fällen kann ein vor dem Start beschädigtes Projekt gespeichert oder zumindest geringfügig verbessert werden. Wir werden in den nächsten Teilen der Serie darüber sprechen.