Allen Mitarbeitern in allen Firmen, egal ob sie Produkte herstellen oder Dienstleistungen anbieten, kann es passieren: das interne Projekt. Dieses neigt dazu, kompliziert zu sein.
Daher übernehmen die wenigsten Mitarbeiter gerne interne Projekte. Verständlich, denn der Ärger, unnötige Emotionen und ineffizientes Arbeiten scheinen vorprogrammiert. Was empfiehlt sich, um stressfrei durch das interne Projekt zu kommen?

Emotionen und unklare Rollen - das gehört zu internen Projekten
Es ist eine Aufgabenstellung im Haus ohne Kundenkontakt zu lösen. Dabei sind zwei Grundtypen von internen Projekten zu unterscheiden:
- Projekte mit möglichen, direkten Konsequenzen für Mitarbeiter
Umzüge, Umstrukturierung, Aus- und Fortbildungen - Erbringung der eigenen Dienstleitung bzw. Herstellung des eigenen Produkts für die eigene Firma
Während im ersten Fall sehr schnell Unruhe im Projekt auf Grund von negativen Emotionen Projektbeteiligter herrscht, verschwimmen im zweiten Fall leicht die Grenzen zwischen Auftraggeber und -nehmer im Unternehmen. Der Fokus dieses Blog-Artikels liegt auf dem zweiten Fall.
Was ist zu tun?
Um ein Projekt erfolgreich zu durchlaufen, muss man klarhaben, warum man das Projekt machen möchten, wie man im Team und mit dem Auftraggeber zusammen arbeiten möchte und was genau zu tun ist.
Das "Warum?" klären
Viele Führungskräfte kennen die Unternehmensziele ihres Unternehmens nicht (extern: ZEIT), um so schwerer wird es ihnen fallen, eine inhaltliche Begründung für ihr Tun zu definieren.
Deswegen empfiehlt es sich, eine Arbeitshypothese für das interne Projekt aufzustellen, die bei jeder Vorstellung von (Teil-)Ergebnissen sowie bei Steuerungstreffen erläutert wird. Ihr macht so das Maß öffentlich, mit dem Ihr messt. Sollte sich nachträglich ein Projektbeteiliger "outen" (interne Projekte neigen dazu, mehr Projektbeteiligte zu haben, als am Beginn definiert wurden), ist vor einer Detaildiskussion des Projekts die inhaltliche Begründung zu diskutieren.
Dies fällt manchem Projektleiter nicht leicht - weil er sich im Tanzgebiet seiner Vorgesetzten aufhält. Ohne die Klärung der Sinnfrage bzw. der Motivation wird das Projektteam nicht gut Fahrt aufnehmen. Also: nur Mut - es lohnt sich.
Das "Wie?" klären
Bei Projekten, die einen klaren Auftraggeber und einen klaren Auftragnehmer haben, klärt man zunächst die internen Teamregeln. Daraus ergeben sich Anforderungen, die man mit dem Auftraggeber weiter verhandelt. Es kann dann zu einer iterativen Schleife kommen, bei der man nochmals die Team-Zusammenarbeit feinjustiert.
Da der Kunde in diesem Falle außerhalb des eigenen Hauses ist, kann sich das Team zunächst alleine finden - und dann eine für das Team gute Form der Kommunikation mit dem Auftraggeber definieren.
Bei internen Projekten ist das schwerer. Die Projektwerte Rhythmus, Transparenz, Beständigkeit sind schwerer einzuhalten.
Schließlich haben auch diejenigen Projektteilnehmer, die sich eher auf der Auftraggeberseite sehen, auch gerade ein Projekt gestartet. Während sie im Falle einer externen Betreuung nicht ständig involviert wären, können sie nun - da sie ständig Projektteilnehmer treffen - direkt ihre Ideen & Anregungen einbringen. Damit gerät das Projekt leicht aus dem Takt - weil nicht mehr klar ist, wann geliefert wird - und zu welchem Zeitpunkt Input erfolgt.
Daher kommt zur Fragestellung, wie man zusammenarbeitet noch viel stärker die Frage, wer in welcher Rolle zum Projektteam gehört. Bei internen Projekten ist zu klären, wer Auftraggeber und -nehmer ist.
Das ist in Unternehmen mit flachen Hierarchien, die eine stark unterstützende Unternehmenskultur hat, sehr schwierig auseinanderzuhalten. Aber auch in Unternehmen mit starken Hierarchien ist diese Fragestellung nicht immer leicht zu beantworten. Sehr oft sind hier die "offiziellen" Auftraggeber nicht die wirklichen Auftraggeber, sondern deren Vorgesetzte. Hier hilft nur das Einfordern direkter Kommunikation.
Bei internen Projekten kann im Prinzip jeder Vorgesetzte eines Projektbeteiligten und jeder Arbeitskollege eines Projektbeteiligten nachträglich sich zum Projektbeteiligten erklären. Je nach Beantwortung der "Warum"-Frage eher auf Auftraggeber oder -nehmer-Seite.
Damit dieses Durcheinander nicht entsteht, ist von Beginn an für Beständigkeit des Projektteams zu sorgen. Da gilt es bei Projektbeginn den initialen Auftraggeber (und ggf. dessen Vorgesetzten) ordentlich zu bearbeiten, damit die Frage nach Projektteilnehmern und deren Rollen ausreichend beantwortet ist.
Tritt unerwartet ein Akteur auf, ist dieser entsprechend offen zu kommentieren und zu integrieren: "Ich wußte gar nicht, dass Sie dabei sind. Welches Anliegen treibt Sie? Welche Rolle nehmen Sie ein?" Ggf. ist die Arbeitshypothese des "Warum" anzupassen - dies wiederum ist an alle bereits bekannten Projektteilnehmer zu kommunizieren.
Implizite Annahmen und ungesagte Tatsachen sind Kardinalfehler interner Projekte. Wir glauben, dass alles klar sei - aber gerade weil es intern ist, verlaufen Entscheidungen oft leise. Es ist eine Transparenz über alle im Projekt getroffenen Annahmen und aufgefundenen Tatsachen herzustellen. Diese unterfüttern die Arbeitshypothese.
Das "Was?" klären
"Was" ist eigentlich genau zu machen? Diese Fragestellung hat der Projektauftraggeber zu definieren. Bei der Ausformulierung des bzw. der SMARTen Ziele könnt Ihr (ggf. mit dem Projektteam) helfen.
Bei externen Projekten wissen wir, dass wir SMARTe Ziele benötigen, um sinnvolle Abnahmekriterien (Qualitätskriterien) für die Abnahme des Projekts ableiten zu können. Bei internen Projekte gewinnt aber "König Schlumpf", denn "es ist ja klar, was wir wollen".
Also so wie immer: SMARTe Ziele und Qualitätskriterien für die Abnahme definieren. Jedwede Abkürzung oder Unklarheit wird das interne Projekt verlängern.
Auf Grund weniger Beteiligter mehr Option auf Durcheinander
Ein internes Projekt ist auf eine Art ein normales Projekt. Und in diesem Sinne sind die typischen Projektfragen "Warum?", "Wie?" und "Was?" unter Berücksichtigung der Projektwerte Rhythmus, Transparenz und Beständigkeit zu beantworten.
Wir neigen dazu, dies in internen Projekten nicht zu tun. Wir wollen "schlanker" und "schneller" agieren. Weil wir uns selbst für Projekt-Profis halten, versuchen wir, abzukürzen. Oh, wirklich? Abkürzen mit unklaren Rollen ist keine gute Idee. Das schafft ein gutes Durcheinander.
Insofern macht sorgt für Antworten auf die Grundfragen, habt eine Auge auf die Anzahl und Motivation der Projektbeteiligten - und arbeitet ganz in Ruhe. Dann wird's schon - auch mit dem internen Projekt.
Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.
- Nächster Artikel: Heute für Geld und morgen umsonst
- Vorheriger Artikel: Erfolgreiche Projekte
- Kategorie: Projekt
Kommentar schreiben
Holger (Freitag, 13 April 2012 12:19)
Ich bin mir nicht sicher, was hier mit "interne Projekte" eigentlich gemeint ist. Ich vermute mal, es ist vor allem im Unterschied zu "Aufträge bzw. Projekte durch Kunden" gemeint und ist stark von der Sicht eines Lösungsanbieters gedacht. Aber in der Realität sind ganz viele von den angesprochenen Punkten auch relevant für Entwicklungsprojekte bei Firmen, die keine eigenen Entwicklungsabteilungen haben. Da ist dann im Zweifelsfall schon der Kommunikationspartner zum externen Dienstleister (also der interne "IT-PL") in der Auftragsnehmer-Rolle.
Aber mir reicht es nicht, die Rollendiskussion auf "Auftraggeber" und "Auftragnehmer" zu reduzieren. Ich denke, es ist wichtig, alle Beteiligten eines Projekts zu kennen -- das ist im Endeffekt die klassische Stakeholder-Analyse, die wichtig ist, vollkommen unabhängig vom eingesetzten Projektvorgehen. Wenn man ein "internes" Projekt zum Erfolg führen will, ist es m.E. nach wesentlich, alle Stakeholder in passendem Maße zu involvieren (Bedürfnisse abholen, bei Entscheidungen involvieren, informieren). Das ist bei klassischen "externen" Projekten halt eine Aufgabenstellung auf Seiten des Kunden, bei "internen" Projekten ist man da halt nur sein eigener Kunde.
Judith Andresen (Freitag, 13 April 2012 20:21)
Wie ich in den ersten Zeilen schrieb, skizzierte ich mit diesem Blog-Artikel genau die Situation, die sich ergibt, wenn man die eigentlich für einen Kunden adressierte Leistung / Produkt nach "innen" leistet.
Ja, und ich stimme Dir auch zu, dass es einer Stakeholder-Analyse ("wer ist dabei mit welchem Ziel?") bedarf - immer. Mein Punkt war und ist, dass die Stakeholder sich in internen Projekten aber oft erst im Laufe des Projekts zeigen.
Und dann ist die Aussage "ist man da halt nur sein eigener Kunde" schon schwerer. Dass viele am Projekt Beteiligten bei internen Projekten auch Zwitter-Rollen einnehmen, macht es auch nicht leichter. Daher ist mein Blog-Artikel das Plädoyer für Klarheit - und das Werben dafür, gerade in internen Projekten für Klarheit zu sorgen.