Ideale Voraussetzungen kommen wieder

Published on June 25, 2018

Ideale Voraussetzungen kommen wieder

    In früheren Teilen


    Im ersten Teil habe ich eine Reihe von Artikeln über die Arbeit des Analytikers im Vorprojekt angekündigt. Es wurden Probleme, Lösungen und Prinzipien aufgelistet, an die beim Starten eines IT-Projekts gedacht werden muss.

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

    In der letzten Anmerkung haben wir den ersten Teil der Grundprinzipien besprochen:

    • IT-Systemdesign und Klassifizierung von IT-Produkten.
    • V-Modellstufen und Systemlebenszyklus.
    • Ein Blick auf das System als finanzieller Vermögenswert.

    In diesem Artikel werden wir mit der Beschreibung der Vorgehensweise abschließen, um weiter zu diskutieren, was zu tun ist, wenn es nicht richtig funktioniert.

    Was Sie aus diesem Beitrag lernen:

    • Auf dem Kegel der Ungewissheit und der Entwurfsphasen.
    • Wie funktioniert die Bewertung?
    • Über die vollständige Erfüllung der Aufgaben der Vorprojektphase und die gleichzeitig realisierten Werte.
    • So erhalten Sie genügend Ressourcen für ein Vorprojekt.

    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 verfasst wurde.

    Systemlebenszyklus und Unsicherheitskonus


    Der Kegel der Unsicherheit ist eines der zentralen Konzepte für Design und modernes Projektmanagement. Die Essenz des Konzepts: Je weniger Informationen wir haben, desto höher ist die Unsicherheit, die sich in Form einer Streuung der Begriffe und Kosten des Projekts ausdrücken lässt.



    In jeder Phase des Aufbaus eines Systems wird ein Teil der Unsicherheit beseitigt. Beim Durchlaufen der typischen Projektphasen nimmt die Unsicherheit exponentiell ab:

    • Wenn wir eine Idee auf einer halben Seite zusammenfassen, können die Kosten- und Wirkungsunterschiede mehrere Größenordnungen erreichen.

    • Wenn sich Geschäftsanforderungen ergeben haben und der Geschäftsplan oder das Geschäftsmodell ausgearbeitet wurde, reduzieren wir die Kosten-Nutzen-Spanne auf Bestellung.

    • Um die Streuung weiter zu verringern, müssen Sie wichtige Entscheidungen über das Erscheinungsbild und das Design des Systems treffen. Eine solche Studie reduziert den Spread auf die Hälfte. Trotz der Tatsache, dass der Spread immer noch groß ist, entscheidet die Analyse des Verhältnisses von Rendite und Kosten vor allem, ob wir das System aufbauen oder nach etwas Rentablerem Ausschau halten.

    • Durch die Angabe der Bedingungen, unter denen das System erstellt wird (wer es zu welchem ​​Zeitpunkt ausführt), können wir die Kostenverteilung auf Werte reduzieren, mit denen Sie mit Projektmanagementmethoden, Lagerbeständen und Verarbeitungsrisiken arbeiten können. Die angegebenen Bedingungen sind in der technischen Aufgabe festgehalten.

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

    Was folgt daraus:

    • Aus der Sicht der Ressourcenallokation müssen wir Zeit haben, um das Projekt aufzurollen, bevor wir einen erheblichen Teil der Kosten aufwenden, wenn es nicht mehr rentabel ist. Phasen von der kurzen bis zur technischen Planung sollten einen kleinen Bruchteil der Gesamtkosten des Systems ausmachen.

    • Sie müssen auch verstehen, dass Sie nicht auf die Idee kommen und sofort die Kosten zahlen 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, dann passiert das nicht so.

    • Geschäftsanforderungen und konzeptionelle Arbeit sollten erledigt werden, da sie Unsicherheiten beseitigen. Sie können sich jedoch nicht wehren, wenn das Projekt nicht gestartet wird. Infolgedessen sollten die Phasen so billig wie möglich sein, aber qualitativ Unsicherheit beseitigen.

    Wie funktioniert die Bewertung?


    Es gibt ein weit verbreitetes Missverständnis, das den normalen Start der Vorprojektarbeit behindert: Wenn wir nicht schnell eine genaue Einschätzung abgeben können, sollten wir uns überhaupt nicht mit den Anforderungen befassen. Das ist falsch. Die Summe der ungenauen Schätzungen ist genauer - eine Tatsache aus der Wahrscheinlichkeitstheorie.



    In diesem Fall sollte die Vorprojektstudie eine Aufteilung des Systems und des Arbeitsplans in mehrere Dutzend vergleichbarer Teile enthalten, und die Bewertung für jedes Teil sollte analog oder nach einer genaueren Methode erfolgen. Die Summe der Schätzungen weist eine geringere Abweichung als jede einzelne Schätzung auf.
    Wenn die Qualität der konzeptuellen Studie keine Aufteilung des Systems in Teile zulässt, die für die Bewertung akzeptabel sind, reduzieren wir die Streuung der Bewertung nicht und es macht keinen Sinn, mit einer solchen Entwicklung in Verbindung zu treten.

    Die Phasen des Projekts in Bezug auf den Bewertungsmodus sind wie folgt:

    • Wenn es eine Idee gibt, die auf einer halben Seite zusammengefasst ist, können wir sie analog bewerten.

    • Wenn wir Geschäftsanforderungen, einen Geschäftsplan oder ein Geschäftsmodell ausgearbeitet haben, können wir die wichtigsten Parameter des Systems herausgreifen und eine analoge Bewertung unter Verwendung eines großen Faktors vornehmen.
    • Das Konzept sieht die Aufteilung in mehrere Dutzend Teile und Werke vor, mit denen die analog vorgenommenen Schätzungen zusammengefasst und der zentrale Risikomanagementplan berechnet werden können.

    • Die Leistungsbeschreibung ersetzt die Bewertung von Systemteilen in Analogie zu den Pflichten der Lieferanten nach Art der Arbeiten. Analoge Bewertungen von Bauteilen werden in Gutachten umgewandelt. Die Risiken von Beurteilungsfehlern werden an die Lieferanten weitergegeben.

    • Das technische Design sieht die Aufteilung des Systems in Hunderte und Tausende von Teilen vor, von denen jedes fachmännisch oder unter Einbeziehung von Statistiken über die Durchführung früherer Projekte bewertet wird.

    Wenn das oben beschriebene Wesentliche nicht in den Arbeiten vor dem Projekt enthalten ist, ist es am besten, es nicht zu tun. Um eine echte Verringerung der Unsicherheit zu erreichen, muss nicht nur die Dicke des Dokumentationsstapels auf dem System erhöht werden, sondern auch sichergestellt werden, dass messbare und umsetzbare Anforderungen und Lösungen vorhanden sind.

    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 vorherigen Abschnitten wurde dies im Hinblick auf Probleme diskutiert. Jetzt werde ich kurz wiederholen, welche Aufgaben in einem Vorprojekt festgelegt und ausgeführt werden sollen:

    1. Verstehen Sie den Zeit- und Kostenaufwand, um die Kosten zu planen und eine Entscheidung zu treffen. Es ist ratsam, die Auswirkungen und Auswirkungen vorherzusagen, um diese Entscheidung zu beschleunigen.
    2. Vervollständige 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 Auktion für das Budget erfolgreich ab (es ist immer da).
    3. Schaffen Sie eine Akzeptanzgrundlage (ein Vertrag für das Volumen und die Qualität des Ergebnisses - eine technische Aufgabe), vergessen Sie nicht, die Validierung des resultierenden Systems im Hinblick auf die praktische Rechtfertigung der Erwartungen aller Parteien in den Plan aufzunehmen.
    4. Bestimmen Sie die Ressourcen: Arten, Stufen, Begriffe, 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 werden und ihre Lösung nicht geplant ist, ist es besser, überhaupt keine Zeit zu verschwenden - dieses Projekt kann nur durch Zufall erfolgreich werden.

    Warum kann es nicht (oder nicht) funktionieren


    Aus all den vorhergehenden Argumenten ergeben sich drei widersprüchliche Bedingungen:

    1. Die Analyse vor dem Projekt sollte schnell erfolgen.
    2. Die Analyse vor dem Projekt sollte kostengünstig erfolgen.
    3. Die Analyse vor dem Projekt sollte qualitativ erfolgen.

    Diejenigen, die mit der Regel des Projektdreiecks vertraut sind, verstehen, dass dies nicht geschieht.

    Es gibt ein paar zusätzliche Schwierigkeiten:

    1. Die Analyse vor dem Projekt kann zu geringen Erträgen für die vorgeschlagene Lösung führen, was für den Kunden und den Sponsor uninteressant wird.
    2. Eine Analyse vor dem Projekt kann den Umfang des Projekts oder die Gesamtbetriebskosten in Bezug auf anfängliche Annahmen erhöhen, und dies wird wiederum für den Kunden und den Sponsor uninteressant.
    3. Die Analyse vor dem Projekt kann den Umfang eines Projekts in Bezug auf die ursprünglichen Annahmen verringern und ist für einen externen Auftragnehmer häufig nicht interessant.

    Im Zusammenhang mit all diesen Schwierigkeiten möchten ich, dass Sie und ich eines verstehen: Die Probleme eines 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 Kommentaren zum vorherigen Artikel wurde die Meinung geäußert: „Das Vorprojekt sollte so bald wie möglich geöffnet werden, es sollte jedoch beachtet 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 wichtigste Schlüsselindikator für die Wirksamkeit eines Vorprojekts. “ (c) WizardryIB

    Dies ist eine unter Projektmanagern weit verbreitete Sichtweise, denn wenn Ihnen etwas anvertraut wird, müssen Sie sich selbst töten, das Team aus dem Weg räumen, Lieferanten auf Brüche ausweisen, den Kunden vergewaltigen, aber das Ziel erreichen.

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

    Der richtige Ansatz ist es, einen schlechten Vermögenswert so früh wie möglich loszuwerden. Die Aufgabe des Analysten und des Managers im Vorprojekt ist es, dies zu tun.

    So erhalten Sie ein Budget für das Vorprojekt


    Um den Weg zu einer konstruktiven und konsequenten Beseitigung von Unsicherheiten rund um das IT-Projekt zu beschreiten, ist es notwendig, mit dem Kunden und dem Sponsor eine gemeinsame Position bezüglich der Einstellung zum Projekt als finanziellem Vermögenswert zu klären.

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



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

    Sobald die Unsicherheit über das Verhältnis von Investitionen und Nutzen ein akzeptables Maß erreicht, können Sie die meisten Ressourcen investieren, um die Rendite zu erzielen. Am Ende jeder Phase müssen Sie eine ehrliche Entscheidung treffen: weiterarbeiten oder das Projekt abschließen.

    Zu diesem Zweck muss am Ende jeder Phase eine Schätzung des Verhältnisses von Investition und Rendite auf dem Genauigkeitsniveau erfolgen, das für die aktuelle Phase selbstverständlich ist.

    Der Kunde muss den aktuellen Unsicherheitsgrad und die aktuelle angemessene Schätzung von Nutzen und Kosten nachweisen. Wenn der Nutzen die Kosten übersteigt, ist es sinnvoll, die weitere Beseitigung der Unsicherheit zu erörtern.

    Die Rhetorik kann folgendermaßen lauten: „Wir sehen eine Gewinnprognose, die die Kosten des Systems erheblich übersteigt. Geben wir einen kleinen Bruchteil der prognostizierten Kosten oder des prognostizierten Nutzens aus, um die Schätzungen zu klären und mit dem Aufbau des Systems zu beginnen.

    Meine (sehr durchschnittlichen) Empfehlungen zum Verhältnis der Kosten für Teile eines Vorprojekts:

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

    • Das Vorprojekt sollte eine Größenordnung weniger kosten - das sind 1-3% der prognostizierten Systemkosten.

    • In der Anfangsphase können und müssen die prognostizierten Kosten möglicherweise nicht von der berechneten Rendite abweichen, solange es keine Geschäftsanforderungen gibt. Sie können 0,1 bis 0,2% für die Lebensdauer des Systems für das Budget für die Erstellung von Geschäftsanforderungen verwenden (unter Berücksichtigung der Tatsache, dass es nicht startet jedes vorgeschlagene Projekt).

    Zum Beispiel, wenn wir ein System verkaufen, das (analog) ~ 100 Millionen kostet. Unter Berücksichtigung der geringen Genauigkeit aller Schätzungen ist es sinnvoll, wenn die Rendite aus dem Betrieb mindestens 300 bis 500 Millionen beträgt.

    In diesem Fall können solche Ausgaben als normal angesehen werden:

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

    • Konzept - 1-3 Millionen Rubel.

    • Technisches Projekt - 10-30 Millionen Rubel.

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

    Kurze Zusammenfassung


    Hier vervollständigen wir die Überprüfung des richtigen Vorprojekts 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 unter allen Beteiligten erörtert werden.
    3. Die Kosten der Analyse sollten sich auf den prognostizierten Gewinn und die Wahrscheinlichkeit seines Eingangs beziehen.
    4. Im Laufe der Entwicklung müssen Qualitätsanforderungen erfüllt werden, die ausreichen, um die Kosten und den Zeitpunkt mit der Genauigkeit abzuschätzen, die der aktuellen Phase eigen ist.
    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 Wegfall 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 einzuhalten. In einigen Fällen kann ein vor dem Start beschädigtes Projekt gespeichert oder zumindest geringfügig verbessert werden. Wir werden in den folgenden Teilen der Serie darüber sprechen.