Brick wall © Les ChatfieldWas macht Projekte eigentlich so schwierig? Und warum scheitern wir immer wieder, selbst bei guter Planung und eiserner Disziplin bei der Durchführung?
Wir scheitern nicht trotz, sondern wegen dieser vermeintlichen Tugenden. Wir glauben, Projekte durchführen sei wie Pizzabacken - dabei ähnelt es mehr dem Erfinden von Pizzarezepten.
Warum? Weil wir in Projekten nicht immer wieder aus denselben Zutaten dasselbe produzieren wollen - jedes Projekt ist neuartig, ist Forschung und Entwicklung, nicht Produktion. Anders als in der Produktion sind völlig unterschiedliche Resultate nicht inakzeptabel, sondern erwünscht. Dennoch machen wir immer wieder dieselben 4 Fehler:
1. Fehler: Wir halten Prozesse und Tools für wichtiger als Individuen und Interaktionen
Was teuer und kompliziert ist, kann ja nicht schlecht sein, oder? Außerdem gibt es uns das beruhigende Gefühl, das zu tun, was man eben in Projekten tut. Aus einem Input wird in einem Prozess ein Output produziert, klingt logisch.
Allerdings: bei Pizza, Parfüm und Pils sind Inhaltsstoffe und Herstellung peinlichst genau festgelegt - der Kunde erwartet immer dasselbe Resultat in gleich bleibender Qualität. Deshalb sind Prozesse allenfalls geheim, aber ganz sicher nicht kreativ.
Von solchen reibungslosen Abläufen lassen wir uns blenden - was in der Fabrik wie am Schnürchen läuft, kann doch fürs Projekt nicht schlecht sein, oder? Also: ISO 9000 für alle!
Falsch. Denn es gibt keine Arbeitsanweisungen für Kreativität, Kompetenz und Kollegialität. Selbst die angeblich so durchrationalisierte Pizzafabrik kommt ohne menschliches Schmieröl in der Prozesskette nicht aus, bei Dienst nach Vorschrift stünden die Räder bald still.
Viele Regeln und Vorschriften sind manifestierte Befürchtungen: dass jemand ohne konkrete Anweisungen seinen Job nicht richtig machen könnte, dass Ergebnisse nicht standardkonform ausfallen könnten, dass niemand sich selbständig einarbeiten könnte, …
Face your fears. Etablieren und leben Sie in Projekten eine Teamkultur, in der solche Befürchtungen im Gespräch geklärt und stillschweigend überflüssig gemacht statt durch Regeln geadelt werden. Fangen Sie im kleinen Kreis an und «infizieren» Sie andere, machen Sie Teamgeist zu einer Epidemie.
Sie sind auf dem richtigen Weg, wenn Sie mit den meisten Kolleginnen und Kollegen so zusammenarbeiten können, als seien Sie mit allen schon mal ein Bierchen (oder ein Gläschen Wein) trinken gegangen. Widerstehen Sie dem Impuls, bei Problemen Ihre «Verteidigungsschilde» hoch zu fahren und nur einen dünnen «Kommunikationskanal» zu öffnen, wie Captain Kirk auf der Enterprise.
2. Fehler: Wir halten umfangreiche Dokumentationen für wichtiger als das funktionierende, brauchbare Ergebnis
Analysieren, analysieren, analysieren! Erst wenn alle Anforderungen erfasst und verstanden sind, geht es los. Jedes Dokument ist ja auch schon ein Meilenstein, nicht wahr?
Falsch. Analyse.doc crasht nie. Ein Prototyp schon.
Überlegen Sie, was gut genug in Ihrem Projekt bedeutet. Dokumente als Meilensteine sind oft eher Mühlsteine. Es ist reine Verschwendung von Geld und Zeit, Dokumentationen mehr Aufmerksamkeit zu widmen als dem ersehnten Ergebnis. Eine Dokumentation ermöglicht den Teammitgliedern ihren nächsten Schritt im Projekt. Wenn Diagramme und lange Texte wichtiger werden als die Kommunikation im Team, dann läuft etwas falsch.
Probieren Sie frühzeitig aus, was unbekannte Risiken birgt. Lernen Sie schneller, indem Sie früher Ihre Fehler machen. Wenn Ihre Dokumente und Diagramme den Kontakt mit der Realität nur zerzaust überleben - stellen Sie diesen Kontakt öfter her, nicht seltener. If it hurts, do it more often.
3. Fehler: Wir stellen den Verhandlungspoker über die stetige Zusammenarbeit mit dem Kunden
Kennen Sie das, als Kunde? Bei jeder kleinen Abweichung zückt der Projektleiter sofort den Taschenrechner. Um zwecks Gewährleistung einen Werkvertrag unter Dach und Fach zu bringen, bringen Sie besser gleich Ihren Anwalt mit an den Tisch. Einmal unterschrieben, sitzen Sie im goldenen Käfig: Sie können am Projektende auf genau das pochen, was Sie vor einem halben Jahr gebraucht hätten. Alles Neue nimmt erst einmal seinen (langen!) Weg durch einen Lenkungsausschuss (oder gleich ein Change Board). In der Zwischenzeit wird erst einmal das weiter realisiert und in Rechnung gestellt, was Sie schon nicht mehr brauchen. Weil Sie das vor niemandem rechtfertigen können, rüsten Sie sich schon vorsorglich fürs Nach-Tarocken und heben den gesamten E-Mail-Wechsel sorgfältig auf - man weiß ja nie…
Kennen Sie das, als Mitglied im Projektteam? Diese Kunden wissen einfach nicht, was sie wollen. Aber zu einem Dienstvertrag lassen sie sich nie und nimmer bekehren, «Ihr Aufwand für kleine Gefallen ist ja sicher schon in Ihrer Kalkulation mit drin, oder?» Sagen Sie Nein, eskaliert das ganze bis hoch auf eine Ebene, deren Stundengehalt höher als der Monatsverdienst des ganzen Projektteams ist - und dort wird im Zweifel für den Kunden entschieden. Einen größeren Teil Ihres Tages nimmt die ständige Pflege Ihres Excel-Sheets mit Änderungswünschen in Anspruch. Was jetzt genau gilt, analyse.doc oder aenderungen.xls, das wissen nur wenige so ganz genau. Dass jede Änderung Zeit und Ressourcen kostet, versteht der Kunde anscheinend nicht - oder will es nicht verstehen…
Warum ist der Kunde eigentlich nicht in Ihrem Team?
4. Fehler: Wir befolgen lieber einen einmal festgelegten Plan als mutig und offen für Änderungen zu sein
In preparing for battle I have always found that plans are useless, but planning is indispensable.
(Dwight D. Eisenhower)
Was können Sie tun,damit das Projekt auf Kurs bleibt? Es gibt vier klassische Stellschrauben: Zeit, Geld, Qualität und Umfang. Wenn Sie alle vier in Ihrem Projektplan festziehen wollen, werden Sie scheitern. Und je länger Sie darüber nachdenken, desto klarer sollte Ihnen werden, dass auf Dauer der einzig akzeptable Weg über Gespräche zum Umfang führt. Die Stellschraube Umfang macht Änderungen zu Ihrem Partner, ob Sie der Kunde sind oder sein Dienstleister.
Warum wird im Projekt dann so viel öfter über Zeit, Kosten und Qualität geredet? Weil hier nur auf Kosten (mindestens) eines der Beteiligten ein Kompromiss erreicht werden kann. Das macht Pläne so beliebt: Kunde und Dienstleister haben vermeintlich ihr Bestes gegeben und sich «geeinigt» - aber Pläne, nun ja, das kennt man ja…
In Wahrheit wurde nicht das Beste gegeben, wenn der Plan keine Änderungen ohne eine Lawine von Auswirkungen auf die Beteiligten verträgt und jede Änderung in etwa so willkommen ist wie eine Wurzelbehandlung oder die verurteilung zur Sklavengaleere.
Embrace change, muss das Motto lauten. Das ist so gut, dass ich es nicht mal vernünftig übersetzen kann: Umarmen muss man den Wechsel. Er soll nicht eingedämmt, sondern willkommen geheißen werden. Nicht die Änderung ist das Problem, sondern die Fiktion eines Projektplans, der kaum an Gültigkeit verliert.
Bleiben Sie agil!
Glauben Sie nicht alles, was Ihnen als Projektmanagement oder gar als best practices dazu verkauft wird, besonders, wenn es teuer und schwerfällig ist.
Bleiben Sie agil! Konzentrieren Sie sich auf Individuen und Interaktionen, funktionierende und brauchbare Ergebnisse, stetige Zusammenarbeit zwischen Kunde und Dienstleister sowie Mut und Offenheit bei Änderungen. Alles andere ist nicht unwichtig, aber nur untergeordnetes Mittel zum Zweck.
Wie sehen Sie das denn? Schreiben Sie doch gleich hier unten einen Kommentar!
Wenn Sie jetzt neugierig geworden sind, empfehle ich Ihnen wärmstens:
Kommentare
sehr gut deckt sich mit
sehr gut deckt sich mit meinen Erfahrungen vor Ort
viel unnützer Ballast wenig Sachkompetenz
kein hinterfragen ob die eingeübten Abläufe auch sinnvoll sind
arbeite selber schon jahrelang mit dem KOPF Modell da gibt es solche Probleme nicht weil man sich planerisch zu 90 % in der Realität bewegt
KOPF?
Mit dem “Kopf” arbeite ich zwar auch, aber das KOPF-Modell ist anscheinend etwas Anderes? Kenne ich noch nicht - was ist das? Gibts einen Link dazu?
Stimme hier voll zu. Ein
Stimme hier voll zu.
Ein weiterer Punkt der mir immer besonders aufgefallen ist, ist mangelnde Kommunikation. Einer weiß im Team oft nicht was der andere tut. Nicht jeder ist auf dem gleichen Stand.
Hier haben sich tägliche Standup-Meetings (da steht man anstatt zu sitzen) bewährt. Diese sollten nicht länger als 15 Minuten sein. In solchen Meetings kann jeder immer auf den aktuellen Stand gebracht und Probleme schnell aus der Welt geschafft werden.
Interaktion
@Markus: Tägliche Standups sind wirklich ein gutes Mittel! Man sollte Teams zudem auch möglichst direkt zusammen unterbringen - nicht alle Mitglieder an entgegengesetzten Enden des Gebäudes (oder gar der Welt…).
Kommunikation in der Reihenfolge (beste Möglichkeiten zuerst) 1. persönliches Gespräch, 2. Telefonat 3. Email 4. Memo macht die Interaktion effektiv.
@Rolf: Hab noch zwei
@Rolf:
Hab noch zwei Buchtipps dazu, falls du die nicht eh schon kennst:
Smart Talk. Sag es richtig! von Doris Märtin
und
Manage It von Johanna Rothman
http://www.pragprog.com/titles/jrpm
Das lese ich gerade. Super Buch zum Thema Projektmanagement
@rolf hier der link zu kopf
@rolf
hier der link zu kopf http://www.kopf-beratung.de/kopf-methodik/kopf-methodik.html
@rolf Interaktion ich habe
@rolf Interaktion
ich habe mir angewöhnt mir den ganzen tag am nachmittag bzw. abends aus dem kopf zu schreiben ,einen sogenannten tagesrapport.
Bei der Gelegenheit schicke ich Auszüge oder ganze Passagen als Memo an die darin vorkommenden leute
Das wurde bisher immer sehr positiv aufgenommen weil die meisten das ganze dann quer lesen und zum großenteils Ergänzungen oder andere Ansichten hinzufügen,was wiederum die Missverständnisse sehr schnell ausräumt die bei zu vielen Terminen bzw. Besprechungen am tag sehr leicht aufkommen können
Sterben den Dokumentationstod
Hallo,
ich las diesen Artikel und habe unser Projektteam an vielen Stellen wiedergefunden. Wir dokumentieren uns im Rahmen einer etwas größeren Projektarbeit gerade zu Tode, kommen aber nicht wirklich vorwärts.
Vor allem ist die Wahl der Dokumentationsmittel sehr gewöhnungsbedürftig. Ich habe selber schon keinen Überblick mehr, in wie vielen Excel-Dateien ich was dokumentieren soll. Es gibt eine offene Punkte Liste, die schon wie ein Statusbericht aufgebaut ist, dann ist da der eigentliche Statusbericht, dann die Aktivitätenliste, dann das LOV, dann die Prozessliste, dann die Kurzdokumentation und nicht zu vergessen das Sollkonzept…, ah, die Funktionsfolgedatei habe ich noch vergessen. Hier muss das rein, da dieses und dort jenes. Einfach unglaublich. Ich komme schon gar nicht mehr dazu, die eigentliche Arbeit zu machen, da ich nur in irgendwelchen Dateien reinschreibe, was ich noch tun muss, nur tun, da tun wir uns etwas schwer.
Alles eingeführt durch eine externe Beratungsfirma, die dafür auch noch Geld bekommt. Scheinbar traut man uns nicht zu, also dem Team, die wichtigen Dinge ordentlich zu dokumentieren, denn immerhin sind wir ja auch vom Fach.
Uff...
@Marcus: das klingt äußerst anstrengend. Nach welchen Maßstäben wird denn die Leistung der Berater gemessen? War es vorher “noch schlimmer”?
Maßstäbe
@Rolf: Nun, nach welchen Maßstäben dieses Unternehmen bezahlt / gemessen wird, kann ich im Detail nicht sagen, aber da wir ein recht großer Konzern sind, sozusagen einer der größten in DE, haben diese Beraterfirmen alle Rahmenverträge mit der Zentrale. Das Spezielle an unserem Projekt ist, dass es sich um die Migration in das Ein-Mandanten-System des Konzerns handelt, sprich, ein einzelner Standort (Gallisches Dorf) soll in die Systemlandschaft aller anderen einziehen. Und in einem solchen Fall, nehme ich an, ist die Erreichung des Ziels mit möglichst wenig kollateralen Schäden eines der Ziele, an denen die Leistung gemessen wird. So zumindest macht man es mit den Projektmitgliedern.
Natürlich muss da dokumentiert werden, aber um Himmels willen doch nicht die gleichen Dinge in tausend und einer Datei. So sieht es momentan nämlich aus.
Wenn einer mit SAP was macht, dokumentiert er ohnehin jeden Schritt peinlich genau, zumindest wenn dieser jemand sein Handwerk versteht.
ok mein Name ist hier schon
ok mein Name ist hier schon in Verwendung…
Heutzutage versucht man doch alles per Email zu erledigen, möglichst den persönlichen Kontakt so gering wie möglich zu halten. Zumindestens kommt es mir so vor, ich bekomm am Tag ca. 30 Emails mit Aufforderungen etwas zu machen, aber Anrufe gerade 5. Jetzt könnte man sagen, ich bin ein unangenehmer Zeitgenosse, nein ich helfe doch gerne
Aber Teamarbeit funktioniert selten, hab ich langsam den Eindruck. Besonders wenn manche einfach nicht von ihrer Meinung abrücken und die Alternativen nicht wirklich akzeptieren. Somit muß man immer wieder die Teams umbilden, um effizient zu arbeiten, dann frag ich mich gleich, bin ich da nicht zu Zweit oder ganz Alleine gleich schneller?
Leidensdruck
@Markus: Kommt mir (leider) bekannt vor. Das Einzige, was da für mich funktioniert hat, waren direkte Gespräche mit den “Herren” der jeweiligen Dokumente, zwecks Zusammenführens. Da muss aber erst der Leidensdruck groß genug sein (Inkonsistenzen oft genug aufgetreten, unterschiedlich bewertete Prioritäten, “Meinungsverschiedenheiten”, …).
Teamarbeit
@darky: Ja, E-Mails sind nach Papier (.doc, .odt, …) die zweitschlimmste Art der Kommunikation. In einer E-Mail fehlt einfach alles: Blickkontakt, Tonfall, Gestik, Nähe, …
Kein Wunder, dass da Distanz aufkommt. Irgendwann bemerkt aber (hoffentlich) jeder, dass er mit Menschen zusammenarbeitet. Das sprichwörtliche Bierchen (oder das “Du”) sind sehr hilfreich, weil man damit aus der Rollenverteilung ausbricht und den direkten Weg zum Menschen geht. Nach meiner Erfahrung funktioniert das beim weitaus größten Teil der Kolleginnen und Kollegen. Bei einem richtigen A… natürlich nicht, aber die sind seltener, als man glaubt.
was mich noch an dieser
was mich noch an dieser unpersönlichen EMail Korrospondenz stört, man weiß nie so richtig was derjenige oder diejenige will
“Machen Sie bitte das folgendes Programm läuft…”
Ahm ja, und wo soll es laufen, soll es für Alle laufen oder nur für gewisse Personen, soll jeder Zugriff haben etc.
Anstatt aber das in einem kurzen, persönlichen Gespräch zu klären (der Auftraggeber hat keine Zeit für sowas bzw. ist halt Chef ich nix), muß ich daraufhin eine Mail zurückschicken mit den Fragen.
Dann kommt vielleicht 2 Tage später die Antwort und ich hab wieder offene Fragen. Das natürlich in einem Gespräch nicht alle Fragen einfallen bzw. es immer wieder kleinere Fragen gibt ist ja ok, aber so Grundsätzliche sind einfach schneller direkt geklärt.
Das mit dem “Du” hab ich noch nicht raus, aus Höflichkeit hab ich gelernt muß der Ältere einem das “Du” anbieten, aber ich mit meinen 25jährchen gehöre nicht gerade zu den Älteren. Oder seit ihr da einfach so direkt und startet den Versuch?
..ja aber
Im gesamten finde ich die überlegungen sehr gut vorallem den aspekt der veränderung das ein plan nie perfekt ist also immer in beta. Das würde ja heißen das man ständig nach innen und ausen hin kommuniziert .
Aber in punkt 2 verstähe ich nicht ganz wiso analysieren creative-killer sind. Aus persönlichen projekten (also web dienstleistungen etc) hab ich die erfahrung gemacht, dass eine gute recherche ein wesentlicher bestandteil eines projektes ist. Somit definiere ich mir das ziel und laufe auch nicht gefahr etwas was es schon gibt zu widerholen (ist mir nämlich passiert ). Der kreative Aspekt kann ja währden dessen und danach gang und gebe sein. Aus der Perspektive eines Wirtschaftsexperten kann ich mir vorstellen wie trocken ein projekt sein kann, aber als gestalter sind wir ohnehin sehr verspielt und eine gesunde analyse hilft das ziel nicht aus den augen zu verlieren >_>
Analyse
@farux: analysieren als Tätigkeit finde ich gar nicht überflüssig. Nur “Analyse” als “Phase”, die abgeschlossen sein soll, bevor man irgend einen weiteren Handstreich tut, das funktioniert meiner Erfahrung nach meistens nicht. Ein paar Gründe:
- Kundenwünsche ändern sich - die Analyse ist aber angeblich “fertig”. Es folgt der übliche Krieg ums Wer-soll-das-bezahlen.
- Das umfangreiche Analysedokument ist gespickt mit Annahmen und Spekulationen, die sich beim ersten Kontakt mit der Realität (sobald etwas entworfen, gestaltet, realisiert, programmiert werde muss) als hinfällig erweisen. Aber weil das Dokument ja so teuer war, “darf” es sich einfach nicht als (ähmmm…) “verbesserungsfähig” erweisen. Und: niemand steht natürlich gerne dumm da, also wird versucht, das Dokument ohne Feedback aus der Realität möglichst gut und wasserdicht zu machen - statt einfach zuzugeben, dass man vorab unmöglich alles weiß und deswegen zusammen mit dem Kunden eben lernen und verbessern muss.
- Die “Analyse” wird als Phase betrieben, weil “man” das eben “professionell” so macht. Die Resultate gelten dann als heilig - wenn es damit ein Problem gibt, ist es wohl das des Realisierers (Programmierers, Kreativen, Grafikers, …). Analysen werden von einer eigenen Kaste (Analytiker) fabriziert, die für die Machbarkeit nicht gerade stehen, keine “reality checks” anhand von Prototypen o.ä. durchführen und auch nie ein Realisierungswerkzeug (Programmiersprache, Grafiktablett, ) anfassen müssen. Taylorismus pur, eben.
Also ich muss dem Artikel
Also ich muss dem Artikel wirklich voll zustimmen, ich denke, mit zu viel Dokumentation und Analyse, die man in den meisten Projekten findet, kann man einfach keine Chance auf Erfolg haben. Besonders wichtig ist denke ich auch die Diskussion um den E-Mail Verkehr. Ich bekomme auch etliche Mails rein, bei denen immer wieder Rückfragen auftauchen. Aber wenn mir das zu kompliziert wird, das per Mail zu klären, kann ich doch auch selbst einfach mal zum Hörer greifen und sagen, so und so, was genau ist gemeint. Zum Einen kann man dann die Fragen, die sich aus der Antwort ergeben, gleich klären, zum Anderen Zeit sparen. Und effektives Arbeiten wollen doch im Grunde genommen auch die Chefs.
Ich habe bei jedem Projekt
Ich habe bei jedem Projekt einen guten Plan und der ist auf sehr viele Eventualitäten vorbereitet. Ich möchte nämlich nicht überrascht werden. Ich gebe zu, es kommt immer wieder einmal vor, dass nicht alles glatt läuft, aber wenn man alles genau plant und dann das auch so ausführt dann geht das bei mir schon meistens gut. Ich bin nicht so der Typ, der sich dann einfach auf ungefähre Richtlinien verlassen möchte. Bei mir muss ein Plan da sein, der Hand und Fuß hat. Nur dann kann es auch klappen. Bei anderen Personen ist dies vielleicht anders.
Dokumentation
Es ist schon richtig, dass lange Protokolle und Dokumentationen während der Projekte oft eher bremsen als einen nach vorne bringen.
Ein Problem dabei ist aber, dass Kunden genau das erwarten. Sie wollen alles genauestens dokumentiert haben, damit sich jeder im Notfall einlesen kann und somit weiß, dass alles richtig gemacht wurde.
Ohne eine Dokumentation fehlt der Nachweis.
Dokumentation
@Waldemar
Diese Art Kundenerwartung kenne ich (der “Lieferant” will’s natürlich auch oft “nachweisen”). Kommt für mich auf den Zweck der Dokumentation an, ob sie etwas Gutes ist.
Ich habe das ungute Gefühl, dass der “Notfall” bei uns öfter juristischer Natur ist denn fachlicher, zwecks “Nachweis” eben. Falls die Dokumentation tatsächlich gebraucht wird, weil sie auch ab und zu “benutzt” wird (statt im Schrank zu verstauben), finde ich sie auch gut. Handbücher und Hilfedateien gehören für mich klar in diese Kategorie.
Mag sein: vielleicht ist es auch nur typisch für meine Branche (IT & Organisation), dass Dokumentation nur für die Schublade produziert wird und sich dann selbst im Notfall, wenn sie herausgezogen wird, als wenig hilfreich erweist. Vieles, was mir unter die FInger kommt, dient eindeutig dem, was man auf Englisch “cover your ass” nennt, also: sich nach allen Seiten absichern. Manchmal fühlen sich Projektbeteiligte förmlich dazu gezwungen, z. B. alle alten E-Mails zu archivieren u.ä. Das ist für mich ein Signal, die Zusammenarbeit auf andere Füße zu stellen statt noch mehr zu “dokumentieren”.
Dokumentation
@Rolf
Da bin Ich recht froh dass bei mir alles in der VOB(Verdinge Ordnung Bau) geregelt ist.
Und vor allem auch bezahlt wird
VOB (Verdinge Ordnung Bau)
@erwin:
Ja, in der IT kann man den Keller “vergessen”, und keiner merkt’s… ;-)
Interessant!
Finde dieses Kopf Modell auch sehr interessant. Gibt es da mehr Informationen zu ?
@sarah wunderberg
http://www.kopf-beratung.de/kopf-methodik/kopf-methodik.html
das iste der link zum kopf -system näheres googeln
Dazu fallen mir die “6
Dazu fallen mir die “6 Stationen” eines Projektes ein.
1. Begeisterung
2. Ernüchterung
3. PANIK
4. Suche nach Schuldigen
5. Bestrafung von Unschuldigen
6. Auszeichnung von Nichtbeteiligten
;-)
ps:(die Captchas sind für Menschen ja schon fast unschaffbar… oo)
Warum Projekte scheitern?
Warum Projekte scheitern? Oft werden in IT Projekte Freiberufler / Projektleiter eingesetzt, die nicht genügend Qualifiziert sind und unzureichendes KnowHow haben. Wenn dann weder ein Projektplan, Pflichtenheft oder sonstiges vorliegt geht vieles schief.
Kommentar hinzufügen