Wo endet „Change Management“ und wo beginnt „Projektscheitern“?

Question

Ich habe kürzlich in einem Mini-Argument mit meinem Chef in Bezug auf "Projektversagen" geraten. Nach drei Jahren ging unser Projekt zur Migration einer Codebasis auf eine neue Plattform (ein Projekt, an dem ich 1,5 Jahre lang war, aber mein Teamleiter war nur ein paar Monate lang an).Er, zusammen mit der Geschäftsleitung meines Unternehmens und des Kunden (ich bin einer dieser schrecklichen Berater, von denen man so viel hört).Mein Auftrag ist ein „Application Outsourcing“), das das Projekt für einen Erfolg erklärt hat.Ich war anderer Meinung und erklärte, dass alte Präsentationen, die ich gefunden hatte, zeigten, dass die Verzögerung bei der Bereitstellung im Vergleich zum ursprünglichen Zeitplan am besten in Monaten gemessen werden könne und möglicherweise in Jahren gemessen werden könne.Ich habe erklärt, was ich über das Scheitern von Projekten weiß und welche Studien und Statistiken hinter den Ausfallraten stehen.Er entgegnete, dass das alles Sache der Wissenschaft sei und dass kein von ihm geleitetes Projekt gescheitert sei, dank der Wunder des Change-/Risikomanagements – was offenbar darauf hinausläuft, Verzögerungen zu erklären und den Zeitplan auf der Grundlage neuer Daten neu zu bewerten.

Vielleicht unterscheidet sich eine solche Beratung von anderen Projekten, aber es scheint, als wäre dies nur ein Scheitern, verpackt in einen hübscheren Namen, um dem Stigma zu entgehen, nicht rechtzeitig, im Rahmen des Budgets oder mit voller Funktionalität geliefert zu haben.Die Tatsache, dass er erklärte, dass mein Unternehmen Arbeitsstunden kostenlos verschenkt habe, um das Projekt innerhalb des ausgeschöpften Budgets abzuschließen, sagt viel aus.

Deshalb frage ich Sie Folgendes:

• Was ist Change Management und wie lässt es sich auf ein Projekt anwenden?
• Wo endet „Change Management“ und wo beginnt „Projektscheitern“?

---

@shog9:
Ich habe nicht nach einem Schuldzuweisungsspiel mit den Beratern gefragt, zumal ich in diesem Fall vertreten die Berater.Ich habe nach Ansichten gesucht, wann ein Projekt als „fehlgeschlagen“ betrachtet werden sollte, unabhängig davon, ob die erforderliche Funktionalität vorhanden ist War endlich umgesetzt.
Ich suche nach dem Unterschied zwischen „Das ist tatsächlich etwas komplexer als wir dachten, und es wird noch eine Woche dauern“, was meiner Meinung nach einigermaßen typisch ist, und „Projektscheitern“ – wie auch immer Sie Scheitern definieren möchten.Gibt es überhaupt einen Unterschied?Stellt diese geringfügige Abweichung vom Zeitplan einen statistischen „Projektfehler“ dar?

Answer 1

Ich denke, dass wir Entwickler die meiste Zeit vergessen, dass es uns allen schließlich ums Geschäft geht.

Unter diesem Gesichtspunkt ist ein Projekt kein Misserfolg, solange der Kunde bereit ist, dafür zu zahlen.Es hängt alles vom Kunden ab. Manche Kunden haben mehr Geduld und verstehen die Risiken der Softwareentwicklung besser, andere zahlen einfach nicht, wenn es zu einer erheblichen Verzögerung kommt.

Wie auch immer, zu deiner Frage.Wenn Sie ein Projekt weiterentwickeln, sind Risiken damit verbunden. Vielleicht planen Sie das Ende des Projekts auf einen bestimmten Termin, aber es wird etwa sechs Monate länger dauern als erwartet.In diesem Fall müssen Sie abwägen, was Sie bereits ausgegeben haben und was Sie gewinnen können, und welche Risiken Sie eingehen.Es gibt tatsächlich eine ganze Wissenschaft namens „Entscheidungsfindung“, die sich damit auf Softwareebene befasst, Ihr Chef hat also überhaupt nicht Unrecht.

Schauen wir uns einige Fragen an: Ist der Kunde bereit, auf das Projekt zu warten?Ist er bereit, bestimmte Mehrkosten zu übernehmen?Auch wenn dies nicht der Fall ist: Lohnt es sich, das Projekt unter Übernahme der zusätzlichen Kosten abzuschließen, anstatt die gesamte bereits geleistete Arbeit wegzuwerfen?Kann das Unternehmen übernehmen, was bereits verloren gegangen ist?

Die eigentliche Antwort auf Ihr Problem liegt hinter diesen Fragen.Man kann hier nicht auf den Punkt bringen und sagen: Wenn das Projekt bis zu diesem Zeitpunkt nicht abgeschlossen ist, ist es ein Misserfolg.Was Ihre spezielle Situation betrifft, wer weiß?Ihr Chef verfügt wahrscheinlich über mehr Informationen als Sie. Ihre Aufgabe besteht also darin, ihm zu sagen, wie das Projekt läuft, wie viel es dauern wird und wie viel es kosten wird (in Stunden/Mann, wenn Sie möchten).

Answer 2

Sofern die Ziele zu Beginn des Projekts nicht klar angegeben waren, gibt es keine klaren Grenzen zwischen "Erfolg" und "Scheitern". Oft hätte ein Projekt ein unterschiedliches Maß an Erfolg/Misserfolg.

Für einige wäre es schon ein Erfolg, einige Konzepte in den Code zu integrieren, während andere den Erfolg vielleicht daran messen, dass sich alle Investitionen amortisieren und Gewinne erwirtschaften.Zwei bekannte Arten von Fehlern sind Terminüberschreitungen und Qualitätsverschlechterungen, aber in der Praxis scheinen die Leute sich nicht sonderlich darum zu kümmern.

Eine einfache Möglichkeit, den Zeitplan zu umgehen, besteht darin, den Managern die Möglichkeit zu geben, Anfragen zu stellen, wann immer sie wollen (Features Creep), und die Programmierer das programmieren zu lassen, was sie für richtig halten (Cowboy-Codierung).Change-Management-Prozess wie z Sprintplanung von Scrum und Planspiel von XP sind einige Beispiele.Dies sind einige der Versuche des Managements und der Entwickler, zuverlässige Produkte pünktlich auszuliefern.Wenn eine der Parteien kein Interesse an Zuverlässigkeit oder Pünktlichkeit hat, wäre ein Änderungsmanagement nicht sinnvoll.

Answer 3

Ich nehme an, wie erfolgreich das Projekt ist, hängt davon ab, wer der Kunde ist.Wenn der Kunde der Geschäftsführer des Unternehmens wäre und er zufrieden wäre, dann war das Projekt erfolgreich, ungeachtet der Misserfolge auf dem Weg dorthin.

Answer 4

Andy Rutledge hat einen ziemlich interessanten Artikel über Erfolg geschrieben.Obwohl der Titel es ist Gespräche vor der Ausschreibung, definiert der Artikel ein erfolgreiches Projekt haben, was für Andy bedeutet:

1. Darf ich oder mein Team unsere beste Arbeit in das Endergebnis einbringen?
2. Ist der Kunde bereit, sich angemessen an dem Projekt zu beteiligen?
3. Ist der Kunde bereit, mit diesem Projekt zu beginnen?
4. Ist der Kunde bereit, Vertrauen in meine Ideen oder die meines Teams zu investieren?
5. Bin ich bzw. ist mein Team bereit, die Projektanforderungen zu erfüllen oder zu übertreffen?

Auf diesen Artikel hat Obie Fernandez, ein erfolgreicher Berater, in seinem Artikel hingewiesen Machen Sie den Trubel Konferenz zum Thema Beratung.

Answer 5

Was ist Change Management und wie lässt es sich auf ein Projekt anwenden?

Beim Change Management geht es darum, Änderungen an einem Projekt zu genehmigen und zu kommunizieren, bevor sie eintreten.Wenn jemand in Ihrem Projekt (Benutzer, Sponsor, Teammitglied...)Wer auch immer) eine Funktion hinzufügen möchte, muss die Änderung dokumentiert und auf ihre Auswirkung hin analysiert werden.Alle daraus resultierenden Änderungen des Umfangs, des Budgets und des Zeitplans müssen dann genehmigt werden, bevor die Änderung vorgenommen wird.Diese Änderungen werden in der Regel von Ihrem Sponsor, Ihrem Lenkungsausschuss oder Ihrem Kunden genehmigt.

Sobald die Änderungen genehmigt und akzeptiert wurden, ist dies Ihr neuer Plan.Es spielt keine Rolle, wie das ursprüngliche Budget oder der Zeitplan lautete.

Im Change Management von Projekten gilt der Grundsatz „Keine Überraschungen“.Die richtigen Personen (Ihr Change Control Board) müssen alle Änderungen an Umfang, Zeitplan und Budget genehmigen, bevor Maßnahmen ergriffen werden.

Bedenken Sie, dass es bestimmte explizite oder implizite Einschränkungen und Toleranzen für Änderungen geben kann.Möglicherweise müssen Sie Ihr Projekt bis zu einem bestimmten Datum liefern, um die behördlichen Auflagen zu erfüllen.Oder Ihre Organisation hat möglicherweise einen Schwellenwert, bei dem ein Projektbudget, sobald es 30 % über dem ursprünglichen Budget liegt, auf ein „C“-Niveau gehen muss, andernfalls wird das Projekt abgebrochen.Die Untersuchung und explizite Angabe dieser Schwellenwerte und Toleranzen im Vorfeld ist eine gute Möglichkeit, Projekte erfolgreicher zu gestalten.

Wo endet „Change Management“ und wo beginnt „Projektscheitern“?

Wenn ein Projekt den genehmigten Umfang, Zeitplan und Budget einhält, ist es erfolgreich.

Es kann jedoch immer noch als Misserfolg angesehen werden.Post-Implementation-Reviews sind ein gutes Instrument, um dies mit Ihren Stakeholdern (nicht nur Ihrem Chef) zu klären.Auch die Nutzenrealisierung wäre lohnenswert, um einen Blick über den Tellerrand des Projekts hinaus und die Auswirkungen auf das Unternehmen als Ganzes zu werfen.