Wie können wir Terminrisiken managen, die durch Software von Drittanbietern in ein Projekt eingebracht werden?

Ich arbeite in der Webentwicklung und sehe mich einer häufigen Situation gegenüber, in der Kunden Software von Drittanbietern als Ausgangspunkt für das Projekt verwenden möchten. Das kann ein CMS, eine E-Commerce-Site oder etwas anderes sein. Motivation ist normalerweise budgetgetrieben; Dem Kunden scheint es, dass eine Website, die auf einem handelsüblichen Produkt aufgebaut ist, die Kosten senken wird. Es ist nicht immer wahr. Zum Beispiel:

  • Dem Kunden (häufig eine technisch nicht versierte Person) wurde gesagt, dass es supereinfach ist, eine 3-seitige Website mit einem bekannten CMS zu erstellen. Allerdings weiß niemand, was es braucht, um eine 100-seitige Website mit einer Blog-Funktion und 3 Stufen einer kostenpflichtigen Mitgliedschaft zu erstellen.
  • Das Team kennt das CMS vor Projektbeginn nicht, sodass das Hinzufügen angeforderter Funktionen zu einer schwierigen Aufgabe wird, und der vorhandene CMS-Code steht einer effektiven Entwicklung oft im Wege.
  • Es kann sich auch herausstellen, dass es keine anständige Dokumentation gibt. Das Team würde ähnliche Funktionen ohne dieses CMS schneller erstellen , aber der Kunde besteht immer noch darauf, es zu verwenden.
  • Das Hinzufügen eines benutzerdefinierten Designs zu einer CMS-basierten Website kann für HTML-Entwickler Probleme bereiten, da die Entwicklung von nicht trivialem Code erforderlich ist (z. B. ein obskures Menüsystem).
  • Es kann sich herausstellen, dass das CMS nicht mit dem Hosting kompatibel ist, das normalerweise für die Bereitstellung verwendet wurde, das CMS interne Fehler aufweist, die eine Skalierbarkeit in der Produktion verhindern, oder dass die Lösung einen enormen Hardwareaufbau erfordert, um unter Last ordnungsgemäß zu funktionieren.

Das führt zu Fragen, die ich stellen möchte:

  • Wie können wir einen Kunden davon überzeugen, dass seine Lösung kein benutzerdefiniertes CMS erfordern sollte oder dass es länger dauern kann , eine benutzerdefinierte Lösung mit bereits vorhandenem Code zu entwickeln? Kunden haben normalerweise Argumente wie „Die größten Websites im Internet verwenden dieses CMS“, aber wir wissen nicht wirklich, wie viel Mühe außer diesen größten Websites darauf verwendet wurde, das CMS ordnungsgemäß auszuführen.
  • Wie können wir (oder bereits vorhandenen) Code von Drittanbietern in unsere anfänglichen Schätzungs- und Risikomanagementberechnungen einbeziehen? Alle Zahlen und Techniken sind willkommen.
Willkommen bei PMSE! Ich habe Ihre Frage grammatikalisch bearbeitet und die Umfragefrage am Ende entfernt. Während Ihr Beitrag Gefahr läuft, mit einer webbasierten Engineering-Frage verwechselt zu werden, ist dies meines Erachtens ein häufiges Problem bei komplexen Projekten aller Art.
Vielen Dank für Korrekturen. Tatsächlich ist die Frage nicht-technisch; Ich suche nach einer allgemeinen Lösung, um das Schätzungsrisiko beim Umgang mit Blackboxes zu mindern. Viel zu oft fügt Code von Drittanbietern ein zusätzliches 'x' in die Gleichung ein und es gibt keine Möglichkeit, es zu lösen. (Und danke für die englischen Korrekturen - ich muss es verbessern.)

Antworten (3)

TL;DR

Sie stellen nicht wirklich eine Frage des Risikomanagements. Im Kern geht es um die Frage, wie man Projekte schätzt, bei denen man keine Ausgangswerte hat. Eine gängige Lösung besteht darin, ein Pilotprojekt zu verwenden, um Planungswerte als Eingaben für ein umfassendes Projekt zu generieren.

Fähigkeit zu schätzen

Die Fähigkeit Ihres Projekts, genau (oder überhaupt) zu schätzen, hängt stark von der Erfahrung des Teams mit einem bestimmten Wissensbereich ab. Wenn Sie keine Erfahrung mit einer bestimmten Technologie oder einem bestimmten Projekt haben, dann ist Ihr Projektplan eine Black Box; Es gibt keine Möglichkeit, es zu schätzen, außer Vermutungen.

Selbst wenn man ein gewisses Wissen voraussetzt, sind alle Projekte mit Unsicherheit behaftet . Im Allgemeinen erstellen Sie einen vorläufigen Zeitplan auf der Grundlage einiger Planungswerte, die häufig um einen Fudge-Faktor angepasst werden, der die Unsicherheit des Teams in Bezug auf das Projekt darstellt. Beispielsweise könnten unerfahrene Teams ihre anfänglichen Produktivitätswerte (z. B. Geschwindigkeit) mit 0,6 multiplizieren oder ihren Zeitplan auffüllen, indem sie die Zeitschätzungen mit 1,4 multiplizieren.

Der tatsächliche Wert des Fudge-Faktors ist weniger wichtig als das klare Wissen, dass es sich um eine Anpassung an die Planwerte handelt. Denken Sie daran: Ein Kostenvoranschlag ist eine fundierte Meinung , keine eiserne Garantie.

Pilotprojekte

Wenn Ihr Projekt Fähigkeiten umfasst, die außerhalb des aktuellen Fachgebiets des Teams liegen, oder wenn einige Aufgaben ausgeführt werden müssen, um den Zeitplan für ein größeres Projekt zu kalibrieren, benötigen Sie ein Pilotprojekt .

Anstatt beispielsweise zu versuchen, eine 100-seitige Website mit einer Toolkette zu schätzen, mit der niemand Erfahrung hat, könnten Sie ein Pilotprojekt für eine 5-seitige Website planen. Die wichtigen Ergebnisse eines Pilotprojekts wie diesem sind eigentlich nicht die Webseiten; Die tatsächlichen Ergebnisse sind Erfahrung mit der vorgeschlagenen Lösung und bessere Eingabewerte für das größere Projekt.

Sie könnten beispielsweise Ihre 5-seitige Studie in zwei Wochen erstellen, aber feststellen, dass sich die Lösung nicht so skalieren lässt, wie Sie es benötigen. Oder Sie stellen möglicherweise fest, dass die Ersteinrichtung eine Woche dauert und Entwickler danach im Durchschnitt eine Seite pro Tag erstellen können.

Unabhängig von den Ergebnissen verwenden Sie die Daten aus dem Pilotprojekt zusammen mit einem neuen Satz besser informierter Fudge-Faktoren, um den Zeitplan oder die Schätzung für das größere Projekt zu erstellen. Dies kann linear sein oder auch nicht: Ein 100-seitiges Webprojekt ist nicht unbedingt 20-mal so komplex wie ein 5-seitiges Projekt. Allerdings sollte Ihr Unsicherheitskegel nach einer Pilotstudie kleiner sein, und Ihre Schätzungen werden viel wahrscheinlicher innerhalb der Grenzen der akzeptablen Varianz liegen.

Frage Nr. 1: Dies ist ein Business Case. Um einen Kunden von irgendetwas zu überzeugen, müssen Sie ein Argument aufbauen. Entwickeln Sie einen Fall, der mehrere Alternativen aufweist, aus denen der Kunde wählen kann, die Vorteile/Kosten/Risiken jeder Alternative und Ihre Empfehlung. Ihre Empfehlung muss durch Branchenstandards und Fakten gestützt und untermauert werden, die Sie in Ihrer Recherche finden, und nicht nur Ihre Meinung, die wahrscheinlich durch Ihr Streben nach Gewinn voreingenommen ist. Ihre gesamte Präsentation muss von der Beziehung getragen werden, die Sie zu Ihrem Kunden aufgebaut haben. Sie wären nicht nur ein Verkäufer, der Ihre Waren anbietet, sondern ein vertrauenswürdiger Berater.

Frage Nr. 2: Dies ist eine Frage zum Risikomanagement. Und Sie würden normale Risikomanagementtechniken anwenden. Es gibt nur wenige Projekte da draußen, die nicht von etwas Externem abhängig sind, das sich nachteilig oder günstig auf Ihren Zeitplan und Ihr Budget auswirken könnte. Das ist also normal; Willkommen bei Projektmanagement 101.

Recherchieren Sie, was Sie über die externe Abhängigkeit wissen können, z. B. Ruf auf dem Markt, Vorgeschichte von Verspätung oder Pünktlichkeit, Referenzen usw. Was Sie nicht erfahren können, müssen Sie eine angemessene Annahme (Risikoquelle) formulieren. Sie laden Ihren Zeitplan mit den externen Meilensteinen, die auf dieser Annahme basieren, damit Sie klar kommunizieren können, wie sich Ihre Leistung auswirken würde, wenn diese Annahmen keine Früchte tragen. Sie können Terminreserven laden, um Verspätung auszugleichen, und vor allem kommunizieren Sie Ihrem Kunden klar, wo Sie Abhängigkeiten haben, welche Risiken Sie und Ihr Kunde eingehen müssen und was Sie aktuell beobachten.

Du kannst nur kontrollieren, was du kontrollieren kannst. Die meisten sehr zufälligen Variablen, die unsere Leistung sowohl günstig als auch ungünstig beeinflussen, liegen weit außerhalb unserer Kontrolle, was für alle Projektmanagementunternehmen des Geschäftstyps A sehr kontraintuitiv ist, aber so ist das Leben. Alles, was Sie tun können, ist, auf sie zu achten, für sie zu planen (Risikomanagement), Ihre Beobachtungen rechtzeitig mitzuteilen und die Tatsache zu akzeptieren, dass dies alles ganz normal ist.

Um Ihre zweite Frage zu beantworten: Sie würden Techniken des Risikomanagements anwenden. Es gibt viel Material im Internet über den gesamten Prozess. Im Risk Register User Guide finden Sie ein gut durchgearbeitetes Beispiel für das Risikomanagement in einem Softwareprojekt .