Auf ein Wort – Verfahrensbeschreibungen in objectiF RPM

by | 18.10.2021 | objectiF RPM anwenden

Immer ist irgendetwas anders: Ich kenne keine zwei Organisationen, in denen Requirements Engineering, Projektmanagement, Änderungsmanagement, QS, Testmanagement etc. identisch ablaufen. Manchmal sind es nur „Kleinigkeiten“, zum Beispiel ein paar besondere Attribute, mit denen Anforderungen, User Stories, Testfälle oder andere Ergebnisse beschrieben werden. Oft aber reichen die Unterschiede bis hin zu speziellen Rollen, Aktivitäten und Workflows. Meistens haben sie ihren Ursprung in branchenspezifischen Normen und Standards. Wenn Ihre Organisation speziellen Regulierungen unterliegt, können Sie objectiF RPM entsprechend anpassen und sogar erweitern.

Aber: Wenn Sie aus fachlicher Sicht dafür verantwortlich sind, also objectiF RPM in Ihrer Organisation in Hinsicht auf die unterstützten Prozesse administrieren, wie tragen Sie das Wissen über Ihre Anpassungen in die Projekte?

Bevor ich Ihnen dazu einige Möglichkeiten aufzeige,

  • gebe ich Ihnen einen Überblick, was Sie anpassen bzw. wie Sie objectiF RPM erweitern können,
  • beschreibe ich den Weg, auf dem Ihre Änderungen und Anpassungen in die Projekte Ihrer Organisation gelangen.

Die Top 7+1 Möglichkeiten zum Anpassen und Erweitern von objectiF RPM

Die Möglichkeiten, objectiF RPM auf Ihre Organisation zuzuschneiden, sind vielfältig. Die aus meiner Sicht wichtigsten Möglichkeiten – meine Top 7 – habe ich in einer Tabelle zusammengefasst.

Tabelle mit Anpassungsmöglichkeiten von objectiF RPM

Abb. 1: 7+1 Möglichkeiten, um objectiF RPM auf eine Organisation zuzuschneiden

Sie haben es vielleicht bemerkt: Die Tabelle hat acht Zeilen. Was hat es mit der achten Zeile auf sich? Wenn die gegebene Funktionalität von objectiF RPM für einen speziellen Zweck nicht ausreicht, können Sie skriptbasiert eigene Features entwickeln (lassen) und damit objectiF RPM funktional erweitern. Insbesondere lassen sich per Skript Schnittstellen zu anderen Werkzeugen realisieren. Ein typisches Beispiel dafür ist die Anbindung von Testwerkzeugen an objectiF RPM.

Diese Option gehört im engeren Sinne sicher nicht zur fachlichen Administration von objectiF RPM, ist aber ein sehr mächtiges Instrument, wenn es darum geht, objectiF RPM optimal an eine Organisation anzupassen.

So kommen Ihre Anpassungen und Erweiterungen in die Projekte mit objectiF RPM

Projekte – übrigens auch Programme und Portfolios – werden in objectiF RPM mithilfe von Vorlagen aufgesetzt. Per Projektvorlage wird die Struktur erzeugt, in der die Projektergebnisse später abgelegt werden. Es wird üblicherweise auch ein initialer Projektplan mit den wichtigsten Aktivitäten, Meilensteinen und Kontrollflüssen angelegt. Eine Projektvorlage kann außerdem Ergebnistypen mit passenden Formularen, Workflows, Abfragen und Charts, Dokumente, Planungs- sowie Strukturmuster und vieles mehr mitbringen. Was genau, das liegt in Ihrer Entscheidung, wenn Sie für die Prozessgestaltung und -administration zuständig sind.

Bringen wir es auf den Punkt: Projektvorlagen sind in objectiF RPM der Schlüssel zu standardisiertem Vorgehen, einheitlicher (Prozess-)Qualität und kontinuierlicher Prozessverbesserung.

Prozessadministration in der Organisationseinheit in objectiF RPM

Abb. 2: So kommen die Vorgaben der Prozessadministration in die Projekte mit objectiF RPM

Auch wenn Projekte per Vorlage aufgesetzt werden, bleibt den Projektverantwortlichen aber immer noch der Spielraum, projektspezifische Anpassungen vorzunehmen. Ob diese Anpassungen sinnvoll und hilfreich für die Arbeit der Projektmitarbeitenden sind, hängt u.a. davon ab, wie gut die Projektverantwortlichen Sinn, Zweck und Inhalt der Vorlage verstanden haben.

So unterstützen Sie projektspezifische Anpassungen

Deshalb lautet meine Empfehlung: Dokumentieren Sie als Prozessadministrator/in die zentralen Elemente Ihrer Vorlagen. Hier sind einige der wichtigsten Stellen, an denen Sie den Projektverantwortlichen und -mitarbeitenden mit Erklärungen helfen können.

Den Zweck der Vorlage beschreiben

Projekte können sich in vielerlei Hinsicht unterscheiden, z.B. im Projektmanagement-Ansatz (agil, hybrid, klassisch), im Projektgegenstand (reine IT-Projekte, Investitions- und Forschungsvorhaben, Organisationsprojekt, Infrastrukturprojekt, …), in den einzuhaltenden Normen und Standards, in der Auftragsart (externe/interne Projekte, Auftraggeber-/Auftragnehmer-Projekte, …) oder ganz einfach in ihrer Größe. Deshalb entstehen in Organisationen, die mit objectiF RPM arbeiten, nach und nach mehrere Projektvorlagen. Welche Vorlage verwende ich am besten für mein Projekt? Um den Projektverantwortlichen bei der Beantwortung dieser Frage zu helfen, sollten Sie alle Vorlagen nach einem einheitlichen Schema beschreiben. Dazu öffnen Sie im Backstage-Menü der Vorlage mit Projekt/Eigenschaften den entsprechenden Dialog und geben unter Beschreibung Ihre Erläuterungen ein.

Vorlage für Automotive Projekte in objectiF RPM erstellen

Abb. 3: So legen Sie eine Beschreibung für eine Projektvorlage an

Wer ein Projekt anlegen will, kann sich sehr schnell über den Inhalt der verfügbaren Vorlagen informieren. Einfach in der Userboard-Ansicht das i-Icon auf der Kachel einer Vorlage mit der Maus berühren und die Beschreibung wird angezeigt.

Vorlagenbeschreibung im User Board von objectiF RPM

Abb. 4: Auf dem Userboard mit der Maus auf das i-Icon fahren und die Beschreibung der Projektvorlage erscheint in Form eines Tool-Tipps

Benutzerdefinierte Eigenschaften (Attribute) beschreiben

Wenn Sie in einer Projektvorlage zu Ihren eigenen oder den von objectiF RPM mitgebrachten Ergebnistypen eine neue Eigenschaft definieren, so nennen wir diesen Vorgang Attributieren. (Das Thema des Attributierens von Requirements Engineering Artefakten habe ich in einem früheren Beitrag an einem Beispiel ausführlich behandelt. Auf das Beispiel greife ich übrigens in den nachfolgenden Abbildungen zurück.)

Angenommen Sie haben von der Möglichkeit des Attributierens Gebrauch gemacht. D.h. Sie haben –­ im Sprachgebrauch von objectiF RPM – im Stereotypen-Browser

  • ein neues Artefakt mit einigen Eigenschaften angelegt
  • oder einen vorhandenen Stereotyp spezialisiert und für die Spezialisierung benutzerdefinierte Eigenschaften festgelegt
  • oder einen vorhandenen Stereotyp um benutzerdefinierte Eigenschaften ergänzt.

Nehmen wir weiter an, dass auf der Grundlage Ihrer Vorlage ein neues Projekt aufgesetzt wird. In diesem Projekt gibt es Bedarf für spezifische Formulare und Abfragen, die sich auf Ihr neues Artefakt oder einen der erweiterten Stereotypen beziehen. Machen Sie es dem Projektadministrator bzw. der Administratorin beim Formulardesign und der Definition der benötigten Abfragen leicht. Sorgen Sie schon beim Erstellen der Vorlage dafür, dass auf einen Blick klar wird, was mit den benutzerdefinierten Eigenschaften gemeint ist, die Sie festgelegt haben. Geben Sie zu jeder benutzerdefinierten Eigenschaft eine kurze Beschreibung ein. Sie wird beim Formulardesign und der Definition von Abfragen als Tool-Tipp verwendet. Beim Formulardesign sieht das dann zum Beispiel so aus:

Eigenschaften des Stereotpys Functional Requirement

Abb. 5: Im Automotive-Sektor ist „ASIL“ eine typische Eigenschaft von funktionalen Anforderungen. Wenn Sie sie in die Projektvorlage als benutzerdefinierte Eigenschaft von funktionalen Anforderungen aufnehmen, ist es sinnvoll, eine kurze Erklärung dazu einzugeben: Einfach die Eigenschaft markieren und auf das i-Icon klicken. Das Beschreibungsfeld wird geöffnet.

Formulardesigner in objectiF RPM

Abb. 6: Wechseln wir nun in ein Projekt, das mit der Projektvorlage eingerichtet wurde. Hier soll ein projektspezifisches Formular erstellt werden. Beim Anlegen werden alle verfügbaren Eigenschaften – inklusive der benutzerdefinierten – angeboten. Zur besseren Orientierung wird die Beschreibung der benutzerdefinierten Eigenschaften als Tool-Tipp angezeigt.

Muster beschreiben

Muster sind in objectiF RPM das Instrument, um in einheitlicher Weise und mit nur wenigen Klicks u.a.

  • Projekte zu strukturieren,
  • die Arbeitsumgebungen für die Projektteams einzurichten,
  • Projekte zu planen und die Planung fortzuschreiben,
  • alles, was für spezielle Prozessgebiete notwendig ist (z.B. für Risiko- oder Änderungsmanagement), anzulegen
  • die Ordnerstrukturen für die Verwaltung von Ergebnissen zu erzeugen,
  • Elemente wie Kanban-Boards, Backlogs, Burn-Up Charts, Cumulative Flow Diagrams, Übersichten der Mitarbeiterauslastung, Instrumente der Earned Value Analyse, Gantt Charts, hierarchische Auswertungen, Dokumente, Konfigurationen und vieles mehr anzulegen.

Muster sparen nicht nur Zeit. Sie können insbesondere eingesetzt werden, um die spezifischen Normen und Standards einer Branche (wie z.B. Automotive SPICE in der Automobilindustrie) einzuhalten. Kurzum: Muster haben in Projektvorlagen einen besonders hohen Stellenwert.

Angelegt und verwaltet werden Muster in einem vorbereiteten Musterkatalog. Mein Rat: Wenn Sie eigene Muster definieren, sollten Sie sie nach einem festen Schema beschreiben. Was gehört in eine Musterbeschreibung? Orientierung bieten Ihnen die in objectiF RPM bereits vorhandenen Muster.

Muster beschreiben in objectiF RPM

Abb. 7: Da mit einem Muster komplexe Strukturen eingerichtet und zahlreiche Ergebnisse sowie Beziehungen zwischen ihnen mit wenigen Klicks erzeugt werden können, ist eine ausführliche Beschreibung unverzichtbar.

Leitfaden erstellen

Richtlinien zur Durchführung von Projekten, Prozesshandbücher, Projektstandards – vermutlich gibt es so etwas auch in Ihrer Organisation, oft eingegeben in ein Wiki, manchmal gespeichert als PDF oder abgelegt als Papier im Regal. Wenn Sie Ihre Prozesse und Vorgehensweisen in objectiF RPM in Projektvorlagen abbilden, dann gehört dazu auch immer eine Beschreibung – nicht irgendwo im Universum, sondern direkt in der jeweiligen Vorlage. Beim Anlegen eines Projekts auf Basis einer Vorlage wird der Leitfaden automatisch in das Projekt übernommen.

Wenn Sie Ihre eigenen Projektvorlagen auf der Basis der Vorlagen entwickeln, die objectiF RPM mitbringt, dann finden Sie darin bereits einen Leitfaden vor. Mein Vorschlag ist: Machen Sie ihn zu Ihrem Leitfaden, indem Sie ihn einfach überschreiben. Denn genau dafür ist er gedacht. Zum Editieren klicken Sie im Backstage-Menü der Projektvorlage auf Projekt/Leitfaden bearbeiten.

Leitfaden bearbeiten in objectiF RPM

Abb. 8: So wird der Leitfaden zum Editieren aufgerufen

Wie Sie den Leitfaden gliedern, hängt von Gegenstand und Scope Ihrer Projektvorlage ab. Mögliche Gliederungspunkte sind:

  • Einleitung: Für wen ist der Leitfaden gedacht? Welchem Zweck dient er? Was erwartet den Leser? Wie und warum ist der Leitfaden entstanden? Wer sind die Autoren und Autorinnen?
  • Überblick: Für welche Arten von Projekten ist die Vorlage geeignet? Welche grundlegenden Annahmen stecken in der Vorlage z.B. über die Projektgröße, Anzahl der Teams, Kosten, den Projektmanagementansatz (agil, hybrid, klassisch) etc.? Wie sieht das zugrunde liegende Rollenmodell aus und wie die grobe Projektstruktur?
  • Anwendung der Vorlage: Was ist zu tun, nachdem ein Projekt mit der Vorlage aufgesetzt wurde (ggf. in Form einer Checkliste)?
  • Von der Vorlage erzeugte Elemente im Detail: Projektgliederung, Ordnerhierarchie für die Projektergebnisse, Ergebnistypen und Formulare, Workflows, Abfragen und Charts, Dokumentvorlagen und Dokumente, Planungs- und Strukturmuster etc.
  • Regeln für das Arbeiten in Projekten, die mit der Vorlage erzeugt wurden: Dazu gehört u.a.: Wie laufen die Projektplanung und Steuerung ab? Welche Elemente stehen für das Controlling zur Verfügung? Was ist beim Versions- und Konfigurationsmanagement zu beachten? Welche Workflows gibt es für die QS?

Diese Aufzählung ist sicher nicht vollständig.

Noch eine Empfehlung: Legen Sie auch Beispiele in der Vorlage an und referenzieren Sie sie im Leitfaden, um die Darstellung anschaulicher zu machen. Sie können außerdem externe Links einfügen, um Ihre Beschreibung zu ergänzen.

Und die Arbeit lohnt sich: Da der Leitfaden beim Anlegen eines Projekts per Vorlage automatisch in das Projekt übernommen wird, steht er jedem Projektmitarbeitenden als Informationsquelle zur Verfügung. Und natürlich kann er im Projekt nach Bedarf um die projektspezifischen „Spielregeln“ ergänzt werden, z.B. für Meetings oder Videokonferenzen. Auch die Beschreibung von empfohlenen Arbeitstechniken u.a. zum Beispiel für die Entwicklung einer Produktvision, für die Stakeholder-Kommunikation, die Anforderungsanalyse, die Aufwandsschätzung oder generell für die Kollaboration.

Ein Tipp zum Schluss

Jede Branche hat ihre eigene fachliche Sprache. Speziell in Hinsicht auf die Stakeholder-Kommunikation sowie die Qualität von Anforderungen und Lösungen, sollten alle Projektmitarbeitenden das gleiche Verständnis von den gängigen Fachbegriffen besitzen. Bei der Entwicklung einer Projektvorlage können Sie einen wesentlichen Beitrag dazu leisten: Legen Sie in der Vorlage ein Glossar an. Klar, auch das macht Arbeit. Aber sie lohnt sich. Denn das Glossar liegt nicht irgendwo in einem Wiki, sondern direkt in jedem Projekt für alle Mitarbeitenden mit einem Klick zugänglich. Beim Anlegen von Projekten per Vorlage wird auch das Glossar in die Projekte übernommen.

Sie kennen objectiF RPM noch nicht? Nutzen Sie es doch einfach einmal 30 Tage kostenlos. Hier geht es zum Download.