22
Aug 2014
Meilenstein – Der Projektmanagement-Blog

Der Prozess-Hürdenlauf

Vor einigen Wochen hat sich ein großes deutsches Bahnunternehmen bei mir bedankt. Natürlich ist solch ein Dank bei einem Großkonzern fest in Prozessen verankert. Irgendjemand im Haus hat davon gelesen, dass ein Dankeschön nach dem Kauf ein Zeichen der Wertschätzung ist und die Kundenbindung erhöht. Kurz darauf saß eine Projektgruppe zusammen und änderte die Prozesse, damit die Kunden endlich einmal zur Kenntnis nehmen, dass man sie wertschätzt. Und so wird aus einem Dankeschön das klare Signal, welche Bedeutung man als Kunde wirklich hat.

Anzeige

Jeder Kunde quält sich, nicht das Unternehmen

Nach einigen freundlichen Worten für mein BahnCard-Upgrade bittet die Absenderin der Dankes-E-Mail noch um meine Bankverbindung – falls man die nicht schon habe. Ein paar Zeilen weiter folgt: "Antworten Sie bitte nicht über die Antwortfunktion auf dieses Schreiben, da die oben genannte Adresse nur zur Versendung von E-Mails eingerichtet ist." Natürlich ist es nur eine Sache von wenigen Sekunden, die dann angegebene echte E-Mail-Adresse von Hand in die Antwort einzufügen. Man könnte aber auch leicht die Absenderkennung so einstellen, dass ein "Antwort"-Klick ausreicht, so wie es allgemein üblich ist.

Und die Bankverbindung? Könnte man da nicht einen kleinen Hinweis geben, ob man schon eine Bankverbindung hat und falls ja, welche? So muss eben der Kunde wissen, welche Daten die Konzern-IT sauber übernommen hat. Solche Prozesse vermitteln klar, dass es besser ist, wenn sich die andere Seite, der Kunde, Arbeit macht, bevor man selber die Prozesse optimiert.

Man braucht kein Bahnfahrer zu sein, um dieses Phänomen zu beobachten. Ob beim Hotel-Check-In die online erfassten Daten nochmals handschriftlich ins Meldeformular übertragen werden müssen oder ein Telefonanbieter Adressdaten im Online-Formular bei der Anmeldung automatisch prüft und Datenbank-Fehler auf den potentiellen Neukunden abwälzt: Wer immer den Prozess gestaltet – die eigene "Swimlane" wird gut optimiert, während der Aufwand für die Prozessschritte der anderen eher großzügig gesehen wird oder gar nicht bewusst ist. Das gilt oft auch im Projektmanagement.

Massig Daten für das PMO?

Für ein PMO sind Statusberichte aus den Projekten eine wertvolle Informationsquelle. In ihnen werden die Informationen abgefragt, die eventuell an anderer Stelle für Berichte benötigt werden. Oft sind dies weitaus mehr als erforderlich. Zwar wird hier nicht nach der schon bekannten Bankverbindung gefragt, doch die Frage nach Projektnummer oder aktuellem Budget und Ist-Kosten ist üblich. In vielen Fällen müssen Projektverantwortliche diese Daten dann im Unternehmen zusammentragen, um sie ans PMO zu berichten. Dabei könnte dieses die Finanzdaten auch direkt mit dem Controlling ermitteln und den Projekten in aufbereiteter Form als Service zur Verfügung stellen. Dann entstünde der Sammelaufwand nur an einer zentralen Stelle.

In einem Kundenunternehmen erstellten wir gemeinsam mit allen Projektbeteiligten eine Berichtslandkarte für projektbezogene Auswertungen. Es stellte sich heraus, dass rund ein Drittel der regelmäßig aus den Projekten gelieferten Daten schlichtweg irgendwo versandete. Sie wurden nicht für Entscheidungen benötigt. An vielen Stellen wurden Informationen doppelt erfasst. Projektleiter benötigten beispielsweise ihre eigenen Meilenstein-Übersichten für die Projektsteuerung und mussten gleichzeitig Monat für Monat die wichtigsten Meilensteine in die Statusberichts-Vorlage und eine Kurzfassung für das Portfolio-Board übertragen.

Als wir die überflüssigen und doppelten Informationen identifiziert und das Berichtswesen vereinfacht hatten, begann sich auch die Datenqualität zu verbessern. Den Projektbeteiligten war nun klar, wofür sie die Daten lieferten und sie mussten weniger Daten zur Verfügung stellen. Umwege, etwa vom Rechnungswesen über die Projekte an das PMO, wurden vermieden.

Besser: Der Prozess-Eigentümer quält sich, nicht die Mitwirkenden

Das PMO hatte viel Aufwand investiert, um die Berichtsprozesse vor allem für die Projektteams und die Projektleitungen zu optimieren. Auch die unterstützende Software wurde anschließend erheblich erweitert, um nicht nur eine Projektdaten-Erfassungsmaske zu bieten. Das PMO-Reporting-Tool wurde so zu einem Werkzeug für die tägliche Projektarbeit.

Um Prozesse auf diese Weise zu optimieren, muss zum einen die Bereitschaft vorhanden sein, Aufwand zu investieren, der nicht unmittelbar dem eigenen Tätigkeitsfeld zugutekommt. Ein PMO, dessen Auftrag auch die Service-Leistung für Projekte beinhaltet, hat es da leichter, als ein reines Datensammel- und Prozess-Überwachungs-PMO. Doch auch dort ist es von Vorteil, wenn es die anderen Prozessbeteiligten einfacher haben. Der Prozess läuft dann reibungsloser und die Datenqualität steigt. Das Bahnunternehmen bekommt bei falschen und fehlenden Bankverbindungen eher eine Antwort, anstatt dass die E-Mail im Papierkorb landet.

Manche Optimierungen kann man alleine durchführen. Dass ein Klick auf "Antworten" einfacher ist, findet man heraus, wenn man sich kurz in andere hineinversetzt oder den Prozess einmal konkret durchspielt. Doch guter Wille allein reicht oft nicht. Viele Optimierungsmöglichkeiten finden sich offenbar nur, wenn der Prozess gemeinsam mit allen Beteiligten entwickelt wird.

Noch besser: Prozess-Eigentümer und Mitwirkende quälen sich einmal richtig

Dank der Aufgabenteilung im Unternehmen kann sich jeder Bereich auf sein Metier spezialisieren. Das macht die Organisation leistungsfähiger. Gleichzeitig entstehen unterschiedliche Fachwelten, die nicht immer zusammenpassen. Um die Anforderungen und Denkweisen von PMO, Projektleitungen, Projektmitarbeitern, Entscheidern, Controlling, Rechnungswesen und anderen in einem Prozess optimal zu berücksichtigen, müssen diese den Prozess gemeinsam entwickeln.

In einem diskursiven Prozess fließen unterschiedliche Sichtweisen ein und ringen um Ausgleich. Um kein Missverständnis aufkommen zu lassen: Am Ende liegt die Entscheidung beim Prozess-Eigentümer und nicht jeder wird glücklich sein. Aber zumindest sind die Problemstellen dann bekannt und die Beteiligten wissen, welche Prioritäten dazu geführt haben.

Bisher gibt es 1 Kommentar
Die Aussagen bei "Massig Daten für das PMO ?" kann ich nur unterstreichen.
Was oftmals unterbleibt, ist die ganzheitliche Betrachtung des Projektabwicklungsprozesses.
Mittels Lean Administration wird man hier schnell fündig, welche "Verschwendungs-"Themen angegangen werden müssen, wenn der gesamte Project Life Cycle einbezogen wird.
Bereits mehrfach ist mir da die strikte Trennung zwischen der Proposal-Phase und der Realisierung untergekommen. Das fängt an mit unterschiedlichen Projektnummern und teils auch Projektnamen, begründet mit "man muss auf den ersten Blick sehen um was es sich handelt".
Überflüssig zu erwähnen, dass dann der Vorschlag, den Konflikt mittels eines einfachen Statusfeld aufzulösen, als Overhead oder als "zu umständlich" angesehen wird.
Allein diese Trennung erschwert es oder macht es gar unmöglich, die in der Proposal- bzw. Contractphase erfassten Projektdaten für den Abwicklungs-Projektleiter zu übernehmen, oder - was noch besser wäre - in einer gemeinsamen Datenbasis zugreifbar zu machen.
Und gerade in großen Organisation, welche teils auch noch mit unterschiedlichen Tools arbeiten, sind dann Mehraufwand und Datenkonsistenz Problemfelder, welche man nicht mehr in den Griff bekommt.
vor 2 Jahre 2 Wochen Manfred Reinhold
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link