OPL/Offene-Punkte-Liste

Die Offene-Punkte-Liste ("OPL") hat das Ziel klar und einfach verständlich aufzuzeigen, welche Arbeiten noch zu erledigen sind, bevor das Projekt abgeschlossen werden kann. Die Liste kann von Projektbeginn an geführt werden, ich empfehle aufgrund persönlicher Erfahrungen aber eine Erstellung zum Abschluss des Projektes quasi als "last step to go" zum Projektabschluss.

Die OPL bringt Klarheit über die noch zu erledigenden Aufgaben, Steigerung der Abschluss-Produktivität, dient als Hilfe bei der Priorisierung und vermeidet Mehrarbeit durch Nacharbeiten bei protokollbasierten Auflistungen durch das Zusammenfassen aller Punkte in einer Datei bereits während Meetings und Abnahmen.

Im ersten Schritt hin zu Offenen-Punkte-Liste müssen noch offene Arbeiten "aufgespürt" werden. Diese können über den Projektplan (alles was nicht 100% erledigt ist), durch Meetings ("wir müssten noch..."), aus dem Qualitätsplan (Stichwort "Nacharbeiten") oder aus geführten Abnahmeprozessen (abschließende Tests, Begehungen, ...) herausgefunden werden.

Nach der Sammlung von Einträgen sind die Aufgaben zu kategorisieren, sinnvoll zu bündeln und an das Team zu verteilen. Dabei hilft eine klare Verantwortlichkeit (wer), Deadline (bis wann) und Aufgabenstellung nach Art und Weise eines Arbeitspaketes (was). So ergibt sich eine Übersicht über noch offene Punkte sowie verbindliche Aussagen über "wer mach was bis wann".

Ziel der Offenen-Punkte-Liste (oder kurz "OPL" auch aus dem Englischen: "open point list") ist es, aufzuzeigen, welche Punkte (Arbeitspakete, Aufgaben, Qualitätssicherungsmaßnahmen, Abnahmen) noch offen sind, bevor das Projekt endgültig abgeschlossen werden kann. Weiterhin können anhand der Liste weitere Planungen wie Zuständigkeiten/Ressourcen oder Zeit und Kosten der noch zu erledigenden Arbeiten abgeschätzt werden. Ist die OPL ganzheitlich abgehakt, ist das Projekt, was Arbeitspakete anbelangt, beendet.

​

Weiterhin dient die von der Projektleitung angefertigte Offene-Punkte-Liste als Kommunikationsinstrument für Besprechungen intern mit Projektbeteiligten sowie externen Stakeholdern um aufzuzeigen, welche Arbeiten abschließend noch zu koordinieren sind.

Beispiel: die Bauabnahme eines Neubau-Hauses und die im Abnahmeprotokoll vermerkten Arbeiten und Nachbesserungen ist eine Abnahme mit Offene-Punkte-Liste. Die Dinge auf dieser Liste (Protokoll) müssen erledigt werden, bevor das Projekt für den Bauträger beendet werden kann.

Die Liste der offenen Punkte bringt einen schnellen Überblick über offene Arbeiten.

Status: Offen, in Arbeit oder Erledigt? Gerade mit Excel-Filtern können Kategorien und Status exakt eingegrenzt werden. In der OPL erhält man auf einem Blick eine Übersicht über den aktuellen Aufgaben-Stand.

OPL-Einträge erhöhen die Verbindlichkeit hin zum Projektabschluss.

Ein Eintrag der zu Projektende offen ist signalisiert dem Projektteam, das das Projekt kurz vor Abschluss noch Gefahr läuft nicht ordnungsgemäß vollendet zu werden. Zur Unterstreichung wird jedem OPL-Eintrag ein Verantwortlicher zugewiesen, welche die Erledigung oder Behebung zu verantworten hat.

Die Offene-Punkte-Liste dient als Kommunikationsinstrument.

Gegenüber dem Projektteam und Stakeholdern kann angezeigt werden, wer was bis wann zu erledigen hat.

Die OPL erleichtert das Schätzen des Rest-Projektes.

Durch die Auflistung der noch zu erledigenden Arbeiten können Zeit und ggf. Kosten bis Projektabschluss genauer beziffert werden.

Die Offene-Punkte-Liste (englisch open point list) oder auch "Liste offener Punkte" sowie "OPL" abgekürzt ist eine Übersicht der noch zu erledigenden Aufgaben bis zur Erreichung des Projektzieles.

Innerhalb der Liste beinhaltet jeder Eintrag spezifische Informationen über Art, Umfang und Verantwortlichkeit der noch offenen Arbeit.

Die OPL ergibt sich aus zweierlei Arbeitsbereichen:

• Offene Arbeiten laut Projektplan
• Offene Arbeiten laut Abnahme und Qualitätsmanagement

Im dritten und extra nicht mit aufgenommenen können auch "Nachbesserung aus Kundenwünschen" aufgenommen werden. Da diese aber aus neuen Anforderungen des Auftraggebers hervorgehen, gehören Sie in einer engeren Eingrenzung nicht zum vorher definierten Projekt und daher auch eigentlich nicht in die OPL.

Im ersten Fall "Offene Arbeiten laut Projektplan" sind schlichtweg abschließende Arbeiten nicht erledigt, welche von vorn herein geplant gewesen sind. In der Software-Entwicklung fehlen Beispielsweise Testergebnisse eines spezifischen Tests oder im Hausbau fehlt die Inbetriebnahme der Heizung. Diese offenen Arbeiten werden als einzelne Einträge aufgenommen.

Der zweite Punkt "Offene Arbeiten laut Abnahmeplan und Qualitätsmanagement" ist weit kritischer zu sehen, da hier Zeit- und Kostenfaktoren eintreten, welche nicht eingeplant waren. In der Softwareentwicklung Fehler welche Funktionen beeinträchtigen oder beim Hausbau die Beschädigung von Heizkörpern. Im großen Stil aber auch eine Brandschutzanlage an einem Flughafen. Diese Einträge sind Fehler welche gemacht wurden und zum Projektabschluss noch gerichtet werden müssen.

Dabei erhält jeder Listeneintrag in der Offenen-Punkte-Liste spezifische Attribute zugewiesen, meist aufgeteilt in Spalten:

• ID - eine spezifische Nummer des Eintrages. Ggf. auch eine Arbeitspaket-Referenz, wenn dieses aus der Benennung hervorgeht.
• Erstellung/Datum der Aufnahme - wann wurde der Eintrag bemerkt?
• Dringlichkeit/Priorität - Muss der Eintrag ggf. vor anderen dringender erledigt werden?
• Auswirkung - Wie kritisch ist der Eintrag zu sehen?
• Stichwort/Tag - Attribute zur Sortierung und Filterung, z.B. "Technik", "Brandschutz", "Trockenbau".
• Offener Punkt - Was muss noch gemacht werden? Als Zielformulierung, nicht als vages Verb wie "Untersuchen".
• Notwendige Abhängigkeiten - werden z.B. Materialien neu benötigt finden diese hier ihren Platz.
• Bis wann - Deadline zur Erledigung.
• Status - Offen, in Arbeit, erledigt
• Verantwortlich - Wer übernimmt die Erledigung?

Wie Sie sehen gehen aus dieser Liste eine Menge Informationen und Verbindlichkeiten aus. Je nach Projektumfang können einzelne Unterpunkte die Liste noch ergänzen um effizientere Entscheidungen zu treffen. So können z.B. Einträge welche Entscheidungen benötigen kategorisiert und zusammengefasst werden, um diese innerhalb eines Meetings zu treffen.

Eine mögliche Verfeinerung durch eine Spalte "Kategorie" könnten sein:

• Information: Wem fehlen wo welche Informationen? Wer braucht welchen Bericht oder welches Wissen?
• Beschluss: Was muss mit dem Team, Stakeholdern, Dritten noch besprochen werden?
• Problem: Wo hängt es? Was ist passiert? Was muss erledigt werden um das Problem zu lösen?
• Frage: Was kann derzeit nicht beantwortet werden und/oder wartet auf Feedback von extern?
• Sonstiges

Abgrenzung zur To-Do-Liste:

Der Begriff "Offene Punkte Liste" ist sehr unterschiedlich interpretiert. Manchmal wird empfohlen die OPL bereits ab Projektbeginn mitzuführen, was für mich persönlich aber zu "klein" wäre, da es für mich parallel zum Projekt- und Abnahmeplan läuft. Andere benutzen Begriffe wie "Abnahmeprotokoll" in Angrenzung an die sich ergebenen Arbeiten der einzelnen Einträge.

Daher kann es sein, dass Sie anderweitige Informationen zur OPL erhalten, die eher einer To-Do-Liste gleichen, als abschließenden offenen Punkten. Für mich persönlich hat sich eine OPL wie hier erklärt jedoch als optimal in meinen Projektumgebungen herausgestellt.

Organisationsintern sollte der Begriff "Offener Punkt" mindestens an übergeordneter Stelle, wie einem Projekthandbuch, klar definiert sein.

"Offener Punkt" nach PRINCE2:

Offene Punkte, oder im englischen Original nach PRINCE2 "issue", definieren zentrale Steuerelemente, welche durch jeden Projektbeteiligten hervorgebracht werden können. Diese enge Definition macht den Begriff zwar für fest definierte Managementprozesse handhabbar, lässt allerdings eine Steuerung von einzelnen offenen Punkten kaum zu, was z.B. das Belegen mit einem Status oder Verantwortlichkeiten zur Ausführung angeht. Die von Mitarbeitern gemeldeten issues werden durch den Projektmanager aufgenommen und im übersetzten "Register der offenen Punkte" festgehalten. Issues werden dabei unterteilt in die Kategorien "Allgemeine offene Punkte" (wie Fragen, Bedenken, Einwürfe), "Meldungen zur Spezifikationsabweichungen" oder "Änderungsanträge".

"Offener Punkt" laut PMBOK (R) Guide:

In wörtlicher Übersetzung entspricht ein offener Punkt einem "Problem", wobei die Sinnhaftigkeit der Übersetzung allerdings nicht dem Kontext im PMBOK (R) Guide entspricht. Frei übersetzt eher eher eine "Angelegenheit, die noch nicht entschieden/unklar ist". Das "Issue Log" in welchem die offenen Punkte dokumentiert werden, zeigen Punkte, bei welchen Entscheidungsbedarf besteht.

Die Durchführung ist relativ simpel und kann bei guter Zeitplanung innerhalb eines Tages erledigt werden. Zur Erinnerung: Der Output ist eine Liste mit Einträgen (offenen Punkten) die bestimmten Kleinstziele (wie Abnahmekriterien) beinhalten, welche noch zu erledigen sind, bevor das Projekt abgeschlossen werden kann.

Diese können sich ergeben aus:

a) Projektplan und Meetings sowie
b) Aus Abnahme und Qualitätsplan

a) Offene Punkte aus Projektplan und Meetings

Zu Beginn ist der Projektplan durchzugehen und noch nicht als 100% erledigt gekennzeichnete Arbeitspakete herauszufiltern und die zu erledigenden Arbeiten als einzelne Einträge zu übernehmen. Weiterhin können je nach noch vorhandenen Ressourcen (Zeit, Geld) Wege zu optionalen Zielen, sofern jetzt noch sinnvoll, mit aufgenommen werden.

Weiterhin kann in einem Workshop oder einer Besprechung mit Teammitgliedern und Stakeholdern der bisherige Projektverlauf besprochen werden. Alle "das müsste noch gemacht werden"-Punkte können aufgenommen werden. Achten Sie jedoch darauf, dass es hier nicht um Projekt-Erweiterungen oder Änderungen a lá "Eigentlich könnten wir noch..." geht, sondern um Arbeiten des aktuellen Projekts.

b) Offene Punkte aus Abnahme und Qualitätsplan

Im zweiten Schritt wälzen Sie ihr Qualitäts-Log: Gibt es Einträge, welche nicht erfüllt sind? Haben Sie Nacharbeiten vermerkt? Weiterhin können Sie bestimmte Abnahme-Prozesse initiieren, um Nacharbeiten aufzudecken. Bei Software-Entwicklungen wären das abschließende Tests, beim Hausbau die Begehung. Alle Punkte die sich ergeben, kommen als einzelnen Eintrag in die OPL.

Die OPL ist nun Arbeitsmittel Nummer eins hin zum Abschluss des Projektes. Initiieren Sie nötige Besprechungen. Bündeln Sie offene Beschlüsse oder Absprachen zu zielführenden kurzen Meetings. Verteilen Sie die neuen Arbeiten an Mitarbeiter im Team, setzen Sie eine Deadline und tragen Sie Verantwortlichkeit und Datum der Deadline in die OPL ein.

Beginnen Sie mit Einträgen die als "Dringen" gekennzeichnet sind und/oder den größten Impact zur Zielerreichung beisteuern. Fordern Sie Rückmeldungen ein.

​(folgt)

• Klarheit & Übersicht: Was ist noch zu erledigen, damit das Projekt abgeschlossen werden kann?
• Zusammenfassung von Quick-Win's: Mehrere kleinere Nacharbeiten können zu einem Arbeitspaket zusammengefasst werden, welches dann zeitnah durchgeführt wird.
• Steigerung der Produktivität: Das Projektziel, wo mehrere Monate dran gearbeitet wurde, ist zum Greifen nah. Der Ansporn die Punkte endgültig abhaken zu können steigt.
• Entlastung der Organisation & Psyche: Es gibt eine strukturierte Liste mit allen offenen Punkten, nicht zig Baustellen in den Köpfen der Projektmitglieder.
• Verbesserter Zugriff auf dokumentierbare Fortschritte: Im Gegensatz zur Arbeit mit Protokollen, sind alle Punkte in einer Liste gespeichert, welche sich sortieren und gliedern lässt. So können Fortschritte schnell sichtbar gemacht werden.
• Mehrarbeit wird vermieden: Die OPL wird während des Meetings geschrieben oder durch copy & paste aus offenen Abnahmepunkten der Arbeitspakete erstellt. Es müssen keine Protokolle oder Listen nach Besprechungen nochmals zusammengefasst und neu gegliedert werden.

Alles wird in eine Liste gepackt
Führt leicht zur Unübersichtlichkeit. Sinnvoller ist es z.B Teilprojekte oder Phasen in mehrere Tabellenblätter einer Datei aufzusplitten. Die Reiter/Blätter Phasen aus denen alle Nacharbeiten erledigt sind können beispielsweise grün hinterlegt werden um einen vollständigen Abschluss zu signalisieren.

Es werden keine präzisen Ziele formuliert, sondern unspezifische Verben

In der Beschreibung sollten Ziele stehen. "Was ist zu erreichen?" als globale Fragestellung der Beschreibung. unspezifische Verben wie "angucken", "klären", "untersuchen" sind zu vermeiden. Nutzen Sie eindeutig formulierte Ziele die zu erreichen (zu erledigen) sind.

Es wird nach Schuldigen gesucht
Häufen sich Qualitätsmängel in bestimmten Bereichen ist häufig die Schuldfrage im Raum. Dieser negative Blick auf die Arbeitsleistung schüchtert ein und führt in der Regel nicht zu besseren Ergebnissen. Stattdessen sollten die Probleme innerhalb des Lessons Learned Workshops aufgearbeitet werden, so dass diese in Zukunft nicht mehr auftreten.

Es wird nicht kategorisiert

Durch das Bündeln von Einträgen bestimmter Kategorien können Arbeiten zusammengefasst werden. Alle Einträge mit "Beschluss" können beispielsweise innerhalb weniger Meetings besprochen werden, anstatt für jeden Punkt eine Mail zu verfassen. Auch kleine Nachbesserungen in bestimmten Bereichen können gebündelt und effektiver an einzelne Verantwortliche zur Ausführung übergeben werden.

Es wird keine Verantwortlichkeit und Deadline gesetzt
Die Einträge sind vorhanden und werden dem Team zur Erledigung übergeben, ohne eine Verantwortlichkeit und Deadline bleiben die Aufgaben meistens liegen, das Tagesgeschäft geht vor. Hier gilt es als Projektleiter feste Kriterien zu setzen, wer was bis wann erledigt.

Die Liste genießt nicht oberste Priorität

Zur Erinnerung: Nur abgeschlossene Projekte bringen einen Nutzen. Diese Punkte sind noch zu erledigen, bis das Projekt abgeschlossen ist. Die Liste sollte nun Grundlage und erster Punkt auf der Agenda bei jeder Besprechung sein.

​(folgt)