Gründe für das Scheitern von IT-Projekten aufgedeckt

Einführung

Die Kernkompetenz jedes IT-Unternehmens basiert auf einem starken IT-Team (das konfigurierbare Projekte termingerecht bereitstellt). Aber warum wird manchmal diese wunderbare Vision eines idealen Teams, das ein reibungsloses Projekt abliefert, ruiniert? Anstelle von Produktivität, Innovation und Erfolg stehen CTOs und CIOs vor Herausforderungen im Zusammenhang mit der Implementierung, einem schrumpfenden Budget und einer tickenden Uhr.

Laut Der Chaosbericht der Standish Group, fast 30% des IT-Projekts Implementierungen sind richtig gemacht und mit Erfolg, wohingegen 20% der Projekte sind totale Fehlschläge.

Bevor wir zum Punkt der Misserfolge kommen, schauen wir uns die Anforderungen an ein erfolgreiches Projekt an:

All diese Dinge müssen passieren, um ein Projekt mit Stolz zu produzieren. Nun, da die Erwartungen hoch sind, beweist die Realität, dass es kaum realisierbar ist (fast ¼ Projekte scheitern an schlechten Anforderungen). Was sind die Gründe dafür?

Falsche Anforderungen

Das Team ist nicht anwesend, während jemand die Spezifikation für ein Projekt schreibt. Wenn ein Team zum ersten Mal einen Entwurf für etwas sieht, an dem es arbeiten kann, kann sich das auf den gesamten Prozess auswirken. Es ist sehr wahrscheinlich, dass das gesamte Projekt nicht abgeschlossen werden kann, und es wird notwendig sein, es völlig zu überdenken und... bei Null anzufangen.

ABHILFE:

Bringen Sie in der Planungsphase alle Experten zusammen — Partner, Vertreter von IT-Teams, Anwender (!) — Sie werden Ihnen sagen, was Sie ändern müssen, und einige Lösungen finden. Geschäftsvertreter können mit Endbenutzern zusammenarbeiten, um die Hauptziele eines Projekts zu kennen. Es ist eine gute Möglichkeit, ein erfolgreiches Projekt zu entwerfen.

Unbeteiligte... Sponsoren

Sponsoren sollen in die Entwicklungsphase einbezogen werden. Sie können nicht einfach die Vision diktieren und darauf warten, dass die gesamte Arbeit erledigt und veröffentlicht wird.

Was ist, wenn Probleme, Fragen auftauchen? Es gibt keinen Vertreter, an den man sich wenden kann. Wenn ein Team von Entwicklern ohne Rücksprache entscheidet, wie ein Projekt ablaufen soll, und die falsche Entscheidung trifft, ist das Geschäft ruiniert.

Die Forschung von PMI hat das aufgedeckt 27% der Projekte scheitern aufgrund mangelnder Sponsorenunterstützung.

ABHILFE:

Prüfen Sie immer, ob es einen Projektsponsor oder eine andere beauftragte Person gibt, die Sie während der Entwicklungsphase eines Projekts berät, Fragen beantwortet und die Arbeit überprüft.

Veränderte Projektziele

Viele IT-Teams arbeiten im SCRUM-Framework — in kurzen Iterationen (von einer Woche bis zu einem Monat). Zu Beginn jeder Iteration gibt es Zeit, die Arbeit zu planen. Der Plan kann nicht einfach geändert werden, aber jede neue Iteration eröffnet die Möglichkeit, Änderungen vorzunehmen.

Manchmal kann es schwierig sein, sich ändernden Zielen zu folgen, aber ihre Auswirkungen können minimiert werden, indem bei Bedarf ein Modell eingeführt wird, das den Wandel unterstützt.

Denken Sie daran: Veränderungen bedeuten nicht Misserfolg! Sie können das Risiko reduzieren, indem Sie den Zeitrahmen von Plänen minimieren.

ABHILFE:

Es ist gut, die Arbeit in zweiwöchigen Iterationen zu planen: Sagen Sie, welche Aufgaben am wichtigsten sind, und konzentrieren Sie sich in diesen 14 Tagen darauf. Lassen Sie das Team sich auf die wichtigsten Aufgaben mit der höchsten Priorität konzentrieren, um wertvollen Code bereitzustellen.

Ungeschickte Schätzung

In der frühen Phase eines Projekts ist eine Schätzung wie eine Vermutung. Ihr IT-Team weiß wirklich wenig über ein Projekt und seine Kosten, die geschätzte Veröffentlichungszeit und die Anforderungen, um die Implementierungskosten und den Zeitrahmen zu kennen.

Wenn die Entwicklung beginnt und die Anforderungen weniger verschwommen sind, ist es an der Zeit, mit einer langsamen Schätzung zu beginnen.

Bei IT-Projekten scheinen veränderbare Schätzungen erforderlich zu sein, da fast kein Sponsor ohne Zusicherung in etwas investiert. Sie brauchen etwas, ein Entwurf oder Idee um die Kosten und Risiken einer Investition zu kennen.

Tatsächlich werden ungenaue Berechnungen und Vermutungen verursacht durch:

• schlechte Schätzungspraktiken — Entwicklerteams haben keine Erfahrung in der Erstellung von Schätzungen und gehen davon aus, dass weitere reibungslos ablaufen werden.
• zu früh planen — Projektmanager und CTOs wollen die Schätzungen so schnell wie möglich wissen, und das bedeutet oft sofort.

ABHILFE:

Wenn das Schätzen für Sie nicht funktioniert, versuchen Sie es Schätzen in Bereichen. Wenn deine Entwickler sagen, dass ein Projekt in 2 Monaten abgeschlossen sein wird, nimm das mit Kegel der Unsicherheit (in Agile) und berücksichtigen Sie den Umfang, der für die aktuelle Phase des Projekts gilt. Wenn es sich beispielsweise um die Anfangsphase handelt, geben Sie die Schätzung als „zwischen 2 Wochen und 4 Monaten“ an.

Plötzliche, unerwartete Risiken

Der oben erwähnte Unsicherheitskegel war in der Tat für solche Risiken konzipiert. In der Anfangsphase schätzen die Entwickler die Zeit ein, die bis zum Abschluss der Codierung benötigt wird. Richtig... denken Sie daran, dass immer noch ein hohes Risiko unvorhersehbarer Fehler besteht. Verlassen Sie sich auf Schätzungen 4 mal die vermeintliche Zeit des voraussichtlichen Zeitpunkts der Veröffentlichung.

Diese zusätzliche Zeit ermöglicht es, alle unerwarteten Probleme zu lösen, die auftreten. Denken Sie daran, dass Sie dank des Kegels der Unsicherheit und ohne Ausfälle früher und günstiger fertig werden können... und denken Sie darüber nach, dies Ihrem Kunden mitzuteilen!

ABHILFE:

Plötzliche Risiken sind bei fast 30% der Grund für das Scheitern von Projekten. Aber dafür gibt es eine Lösung! Es ist dasselbe wie bei ungeschickten Schätzungen. Schätzungen müssen die bekannten und unbekannten Risiken widerspiegeln, um unerwartete Fehltritte wirklich zu vermeiden.

Ressourcenlosigkeit

PMs, CTOs und CTOs neigen dazu, Menschen (also Mitarbeiter) als Ressourcen zu bezeichnen, und „nicht genug Ressourcen“ zu haben, bedeutet, nicht genug Leute zu haben, um an einem Projekt zu arbeiten. Diese Situation tritt in über auf 20% der gescheiterten Projekte.

Verschiedene Methoden haben unterschiedliche Einschränkungen. Bei der WATERFALL-Methode — Budget — haben Sie hier Geld, um Ihre Arbeit zu Ende zu bringen. Bei AGILE — Umfang — erledigen Sie die Arbeit, die Ihr Team erfolgreich abschließen kann.

Bei Projekten mit geringen Ressourcen kommt es häufig vor, dass Umfang, Budget und Zeitrahmen unflexibel sind, was nicht gut ist. Mindestens eine dieser Einschränkungen muss flexibel aufgrund unerwarteter Risiken.

Tatsächlich sollte ein Mangel an Ressourcen niemals der Grund für Misserfolge sein! Das sollte der Grund sein, warum das Projekt nicht gestartet wurde. Wenn Sie Ihr Projekt richtig planen, sollten Sie von Anfang an wissen, ob Sie genug Leute in Ihrem Team haben, um so viel Arbeit in einem bestimmten Zeitrahmen zu erledigen.

ABHILFE:

Lösen Sie das Problem der Ressourcenlosigkeit einfach: Machen Sie eine der 3 Einschränkungen: ZEIT, BUDGET, UMFANG flexibel.

Wir beenden diesen Artikel mit einer Liste von 3 Dingen, die Sie tun müssen, um ERFOLGREICH ZU SEIN:

• geben Sie allen an einem Projekt beteiligten Experten die Möglichkeit, sich während des gesamten Lebenszyklus zu äußern, um falsche Anforderungen und unzureichende Produkte zu vermeiden.
• Wählen Sie eine flexible Einschränkung — Zeit, Budget oder Umfang — und führen Sie regelmäßig eine Neuplanung durch, um zu überprüfen, ob die Pläne planmäßig verlaufen (oder passen Sie sie an, um wieder auf Kurs zu kommen).
• Den Schätzungen aller Beteiligten den Begriff „Unsicherheitskegel“ anvertrauen, um das Risiko unerwarteter Ausfälle und Verzögerungen zu verringern.