Schlagwort: Projekte

Kochrezept: Offene Punkte Listen

In Projekten werden nach einigen Wochen aus wunderbar schlanken Offene-Punkte-Registern gerne Ansammlungen von Unrat, die kaum einen guten Überblick bieten und schnell nicht mehr als Arbeitsmittel genutzt werden. Derlei Listen firmieren unter Open-Issue-List, Action-Tracker aber auch Risiko-Register können stark anwachsen. Nachfolgend 6 Tipps um das Zeug handhabbarer zu machen:

1. Unnütze Spalten löschen

Vorgegebene Offene-Punkte-Listen haben manchmal Spalten, die im aktuelle Projekt gar keinen Mehrwert darstellen. Diese bitte großzügig löschen. Nicht sinnvoll anwendbare Einträge füllen die Liste mit Unrat und erzeugen bei Projektmitgliedern einen Widerstand. Grundsätzlich gilt Dinge die unklar oder unscharf sind: Am besten weglassen.

2. Listen kaskadieren

Teilprojekte oder Untergruppen sollten ihre eigenen Action-Tracker führen. Ungleiche Gewerke in einer Liste sorgen für Unübersichtlichkeit und unnütze Diskussionen, wenn fachfremd über die Punkte der Nachbargruppe philosophiert wird. Dabei rate ich dazu wirklich trennscharf zu arbeiten. Eine Aufgabe findet sich inklusive ihrer Teilaufgaben in genau einer Liste. Nicht etwa die Aufgabe im Projekt-Register und Unteraufgaben im Unter-Projekt-Register.

3. Verantwortlichkeiten, Mitarbeit und Zustimmungen

Für einen Offenen Punkt sollte immer genau ein Teammitglied verantwortlich sein. Das ist manchmal aber gar nicht so eindeutig, da Nachbarprojekte befragt werden müssen oder diverse Personen eingebunden sein müssen. Den Verantwortlichen im Feld „Responsible“ zu unterstreichen ist mühsam und wird hie und da vergessen, deshalb rate ich dazu drei Felder zu führen Responsible, Consulted und Informed. Dabei darf in das Feld Responsible stets nur ein Name.

4. Fertigstellungszeit

Eine Kleinigkeit führt in vielen Listen zu übersehenen Punkten. Jeder Punkt muss neben dem Erstellungsdatum ein Fertigstellungsdatum haben, dieses wird manchmal verschoben und in einem separaten Feld „Revised Date“ geführt.

Sinnvoller für das Sortieren der Liste nach den kommenden abzuschließenden Aufgaben ist es ein Fertigstellungsdatum zu führen. Das zu Projektanfang festgelegte Datum kann in ein Feld „Initial“ der Inhalt des Felds Initial wird per Formel in Fertigstellungsdatum kopiert. So kann die Liste immer nach den aktuellen Fertigstellungsdaten sortiert werden. Siehe Beispiel Open Actions Tracker.

5. Abgeschlossene Punkte herausnehmen

In einer Tabellenkalkulation kann zwar sehr schön gefiltert und sortiert werden, trotzdem rate ich dazu, geschlossene Punkte in eine separate Tabelle zu kopieren. Hier können dann gegebenenfalls noch zusätzliche Felder für Kommentare, Abnahmen, etc. hinzugenommen werden. Auch erleichtert dies eine Übersicht zu den Punkten die aktuell geschlossen wurden. Eventuell steht ja hier noch der Kommentar des Kunden aus und ein Punkt wird wieder aktiviert wird.

6. „Should“ und „Could“ zu „Won’t“

Einige Offene Punkte mutieren zu Strandgut welches immer wieder oben angespült wird. Bei diesen Punkten werden andauernd Zeiten nach hinten geschoben oder Verantwortlichkeiten gewechselt. Geschehen tut nichts. Das verstopft Statusmeetings und nervt die Beteiligten. Dieses Strandgut an Punkten sollte zu Ende jeder Projektphase neu bewertet werden. Meist sind diese Punkte als „Could“ seltener mal als „Should“ eingestuft worden. Diese Einstufung sollte nochmals überprüft werden und sehr binär reagiert werden. Entweder wird ein solcher Punkt noch innerhalb der Phase umgesetzt oder als „Won’t“ gestrichen.

Fertig

Fällt euch noch etwas ein, was derlei Register benutzungsfreundlicher macht? Nur her damit. Einen Beispiel Action-Tracker im OpenDocument Format findet ihr hier und als Excel hier.

Gute Projektmitarbeiter, schlechte Projektmitarbeiter

Zu Anfang meiner beruflichen Laufbahn herrschte eine der IT-Blasen. Personalvermittler telefonierten die Büros der wissenschaftlichen Mitarbeiter an der Universität ab. Freunde und Bekannte versuchten sich die Anwerbeprämien zu verdienen, in dem Sie geradezu verzweifelt ihren Bekanntenkreis nach Informatikern absuchten. Unter den reichlichen Anfragen war auch ein großer Elektronikkonzern. Dessen Personalabteilung sehr selbstbewusst ein Einstiegsgehalt offerierte, das nicht viel über dem Gehalt des öffentlichen Dienstes lag. Als Begründung führte man diverse Punkte an; im Übrigen könne man die Arbeit als wissenschaftlicher Mitarbeiter nicht als Berufserfahrung anrechnen. Mit dieser Meinung lagen sie so falsch.

In einer Projektarbeit oder einem Seminar teilt sich die Studierenschaft grob in zwei Teile: „Gute Projektmitarbeiter, schlechte Projektmitarbeiter“ weiterlesen

Was hat der Change im Service Desk zu suchen?

In ITIL® Version 2 gab es nur eine Funktion(seinheit) das war der Service Desk. In der aktuellen ITIL Version 3 sind es vier definierte Funktionen, die sich Teile von Prozessen schnappen und dort für diverse Aktivitäten zuständig sind. Die genaue Zuordnung bleibt der Organisation überlassen, denn meiner Meinung nach ist eine Funktion in ITIL ohnehin nur eine Erklärungshilfe für die Abbildung von Prozessen in das echte Leben einer Organisation.

Der Service Desk als die älteste Funktion hat nun schon eine ganz ansehnliche Historie und kann auf viele Implementierungen zurückblicken. Dabei haben sich typische Szenarien ausgebildet. Der typische Service Desk, falls es das überhaupt gibt, sagen wir mal der „durchschnittliche“ Service Desk übernimmt dabei folgende Prozessanteile: „Was hat der Change im Service Desk zu suchen?“ weiterlesen

Projekte scheitern an nichtssagendem Papier

Teil #3 aus Gründe warum Projekte scheitern

Ein in der Literatur gerne diskutierter Punkt ist, dass Projekte scheitern weil sie zu bürokratisch sind und zu viel Papier produzieren. Es ist schon sehr ärgerlich sich durch Dokumentenberge zu kämpfen, die jeweils mit 4 Seiten Impressum, Glossar, Historie und Dokumentssteuerung beginnen und auf den weiteren Seiten auch nur allgemeines Blahfasel enthalten. Das Problem sind hier nicht die Mengen an Papier, sondern meist liegt die Ursache am Umgang mit dem Thema Verantwortung. Es gibt Konstellationen da sind die Teil-Projektleiter Techniker und der Projektleiter eine Art Aufpasser. Demnach muss der Projektleiter nur für seine Existenzberechtigung sorgen, vom Projektgeschehen hat er keine Ahnung. Also kann nur unnützes Zeugs herauskommen. De facto lenkt jedoch niemand das Projekt in die richtige Richtung.

„Projekte scheitern an nichtssagendem Papier“ weiterlesen

Projekte scheitern an vermiedener Kommunikation

Teil #2 aus Gründe warum Projekte scheitern

Beim Kapitel Kommunikation im Projektmanagement wird gerne über interkulturelle Hürden und ähnliches gesprochen. Probleme in der Kommunikation sind tatsächlich ein wichtiger Faktor in der Welt der gescheiterten Projekte. Das man im Chinesischen nie direkt zur Sache kommt, ist aber eher ein Nebeneffekt, der gut vorhersehbar, planbar und lösbar ist. Viel interessanter ist Kommunikation die gezielt vermieden wird. Beispiel: Ein Lieferant lässt in seinem Angebot bewusst notwendige Bestandteile weg, um den Preis attraktiv erscheinen zu lassen. Selbstverständlich wird sich das im Projekt (und hoffentlich auch sonst) rächen. Dem Projekt wird dabei mehr Schaden zugefügt, als nur die Zusatzausgaben für die fehlenden Elemente. Der Lieferant wird mit Nebelkerzen werfen und versuchen die Schuld auf Andere zu lenken. Das frisst eine Menge Zeit, Nerven und Geld. Dies im Vorfeld heraus zu bekommen, ist nahezu unmöglich. Das Projektteam muss dazu einen sehr hohen technischen Sachverstand haben, immerhin mehr Know-How als das Pre-Sales-Team. Wieder mal ein Grund für auch technisch bewanderte Project Boards und Projektleiter. „Projekte scheitern an vermiedener Kommunikation“ weiterlesen