{"id":708,"date":"2014-07-01T15:24:32","date_gmt":"2014-07-01T14:24:32","guid":{"rendered":"http:\/\/blog.rewoo.de\/?p=708"},"modified":"2014-07-01T15:24:32","modified_gmt":"2014-07-01T14:24:32","slug":"warum-projekte-scheitern-muessen","status":"publish","type":"post","link":"https:\/\/blog.rewoo.de\/?p=708","title":{"rendered":"Warum IT-Projekte scheitern m\u00fcssen"},"content":{"rendered":"

\t\t\t\tSie wussten sicher, dass \u00fcber 70% der Projekte im IT-Bereich abgebrochen wurden, scheiterten oder schlicht nicht die Erwartungen erf\u00fcllen konnten. Laut einer Studie von \u00a0IDG Business Research Service aus dem Jahr 2012<\/a> waren nur knapp die H\u00e4lfte der Befragten \u00fcber den Ausgang ihrer IT Projekte \u201ezufrieden\u201c.<\/strong><\/p>\n

Na, wollen Sie immer noch Ihr n\u00e4chstes Projekt angehen? Keine Angst vor einem BER-Debakel? Gut, denn es gibt Gr\u00fcnde f\u00fcr Ihren Optimismus. Im Folgenden werden 3 Argumente exemplarisch beleuchtet und entkr\u00e4ftet, die nur allzu oft in den K\u00f6pfen von Entscheidern spuken.<\/strong><\/p>\n

Technische Probleme<\/h2>\n

Eine schlechte Ausrede. Pr\u00fcft man die Gr\u00fcnde f\u00fcr gescheiterte Projekte, wird meistens von schlechter Kommunikation, \u00fcberschrittenen Fristen oder Budgets berichtet. Niemals von der falschen Technik, die eingesetzt wurde.<\/p>\n

Wird zu konservativ mit der Frage der eingesetzten Mittel umgegangen l\u00e4uft man Gefahr auf wichtige Erfahrungen und notwendige \u00c4nderungen zu verzichten. Setzt man dagegen auf den letzten Hype, k\u00f6nnte das Projekt in Sch\u00f6nheit sterben.<\/p>\n

Was tun? \u00dcberzeugen Sie sich davon, mit welcher Technik ihre eigene IT-Abteilung am besten umgehen kann, und mit welchen Mitteln sich der Lieferant Ihres Vertrauens am wohlsten f\u00fchlt. Bringen Sie beides in Deckung, liegt ein wichtiger Grundstein zum Projekterfolg.<\/p>\n

schie\u00dfen, zielen, schie\u00dfen \u2026 hoffen, zahlen<\/h2>\n

Das geht besser. Planung ist unerl\u00e4sslich. Ein gemeinsames Verst\u00e4ndnis\u00a0von Lieferant und Auftraggeber \u00fcber Ziele und Probleme muss die Grundlage bleiben. Werden\u00a0gesteckte Ziele priorisiert und laufend \u00fcberpr\u00fcft, sch\u00e4rft sich der Zielkorridor.<\/p>\n

Haben Sie keine klaren Ziele wird ein Projekt nach Zeit&Material (T&M) ausgehandelt. Zwar k\u00f6nnen Sie nun kaufm\u00e4nnisch eindeutig mit der Situation umgehen, jedoch profitiert der Auftragnehmer vom Fortbestand des Projekts. Sie tragen das Risiko und stellen das unkalkulierbare Budget.<\/p>\n

Dem entgegen steht der Festpreis. Daf\u00fcr ist ein klassisches Lasten- und Pflichtenheft die Grundlage, um Zeit, Qualit\u00e4t und Budegt fest zu kalkulieren. K\u00f6nnen Sie im Vorfeld jeden Bedarf genau beschreiben, liegt das Risiko komplett beim Lieferanten. Jedoch sind h\u00e4ufig die Vorstellungen dem Lieferanten schwer kommunizierbar, eine vollumf\u00e4ngliche Spezifikation eine Illusion. Und genau dieser Fakt treibt viele Hersteller zu einem Risikoaufschlag, den Sie bezahlen m\u00fcssen.<\/p>\n

Gibt es eine smarte L\u00f6sung? Ein eindeutiges Jein. In den letzten Jahren hat sich der Begriff des \u201eagilen Festpreises<\/a>\u201c durchgesetzt, welcher versucht beide Modelle miteinander zu vereinen: Das Risiko wird zwischen Lieferant und Auftraggeber geteilt. Transparente Entwicklung, klare Meilensteine, die M\u00f6glichkeit eines Abbruchs ohne Totalverlust sowie leistungsorientierte Abrechnung f\u00fchren beide Teilnehmer zum Erfolg. Ein klarer Nachteil ist die nicht eindeutige Vertragsgrundlage. Im Streitfall ziehen sich beide Parteien auf den grundlegenden Vertrag zur\u00fcck. Und dort ist entweder von einem Werkvertrag oder einem Dienstvertrag die Rede.<\/p>\n

Software muss sich ver\u00e4nderten Zielen\u00a0anpassen k\u00f6nnen<\/h2>\n

Ein klares Nein, weil \u201eMoving targets\u201c in jedem Projekt als Vollstrecker fungieren. Sich nicht eindeutig auf ein klares Ziel einigen zu k\u00f6nnen, kann bedeuten, dass man keines hat. Eine schlechte Voraussetzung f\u00fcr Erfolg.<\/p>\n

Was sich anpassen kann sind die Beteiligten. Denn es existiert\u00a0keine klare Schritt-f\u00fcr-Schritt Anleitung zum Bauen von\u00a0Software, sondern es liegt ein sensibler Kreativprozess zu Grunde. Denken Sie an Ihre Softskills und an die Menschen im Projekt, dann bekommen Sie auch Soft-Ware.<\/p>\n

Es kann aber auch bedeuten, dass eine Partei versucht, den gr\u00f6\u00dferen Gewinn aus dem Auftrag zu ziehen. Eine M\u00f6glichkeit: mehr miteinander statt gegeneinander. Sehen Sie Ihren IT-Dienstleister als Partner an, dann kann er Sie auch als solchen behandeln.<\/p>\n

Fazit<\/h2>\n

Der Hauptgrund f\u00fcr das Scheitern von IT-Projekten ist und bleibt der Mensch. Fragen Sie sich selber, ob Sie einem Dienstleister vertrauen wollen, der Profit als sein oberstes Ziel definiert hat. Kennen Sie seine Motivation, kennen Sie auch sein Vorgehen.<\/p>\n

Finden Sie einen Dienstleister, dessen Ziel der Projekterfolg beim Kunden ist, der mit Ihnen gemeinsam Wege beschreiten will. Dann spielt weder die Technik eine Rolle noch der Vertragsdschungel, sondern die Menschen, die beteiligt sind.\t\t<\/p>\n

<\/div>