Qualitätskosten in Projekten bis zu 30% senken

Qualitätskosten in Projekten bis zu 30% senken

24. Oktober 2021 Projekt Entwicklung 0
Qualität und Einschränkungen

Die Boeing 737 MAX 8 ist ein klassisches Beispiel für ausufernde Qualitätskosten.
Das Dieselgate muss man auch nicht weiter ausführen. Das Desaster mit dem VW ID.3 (Verzögerte Auslieferung und Task Force) gehört auch dazu. Die Liste ist – mehr als lang.
Das „magische Dreieck“ – Zeit, Qualität und Kosten wird immer wieder angesprochen. Da denkt man, dass es durch „Agilität“ besser wird, die Erfahrung stützt diese Theorie bis heute nicht.

Absturz

Ausgangssituation

Die klassische Ausgangssituation in fast jedem Projekt heutzutage ist:

  1. Unklare Anforderungen und
  2. Eine unstrukturierte Projektsituation
  3. Unzureichendes Budget
  4. Unzufriedenstellenden Beifügung von Neben-/Hauptanforderungen des Kunden in Richtung Kommunikation oder Homologation
  5. Sich widersprechende oder
  6. Völlig unangemessene Beifügung von mitgeltenden Unterlagen. (Ein Satz hätte gereicht, aber 120 Seiten gesendet)

Die Projektmanager Aufgaben bestehen oftmals darin die Entwicklungskosten, speziell die Qualitätskosten der Entwicklung zu minimieren. Die Folgekosten schlechter Qualität (schlechte Entwicklungsqualität, Task Force Management, Rückrufe, Reparaturen etc.), welche sich aus der daraus resultierenden Entwicklungsqualität ergeben, werden gerne ausgeblendet.

Image by Steve Buissinne from Pixabay

Werkzeuge des PM

Dabei hat der Projektmanager alle Werkzeuge in der Hand, damit er die Qualitätskosten reduzieren kann. Ebenso kann er, sofern es nicht das erste Projekt in dem Umfeld ist, die tatsächlichen Kosten sachlich begründen.

Wir gehen im Folgenden auf die Studienergebnisse des PMI für Projektversagen ein und koppeln diese mit den klassischen Themen des Projektmanagements, zeigen Ihnen wo hier Qualitätsthemen liegen, wie Sie diese identifizieren und wie Sie sicherstellen „auf Kurs zu bleiben“.

Die Automotive SPICE® PAM (Prozess Assessment Modell) 3.1 oder die Medical SPICE® (VDI 5702) kann man als „Bremse“ ansehen oder man sieht Sie als kondensiertes Wissen an, welches einem helfen kann, die Entwicklung zu optimieren und unnötige Kosten zu vermeiden.

Oftmals lassen sich aufgrund von inneren Zwängen und äußeren Einflüssen, nicht immer klar Wege beibehalten, die man eigentlich gehen müsste. Wir bleiben hier mal ganz bewusst im Konjunktiv.

SPICE®

Software Process Improvement Capability dEtermination

Auch wenn der Standard für eine Organisation! (es ist eine Organisationsnorm) entwickelt wurde, welche Software entwickelt, man kann Sie auch an andere Bereiche leicht adaptieren.
Dieser Standard hilft, sich daraus einen in-house-Prozess-Standard zu entwickeln.
Die Medical SPICE (VDI5702) ebenso.
Die in diesen Normen geforderten Prozesse, die Basispraktiken und die Arbeitsprodukte sind auch bei agiler Arbeitsweise anwendbar!

Wir können es besser!

Wir wären so froh Ihnen genau das sagen zu können.
Aber auch bei uns gehen Dinge nicht immer so wie wir wollen. Auch wir kämpfen mit den „inneren und äußeren Wiederständen“ in den Firmen. Die Folgenden Erfahrungen und Maßnahmen tragen jedoch signifikant zur Erhöhung der Qualität und Reduktion der Kosten bei.
Wir können Sachignoranz, „Quertreiber“ und „Besserwisser“ nicht eliminieren.
Das Folgende richtet sich also nicht nur an Projektmanager, sondern an alle Projektbeteiligten, wenn Diese nicht mit an einem Strang ziehen stehen Sie als Projektmanager auf verlorenem Posten.

Wenn Sie die nachfolgenden Punkte beachten wird es für alle Beteiligten weniger Geld und mehr Qualität bedeuten, auch wenn es zu Anfang nicht so aussehen mag.

Image by Arek Socha from Pixabay

Projekte gehen schief, weil….

PMI 2017 Untersuchung

Wir werden im Folgenden viele dieser Punkte aufgreifen, zeigen was die häufigste Ursache ist, und welche Mittel der Projektleiter zur Verfügung hat, um diese Situationen zu steuern/korrigieren.
www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en

Was will SPICE?

Nachfolgender Text ist stark vereinfacht, beschreibt es aber ganz zutreffend.

Die SPICE Standard will, dass Sie Software entwickeln, welche den Anforderungen des Kunden entsprechen. Das ist typisch Qualität.

Wie fast jede Norm ist Sie so geschrieben, dass man auf Seite 3-5 nach dem Papierkorb sucht.
Mit ein bisschen Einsatz wird die Norm aber selbst für das Management zu einem MUST have. Es ist also wie bei jeder Norm, es braucht einen, der die Inhalte der Norm verdichtet und in praktikable Umsetzung überführen kann. Dazu später mehr.

Jeder Prozess (32 an der Zahl, davon bei Systementwicklung 16 bzw. nur 10 Prozesse bei reiner Softwareentwicklung verpflichtend) hat ein Prozessziel.
Darüber lassen sich typischerweise alle Kollegen „ins Boot holen“.
Zu jedem Prozess gehören:
Ziele, Ergebnisse, Praktiken und Arbeitsprodukte (mit Qualitätskriterien).

CMMI Levels

Für das Level 1 müssen Sie in der Lage sein nachzuweisen, dass Sie in jedem geforderten Prozess > 50% der Basispraktiken (die Sie nach eigenen Wünschen an Ihr Unternehmen adaptieren dürfen) und ebenso, dass Sie > 50% der geforderten Arbeitsprodukte erstellen.

Für das Level 2 müssen die obigen Punkte > 85% sein und Sie müssen das Planen und Steuern > 50% erreichen.

Level 3 alles Vorherige auch wieder bei > 85% und ein Rollout an die Dependancen mit Anpassungsrichtlinien etc.

Sie werden feststellen, dass sehr viele Probleme durch die Basispraktik „MAN.3.BP5 Ressourcenbeschaffung und Umplanung“ abgefedert werden können.

Und dafür benötigen Sie exzellente Prozesse.

Nun aber zu den Punkten aus der Studie und wie Sie diese „fangen können“

Image by Free-Photos from Pixabay

Änderung der Prioritäten der Organisation

Zunächst hat die Firma einen Auftrag gejagt und gewonnen.
Nun kommen neue Aufträge und andere Prioritäten, die Ressourcen werden abgezogen, oder es gibt im Unternehmen eine Taskforce und dadurch werden die Ressourcen werden abgezogen um das andere Projekt zu „retten“.

Die Folge ist, das andere Projekte nun nicht ausreichend Personal haben, um die Aufgaben zu erledigen und der Taskforce Modus hier auch kurz vor der Tür ist. Der Terminplan wird in Mitleidenschaft gezogen.

In den Projekten entsteht ein hohes Maß an Verwirrung, da die beteiligten Personen oftmals durch diese ständigen Verschiebungen gar nicht wissen was sie aktuell tun sollen bzw. die Planung im „Firefighter Modus“ auf Tagesebene verändert wird.

MAN.3 BP5 Ressourcen bekommen oder Umplanung

Empfehlung

Zeigen Sie auf, dass eine Person, welche je zu 1/3 in einem Projekt arbeitet, keine 1/3 Leistung liefert.
Jede neue Aufgabe bedeutet immer umschalten. Und bevor man sich in etwas eingefunden hat, vergeht Zeit. Die Ressourcenteilung, unter der Annahme, dass Zeit = Leistung ist, geht immer schief, Planen Sie um, und zeigen Sie die Folgen der Veränderung auf. Kämpfen Sie um die Ihnen zugesagten Ressourcen. Keiner wird Sie mögen, aber Sie werden noch weniger gemocht, wenn Sie das Projekt vergeigen.

Wenn Sie diese Ressourcen nicht haben, kaufen Sie ein Team ein, welches die Aufgaben erledigt. Auch hier gilt, dass das neue Team Zeit braucht, um produktiv zu sein.

A Fight…

Ein Kunde von uns hatte bereits in der Planung, siehe auch weiter unten „Unzureichende Ressourcenprognose“ und „Ungenaue Schätzung der Task-Zeit“ massive Fehler begangen. Die avisierten 13 Mio. Entwicklungskosten/Ressourcen, wären selbst mit einem erfahrenen Team nicht zu meistern gewesen. Die mittels einer geeigneten Methode nachkalkulierten Kosten lagen bei 33. Mio. Diese schockierende Mitteilung wurde – da nicht opportun – ignoriert und stattdessen auch noch Personal abgebaut. 

Als Resultat war die Firma 2 Jahre im Task Force Modus, plötzlich waren – weil der Kunde natürlich irgendwann mit Projektabzug gedroht hat – Ressourcen verfügbar und die Gesamtkosten überstiegen 45 Mio.

Image by Gerd Altmann from Pixabay

Eine gute Planung bedeutet hier: Management geeignet und sachlich nachvollziehbar. Faktenbezug.

Die Idee hier mit einem Standalone Projektmanagementwerkzeug alles erledigen zu wollen, funktioniert fast nie. Sie müssen Life Daten aus den einzelnen Prozessen haben. Wenn Sie darauf angewiesen sind die Daten aus den einzelnen Prozessen mittels regelmäßigen „Meetings und Reporting“ zu bekommen, sind die Daten, abgesehen von der Inkonsistenz, schon veraltet, bevor Sie den Report fertig geschrieben haben. Hier ist bei der Digitalisierung gemäß dem Level 2 der SPICE gemäß der „GP 2.1.3 Monitor the performance of the process against the plans“ ein Workflow Management System zu verwenden. Aber auch hier gilt „A fool with a tool is still a fool“ Ungeeignete Tools, Tools nicht verkettet sind und Tools, welche inhaltlich nicht gut gepflegt werden, nutzen Ihnen nicht viel, womit wir zum nächsten Punkt kommen.

Ungenauigkeiten – signifikante Abweichungen

Ursachen:

Image by Gerd Altmann from Pixabay

Schätzungen werden gerne angezweifelt. Das ist nur zu verständlich, wenn Sie den Druck sehen, unter dem man steht, Aufträge zu gewinnen.

Falsche/keine Methoden zur Ermittlung der Aufwände. Optimismus/Pessimismus bei der Schätzung, sowie die Abhängigkeit der Vorgaben aus dem Vertrieb erhöhen hier den Druck. Die Lessons Learned, werden gerne ausgeblendet

Das Thema wird zusätzlich schnell „politisch“. Beispiel ist der BER, Stuttgart 21 oder auch der VW ID.3

Die genannten Ursachen für das Projektversagen „Unzureichende Ressourcenprognose“, „Überlastung“, „Unerfahrene Projekt Manager“, sowie „Ungenaue Kostenschätzung“ kumulieren sich hier zusammen mit dem Obigen.

MAN.3.BP4: Define, monitor and adjust project activities

MAN.3 BP5 Ressourcen bekommen oder Umplanung

Unerfahrene Projektmanager:

Beginnen wir mit dem Einfachsten:

Zertifikate sind schön, sind aber keine Erfahrung!

Die Zeit, welche mit einer Sache verbracht wurde, ist auch keine Erfahrung!
„TLDR“ = „Too Long Didn‘t Read“ Wird auch immer wieder gerne ins Feld geführt. Es muss etwas fertig gestellt werden.

Its starts with reading. Image by Foundry Co from Pixabay

Unser Kunde hatte einen sehr erfahrenen Abteilungsleiter, der unter anderem PMI zertifiziert ist. Allerdings fehlte auch Ihm die Praxiserfahrung.
Entgegen unserer, mit Zahlen und Fakten begründeten Empfehlung (Verdreifachung der Ressourcen gefordert), bzw. Zeitverzug, wurde das Projekt nach vorne gepeitscht und im Sinne von „der Vorgänger hat gesagt wir sind schon fertig und brauchen nur noch das Testat“ der Rollout durchgesetzt.
Unsere Aussagen waren, obwohl nachvollziehbar, „nicht opportun“.
Die notwendigen Normen wurden gemäß dem obigen TLDR nur von uns und einem internen Kollegen gelesen. Man ging so weit dem internen Projektmanager zu sagen, dass er sich um die normativen Anforderungen nicht darum kümmern müsse.
Das Ergebnis war, dass der Rollout zwar „irgendwie“ ging, aber danach mehrere Iterationen Bug Fixing notwendig waren. Und selbst danach kam es noch einmal „Knüppeldick“.
Selbst einfachste Funktionen waren plötzlich sehr fehlerbehaftet. – Bug Fixing macht plötzlich 80% der Arbeitszeit aus. Das Management war immer noch der Meinung, dass „wir nur dramatisieren würden“ und „das macht doch sonst Keiner“. Bis zu dem Moment, wo man die Zertifizierung 4 x hintereinander nicht erreichte. Gesamtkosten waren dann – inklusive der mehrfachen Zertifizierungskosten 8 x höher als ursprünglich geplant, Faktor 2 hätte gereicht, wenn man von Anfang an das Ganze korrekt bearbeitet hätte

Punkt 2,3,4:
Zeit, Ressourcen, Kosten:
Wie schon oben erwähnt, Erfahrung im Sinne von „Ich habe es gelernt und erfolgreich umgesetzt“, bzw. „Ich habe es vergeigt, repariert und mache den Fehler nicht noch einmal“ ist hier der Schlüssel.

Wenn, wie oben erwähnt, uns trotz unserer Erfahrung nicht geglaubt wird, und wir als externe Mitarbeiter im Projekt sind, wissen wir sehr gut, wie es Ihnen als Angestellter geht.

Kosten- Zeit- und Ressourcenabschätzung

Viele Projekte werden von den „Controllern“ dominiert. Der Vertrieb sucht das möglichst günstigste Angebot abzugeben.

Kosten abzuschätzen ist immer eine riskante Angelegenheit, denn man möchte auf der einen Seite nicht draufzahlen und auf der anderen Seite aber den Kunden entsprechend ein solides Produkt anbieten können.

Ein agiler Ansatz mag hier Abhilfe schaffen, nutzt aber überhaupt nichts, wenn Fakten von irgendeinem der Stakeholder ignoriert werden.

Wenn Sie hier nicht aufpassen können Sie erhebliche Kosten produzieren, wenn Sie keine Prozesse haben, keine Templates keine sonstigen Vorgaben die ihnen klar aufzeigen wie Sie das Risiko minimieren oder wie die Kosten so abschätzen können, dass Sie einen Deckungsbeitrag ableiten können, wenn Sie den Einkauf, den Vertrieb oder das Controlling UND den Kunden hier nicht einbinden, sondern es nur auf der funktionalen Ebene machen, lassen Sie wichtige Informationsquellen Ihres Unternehmens außen vor was letztlich auch dazu sorgt dass dieses Projekt nicht funktioniert wird.

Image by Steve Buissinne from Pixabay

In einem geordneten Projektablauf ist die klassische Ablaufsituation so, dass man eine Kostenabschätzung macht die entweder

  • auf einer konsequenten Analyse der jeweiligen Umfängen ableitet (Aufwand) oder
  • sie einfach einen prozentualen Anteil definieren,
  • plus Risikoaufschlag,

der ihnen dann einen ungefähren Hinweis darauf gibt welche Kosten auf Sie zukommen.

Denken Sie daran, dass der Kunde auch erwartet, dass Sie aufgrund einer neuen Projekts Situation oder einem wie auch immer gearteten Änderungsszenario einen erheblichen Risikoaufschlag auf ihr Schätzung packen Sie mit einer entsprechenden Nachschlag Verhandlung auf Ihn zukommen wird.

Hinzu kommt, dass Sie häufig wahrscheinlich auch nicht immer das absolute Fachpersonal haben das genau diese Risikoanalyse für Sie korrekt durchführt und erst später im Projekt fällt das auf.

MAN.3

Empfehlung

Die Function Point Analyse ist eine für reine Softwareprojekte eine geeignete Methode. Für die Systementwicklung ist Sie nicht ausreichend.

Jeder Pilot eines Flugzeuges ist verpflichtet vor dem Start eine Berechnung durchzuführen. Zustand des Flugzeuges, Flugzeugtyp, Beladung, Wetterverhältnisse etc. und daraus abgeleitet wird die notwendige Spritmenge berechnet inklusive Ausweichflugplatz (Alternate) und Wartezeit (Hold) zur Landung.

Das kann dann schon mal sein, dass die geplante Spritmenge bis zu 50% oberhalb der „idealen“ Situation ist.

Oftmals wird das in der Zwischenzeit von den „Dispatchern“ (vergleichbar mit den Controllern im Unternehmen) durchgeführt. Verantwortlich ist aber der Pilot. Controller ohne eigen erfolgreiche Projektleitungserfahrung folgen „der reinen Lehre“.

Wichtig ist für das jede Person in den Führungsebenen vom Management bis zum Teamleiter, dass Sie Ihren Mitarbeitern vertrauen. Wenn Sie Ihrem Mitarbeiter zutrauen, dass er Ihnen das Flugzeug auch durch schwere Wetter sicher zum Ziel bringt bringt, dann diskreditieren Sie ihr Vertrauen nicht dadurch, dass Sie Ihm unterstellen, dass er nicht richtig rechnen kann. Ein guter Pilot (und Sie sind Ihm typischerweise dankbar) wird Ihnen den Start verweigern, wenn er weiß, dass er das Flugzeug nicht sicher starten, fliegen oder Landen kann.   

Wir empfehlen die „Projektkosten und Ressourcenabschätzung für Systementwicklung“, welche kostenfrei heruntergeladen und genutzt werden kann.

Der Initiale Aufwand zur Anpassung der Zahlen an das durchführende Team (Zustand des Teams, Projekttyp, Mitarbeiter und Knowhow, Risikoverhältnisse ….) ist mit 2-5 Personentagen überschaubar, danach sind Kostenabschätzungen (Prototypkosten außen vor) in ca. ½ Tag sachrichtig zu ermitteln.

Image by Bernd Hildebrandt from Pixabay

Unzureichende/schlechte Kommunikation

  • Wir sind kurz vor Level 1
  • „Oh, Super, dann habt Ihr ja jetzt weniger Task Force“.
  • „Nein wir haben mehr!“
  • „??????“
  • „Einige Team, bzw. Projektleiter wollen auf der Karriereleiter weiter nach oben kommen. Deshalb fahren Sie das Projekt aktiv in den Task Force Modus, um dann als „Hero“ glänzen zu können, wenn Sie es dann trotzdem in Serie bringen.
  • Sie bekommen viel Aufmerksamkeit und <<empfehlen>> sich damit für die nächste Ebene.“

Im obigen tatsächlichem Beispiel ist so ziemlich alles verkehrt was sein kann.

In einer solchen Situation als Manager / Projektmanager zu arbeiten gleicht eher einer Schlangengrube.

Ursache

Was in eine typische Grundursachen für unzureichende oder schlechte Kommunikation?
Besser gefragt, woran erkennt man das?

Das Thema „unwillige/ungeeignete Mitarbeiter“ wird im Folgenden nicht betrachtet.

Image by Bernd Hildebrandt from Pixabay

Zum einen erkennt man mangelhafte Kommunikation daran, dass es offensichtlich sehr, sehr viele Meetings gibt, in denen man ständig versucht sich wieder neu zu synchronisieren und die Informationen Fehlinformationen abzugleichen, zum anderen sind es E-Mails, mit dem Inhalt ala „kannst du mir noch mal den letzten Stand schicken“.
Hier sehen wir das offensichtlich die Informationsketten und Ablagesysteme nebst Strukturen nicht existieren. Häufig existieren nicht mal Werkzeuge, die eine klare Kommunikation erlauben.

Und ganz davor sind mangelhafte Prozesse.

Wenn man es ganz nüchtern betrachtet sind Zeichnungen oder Lastenhefte nichts weiter als Kommunikationselemente in denen Anforderungen in textueller oder gezeichneter Form einem Prozessbeteiligtem mitteilen

Schwieriger wird es erst wenn die Inhalte nicht klar sind.

  • Trennung zwischen funktionalen und
  • einer nicht funktionalen Anforderung oder
  • es ist nicht dokumentiert wo und in welcher Form denn dokumentiert werden soll
  • Es existieren keine Vorgaben wie etwas zu dokumentieren ist,

Sie sehen, es ist nicht so einfach das hier zu tun aber die Elemente, die hier beschrieben wurden, sind alle ein Indiz dafür, das sehr schnell schlechte Kommunikation entstehen kann.

Was aber am schlimmsten ist, ist die fehlende zentrale Ablage und Versionsverwaltung der Anforderungen:

Was habe ich von welchem Kunden in welcher Form bekommen und woran erkenne ich als Unternehmen, dass diese Information die letzten sprich die aktuellen sind und auf dieser Basis ich dann aufsetzen kann, um meine Entwicklung zu starten?

Und wie stelle ich durch mein Änderungsmanagement sicher, dass diese Informationen jederzeit verfügbar sind und ich Sie jederzeit jemanden geben kann, wohl wissend, dass ich damit nichts Falsches rausgebe.

Aus dieser mangelhaften Kommunikation, sowie der Idee, es wird nicht so schlimm kommen, erwächst dann das nächste Problem.

Schlechte Anforderungen

Do the requirements look like that in the behind for you?

Es muss schneller fertig werde, dafür haben wir jetzt keine Zeit, ist wie eine Reise, ohne die Dinge mitzunehmen, welche man im Zielgebiet braucht. Nur das Jetzt ist wichtig.

Die falsche/fehlerhafte Erfassung der Anforderungen gilt mit 39 % als der Schlüsselfaktor für Projektversagen. Andersherum lässt sich aus der Versagensseite ableiten:

Gute Anforderungen sorgen für erfolgreiche Projekte

Requirements Engineering für jeden Prozess und der zugehörige Review machen das Projekt scheinbar sehr „langsam“, besonders dann, wenn es im Review noch Abweichungen gibt, welche korrigiert werden müssen.
In Zeiten der „Agilität“, des „DevOps“ und „Continious Delivery“, sowie der Idee, dass man im 2/3 Wochen Rhythmus etwas fertigstellen soll, erscheint das Vorgehen „erst einmal Requirements Engineering“ sehr antiquiert.

Die Zeit von 2 Stunden zur Gestehung einer (1) Anforderung scheint utopisch langsam, ist aber im Automotivsektor eher als schnell anzusehen.
Das Gestehen eines Architekturelements ist mit ca. 20-25 Arbeitstagen realistisch.
Wenn die Anforderungen schlecht sind, wie soll das Produkt gut werden!
Die Aussage von 1987:[1]

„Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase. “

ist auch heute weiterhin gültig.

Das Risiko 100 x höhere Kosten bei gleichzeitig schlechterer Qualität und unglücklichen Mitarbeitern, was wiederum schlechter Qualität und langsameres Arbeiten bedeutet, sind Dinge, welche man, wenn irgend möglich, vermeiden sollte.

Prozesse SYS.- und SWE.1-3 in Kombination mit guter Planung

Die Anforderungen einem Projekt stellen die Planungs- und Änderungsgrundlage dar. Das ist eine Binsenweisheit, die aber oftmals nicht so gesehen wird.

Betrachten wir uns eine typische Entwicklung im Automobilbau haben wir immer drei Musterstände.

  • Das A Muster das gemeinhin auch als Funktionsmuster gilt
    d. h. hier kommen etwa 30 % aller Anforderungen hinein, dann
  • das B Muster, hier werden etwa 70 % des Gesamtumfangs erwartet und zum Schluss
  • das C Muster
    Das spiegelt den Serienstand mit 100 % wider

Wenn man zum Anfang schlecht geplant hat und die Anforderungen nicht klar sind muss man sich darüber im Klaren sein, das man den vollkommenden Fehlschlag hiermit einplanen muss.

Dieses Risiko müssen Sie mit einbeziehen.

Die Effekte:

  1. Unklarheit im Projekt, sprich erhöhter Aufwand um zur Klarheit zu bekommen, um zu verstehen was man genau entwickeln soll?
  2. möglicherweise einen kompletten Fehlschlag bis hin zum Risiko des Projektabbruchs durch fehlendes Verständnis für die Kundenanforderungen.
  3. steigende Frustration im Projekt, die Mitarbeiter gehen möglicherweise in eine innere Kündigung

Ein Kollege, aus dem Mechanik Bereich bekam vom Kunden die Aufgabe ein „neues Lastenheft zu bewerten“.  Obwohl in der Firma überhaupt nicht etabliert und von allen belächelt hat er sich unseren Rat zu Herzen genommen, das Dokument in ein Requirements-Engineering Tool überführt und jede einzelne Anforderung bewertet und mit den Fachabteilungen abgestimmt.

Das Ergebnis:

  1. Die Kollegen stellten fest, dass es das Beste Anforderungsdokument ist, welches Sie je hatten
  2. Es entstand Panik, weil ca. 20% (140) der Anforderungen des Kunden abgelehnt wurden und der Kunde dafür bekannt ist, maximal 10 Änderungen in den Anforderungen zu akzeptieren.
    (Da standen Formulierungen wie:
    „Wenn ich als Kunde eine Fehler mache, haftest Du Lieferant dafür“)
    natürlich wurden diese Anforderungen abgelehnt.
  3. Bei der Durchsprache hat der Kunde ALLE Änderungen akzeptiert, weil jede Änderung/Ablehnung begründet war, bzw. mit Lösungsvorschlägen versehen war.

Sachlogik schlägt hier jedwede Meinung und – wenn es detailliert gemacht wurde, erhöht dieses Arbeiten des Lieferanten das Vertrauensverhältnis – und das ist fast unbezahlbar.

Empfehlung

Nutzen Sie Ihre Toolkette, welche die Informationen konsistent hält, oder führen Sie eine ein und stellen Sie sicher, dass man das Tool auch nutzt.

Es gibt die Tendenz, weil dies Werkzeuge mächtig sind und dementsprechend Schulungsaufwand und eine gewisse Arbeitsdisziplin erfordern, doch wieder auf Dateiablagesysteme zu gehen.

Stellen Sie sicher, dass sie diesen Single Point of Information jederzeit haben und haben damit eine gesicherte Information. Weiterhin ist es äußerst wichtig, dass sie ein aktives Monitoring einführen. Nutzen Sie die normativ geforderte Überprüfung der Arbeitsinhalte also ein sogenanntes Review, das sicherstellt das die Arbeitsinhalte, die jetzt gerade den sogenannten letzten Stand darstellen immer noch mit den Anforderungen des Kunden übereinstimmen. Dies hat eine sehr elegante Nebenwirkung denn auf die Art und Weise führen Sie sehr leicht den sogenannten kontinuierlichen Verbesserungsprozess ein da sie ja stets die Arbeitsinhalte überprüfen. Sie werden relativ schnell erkennen, dass die Mitarbeiter es sehr gut finden zu wissen wann etwas gut ist und wann nicht.

„Wir brauchen endlich mal ein echtes Code Review“ war die Aussage der Mitarbeiter im Projekt.

Wenn Sie hier effektiv arbeiten und den Fortschritt wirklich überprüfen, verhindern Sie auch die


[1] Software Defect Reduction Top 10 List Barry Boehm, University of Southern California, Victor R. Basili, University of Maryland

Überlastung

It feels like this if you are overloaded. Image by Tú Anh from Pixabay

40-50% eines jeden (Software)Projekt sind vermeidbare Nacharbeit.[1] Auch das ist seit Jahren bekannt.

Das obige Anforderungsmanagement mit Review wird Ihnen Unmengen an zusätzlicher Arbeit sparen.

Zusätzlich gibt es oftmals ein fehlerhaftes Monitoring/falsche Tools/Ignoranz.

„Wer viel misst, misst Mist.“ ist eine bekannt Redewendung.
Typischerweise wird der Fortschritt der Aufgaben überprüft und der Erreichungsgrad „abgefragt“.

Eine gutes Tool ermöglicht Ihnen jedoch nicht nur den Status der Aufgaben, sondern auch den Status der zugehörigen Artefakte zu überprüfen. Ein Statusmodell für die Anforderungen, die zugehörige Praktik des Verplanens einer jeden Anforderung zu den Releases über die Prozessebenen hinweg schafft hier Transparenz.

Im Laufe der Zeit hat sich in Unternehmen eingeschlichen, dass man lieber falsche Daten liefert, Unfertiges als Fertig deklariert und sich den Projektstatus „schön“ berichtet.

Projekte, welche im Status „Tiefdunkelrot“ sind, werden, um keinen Stress mit dem Management zu bekommen, immer noch als „Gelb“ berichtet.

Ein Teil dieser Tendenz ist dem Management zuzuordnen[2], welches „good news only“ möchte, ein Teil den Mitarbeitern, welche bereit sind Standards aufzugeben, um dem Management zu gefallen.

Hier ist Ihr Fingerspitzengefühl gefragt, ggf. gibt es einen wirklichen Kampf.

„Erfahrene Vorgesetzte“, welche über Jahre hinweg die Probleme unter den Teppich gekehrt haben werden bei Tool getriebenem Reporting natürlich auch gnadenlos bloßgestellt.
Der Widerstand zur Toolnutzung ist natürlich vorprogrammiert.
Eine Unterstützung durch das Management ist zwingend notwendig.

Überlastung entsteht auch, wenn Personen mehreren Projekten zugeordnet werden.
Jeder Projektmanager benötigt die Key Ressourcen zu 100%. 50% werden versprochen und dann werden die Ressourcen und Mitarbeiter aber trotzdem 3 Projekte zugeordnet.
Dass man bei Tools die Rüstzeit hinzunehmen muss ist völlig klar. Das man als Mitarbeiter bei 30% Projektverfügbarkeit aber IMMER wieder den Kopf „umschalten muss“ dreimal so viele Meetings und Abstimmungen hat und diese 30% dann de facto nur 15-20% sind, wird oftmals nicht berücksichtigt. 400% verplante Auslastung, habe ich erlebt. Die Projektsituation, die Stimmung und die Qualität war dementsprechend.

MAN.3.BP5: Define, monitor and adjust project estimates and resources

Empfehlung

Gute Tools zeigen ihnen die Cross Project Ressourcen Nutzung auf.  Das beste Reporting und Monitoring nutzt aber überhaupt nichts, wenn Sie in der Planung (s.o.) ordentlich arbeiten.

Die Überlastung entsteht natürlich auch durch die gerade angesprochenen


[1] Boehm, Basili – ebd.

[2]Why Do So Many Managers Forget They’re Human Beings?
https://hbr.org/2018/01/why-do-so-many-managers-forget-theyre-human-beings

Begrenzte Ressourcen und Ressourcenabhängigkeit

In einigen wenigen Bereichen gibt es tatsächlich begrenzte Ressourcen und eine Abhängigkeit von „nur einem Lieferanten/einem Mitarbeiter“.

Die Crux an der Sache ist, dass man, während man in jedem Lieferantenverhältnis versucht einen weiteren Lieferanten zu qualifizieren und die Abhängigkeit zu verringern, bei Mitarbeitern dahin tendiert diese über jegliche Vernunft hinweg zu belasten. Ebenso wird die Fähigkeit im eigenen Hause nicht gesehen.

Ein Kollege der als Algorithmiker auf der „untersten Ebene des V“ arbeitete, wurde von uns für den Posten des Systemanforderungsanalytiker vorgeschlagen.
Das löste beim Abteilungsleiter, sowie in der Personalabteilung größte Verwunderung aus.
Nach einem Gespräch war man „baff erstaunt“ eine solchen Mitarbeiter im Hause zu haben.
Der Kollege war dann innerhalb kürzester Zeit der „Function Owner“ von ca. 80% aller Funktionen auf der Systemebene. Ihm wurden arbeiten „aufgehalst, dass er bei ca. 180% hätte arbeiten müssen.
Erst die widerholte Intervention dem Kollegen Luft zum Atmen zu geben und Ihm andere Mitarbeiter zur Seite zu stellen führte dann dazu, dass die Last auf ein erträgliches Maß reduziert wurde.

Diese Abhängigkeit von einer „Single Ressource“ löst man in den meisten Fällen mit

Mindestens eine Stunde am Tag für das Training/Ausbildung.
Obwohl Sie eine Stunde weniger Zeit haben, um den Job auszuführen, führt diese Stunde in der Regel zu mehr Effizienz oder höherer Qualität.

MAN.3.BP6: Erforderliche Fähigkeiten, Kenntnisse und Erfahrungen sicherstellen.

Ein Teil der Aufgaben des Projektmanagers lautet wie oben. Das impliziert, dass Sie neben der oben erwähnten Schulung auch die Verbesserung der Fähigkeiten planen, die für das ausführende Personal erforderlich sind.

Während das Training in der Regel eine Maßnahme ist, die durch Personal- oder Qualitätsabteilung eingeleitet wird, fügen Sie projektspezifische Trainings hinzu. Jedes gewonnene Wissen und anwendbare Fähigkeit führt zu einer glücklicheren und damit effizienteren Person, und genau das brauchen Sie.

Und wenn Sie das machen, dann sind die Reaktionen etwa so.

„Zu meinem Erstaunen wurden alle auf 6 Monate geplanten Ziele innerhalb von nur ca. 4 Wochen vom gesamten Team erreicht.

Danach wurden die Aufgaben signifikant erweitert (vervielfacht) ……

Hier war die Aufgabe zu meistern, die technischen Details der einzelnen Fehler innerhalb der Module zu klassifizieren, zu systematisieren und so aufzubereiten, dass die Fehlerlösung für den SW Ingenieur möglichst einfach umsetzbar war.

Während HERR X selbst sich innerhalb kürzester Zeit Detailwissen über die einzelnen Module erarbeitete, sodass er auch für die spezialisierten Mitarbeiter (welche täglich bis zu 4 Stunden Ausbildung erhielten) jederzeit ein technisch kompetenter Ansprechpartner war, hat er parallel dazu dafür gesorgt, dass das Wissen in eine systematisierte Form überführt wurde und ein Wissenstransfer im Team stattfinden kann. Trotz täglich steigender Arbeitslast und Anforderungen an das Team, hat diese Systematisierung und Konzentration auf die notwendigen Prozesse dazu geführt, dass das Analyseteam immer die vorgegeben Ziele erreicht hat.

Das Argument, dass durch Training nicht viel Produktives geschaffen werden kann, fällt damit vom Tisch.

Fähigkeiten und Verstehen sorgen für mehr Effizienz, und das dauerhaft.

Eine weitere Herausforderung ist, dass der Kunde erwartet, dass seine Time-Line, eingehalten wird. Beginnend bei der obigen Planung und dem Lesen der Anforderungen sind die ersten Stellhebel zur Vermeidung dieser Stressfaktoren. Wenn Sie dem Kunden gegenüber Lösungen aufzeigen wie sein Haupt Zeitplan eingehalten wird, Ihre Versprechen halten, so spielt er bei kleineren Verzögerungen mit, sofern Sie ordentliche Qualität liefern.

Der Kunde, dem Sie ein Produkt liefern, welches nicht seinen Anforderungen entspricht, machen Sie sehr unglücklich.

Das Lieferanten alles mögliche liefern, nur um zu sagen, wir haben den Liefertermin eingehalten, haben wir nicht nur einmal erlebt. (Auf Kunden und auf Lieferantenseite).
Die daraus resultierenden Emotionen und die Vertrauensbasis, brauche ich Ihnen wohl nicht zu beschreiben.

Sie müssen die „schlechte“ Arbeit noch einmal machen, wofür Sie aber jetzt, aufgrund des fortgeschrittenen Zeitpunktes, gar keine Zeit mehr haben, weil Ihnen sonst die nächste Phase wegläuft.

Das heißt, die vermeintliche Lösung wird zu einem Problem, da die Last der Arbeit erhöht wurde und der Zeitplan gleichgeblieben ist.
Wenn Sie mit dem Kunden etabliert haben, dass Sie verlässlich sind, kämpft der Kunde für Sie wie ein Löwe.

Alle Prozesse der linken Seite des V. (System, Software, Hardware und Mechanik) sind Anforderungen!

Mit einer ehrlichen Planung, offener Kommunikation und guter Qualität (== Compliance with Requirements) überzeugen Sie den Kunden und auch ihre Kollegen intern.

Prozesse und Neuentwicklung zusammen bedeutet:

Sie haben einen Zweifrontenkrieg im Projekt.

Zum einen wissen Sie nicht was Sie tun sollen und zum anderen wissen sie nicht wie Sie es tun sollen. In so einem Fall stellen Sie auf jeden Fall sicher, dass Sie mindestens einen Prozessexperten dabei haben der zur Laufzeit der Entwicklung die Prozesse mit entwickelt und der als Ansprechpartner gegenüber der Entwicklung arbeitet und so mögliche Schwachstellen im Projekt von vornherein eliminiert.

Und wie bereits oben angegeben – Projektmanager ohne Erfahrung … Diese sorgen dann für den nächsten Punkt:

Undefinierte Chancen und Risiken

Is it a risk – or not?

Jedes Risiko, welches spät erkannt wird verringert die Wahrscheinlichkeit, dass man es in den Griff bekommt und “erhöht den Blutdruck“ Es wird hektisch und die Ressourcen gehen in die bereits oben angesprochene Überlast.

Entweder Sie identifizieren und kontrollieren die Projektrisiken
oder die Projektrisiken kontrollieren Sie.

Eines der elementaren Probleme eines Menschen, ist dass der Mensch etwas glaubt.
Glauben ist: „von Beweisen unabhängiges Wissen“[1]

Etwas profan ausgedrückt könnte ich sagen ich glaube, dass die Anforderungen in Ordnung sind, ich glaube das im Keller das Licht aus ist, ich glaube ich habe das Auto abgeschlossen.
Die Schwierigkeit von Menschen ist es, Wissen wirklich anzuwenden und wirklich zu wissen dass etwas richtig ist.  Ein ähnliches Problem ist der berühmte Spruch: „Aus den Augen aus dem Sinn“, oder „Was ich nicht weiß, macht mich nicht heiß“.


[1]www.dwds.de/wb/Glaube

Eine gute Planung schließt die Betrachtung der Risiken mit ein.

Die erste Reduktion von Risiken besteht darin das Kundenlastenheft und die mitgeltenden Unterlagen zu lesen und dem Kunden zurück zu spiegeln, wie man zustimmt/ablehnt.

(Ein) 1 Anforderungsdokument von 120 Seiten enthält 20 Seiten „Mitgeltende Unterlagen“

Ganz vorne im nicht gelesenen Vorwort – man braucht ja nur die Anforderungen lesen  und von Verstehen wird erst recht nicht gesprochen – steht der Satz:
“Alle genannten Unterlagen sind rechtsverbindlich mitgeltend.“

20 Seiten mit jeweils ca. 30 referenzierten Dokumenten ± 50 Seiten /Dokument und ggf. weiteren Querverweisen.
Spätestens dann machen sich bezahlt das Lastenheft richtig zu lesen und diesen Punkt dann erst einmal abzulehnen.

Verwenden Sie Checklisten wie in der Luftfahrt oder Sie schulen den „Piloten“ regelmäßig im Simulator. Fordern ihn mit Risiken heraus, von denen Sie wissen, dass es Sie geben könnte.

Diese Simulatorflüge kombinieren immer wieder Dinge, von denen Sie im normalen Leben glauben, dass Sie sie niemals treffen werden. Wenn Sie geschult sind und sich Risiken bewusst sind, haben Sie einen bestimmten Alarmstatus und werden frühzeitig handeln, um einen Absturz zu vermeiden.

Immer wenn Risiken nicht aktiv angegangen wurden, oder mit dem

  • „das haben wir noch nie gemacht“ oder
  • „das wird schon nicht passieren“ etc.

ignoriert wurden, sind die resultierenden Probleme um so schlimmer geworden. 

Selbst nachdem die Risiken tatsächlich in Probleme gemündet sind, werden diese nicht angenommen, da man nie aus dem „ich glaube“ zu „ich schaue“ gewechselt ist.

Nehmen Sie das Risikomanagement nicht so, als würde es nicht passieren.

In der Funktionalen Sicherheit (ISO 26262) gibt es den Ansatz des untolerierbaren Bereiches, der durch geeignete Maßnahmen in einen tolerierbaren Bereich verschoben werden muss. D. h. hier muss konsequent der Stand der jeweiligen Risikobearbeitung überprüft werden. Wie beim Piloten, der regelmäßig überprüft, dass alle Parameter des Fluges und des Flugzeugs noch passen. Es mag Ihnen passieren, dass Sie beim Umfliegen des Gewitters andere Chancen und Risiken bekommen.

Jeder Pilot hat geeignete Werkzeug, Wetterradar, Wetterbeobachtung (von anderen Piloten und vom Meteorologischen Dienst) Karten, Satelliteninformationen und, und, und.

Haben Sie diese Daten und die Werkzeuge auch? Haben Sie die „Anzeigeninstrumente“ welche Ihnen die Probleme aufzeigen werden?

Achten Sie bei all ihren Risiken grundsätzlich auf das „magische Dreieck“, der Verbindung von Qualität zu Kosten zu Zeit.

Änderung der Projektziele /schlechtes Change-Management

Zu Anfang sollte es eine kleine Darstellung statischer Informationen sein, später ein Spiel für 16-Jährige.

Das ist zwar im Automotive Umfeld nicht so krass wie bei anderen Projekten, aber es wird immer wieder gerne versucht. “  Das einzig Konstante ist die Veränderung.[1]“ Genau unter diesen Rahmenbedingungen befindet sich jedes Projekt.  Zu Beginn ihrer Analyse kommen Sie vielleicht auf ein Budget von 10 Millionen €, nach einiger Zeit stellen Sie fest, dass aufgrund von neuen z.B. Produkthaftungsanforderungen, die bisherige Annahme deutlich gerissen wird oder gerissen wurde.
Ihr Ziel das Projekt zu einem Zeitpunkt X zu realisieren ist unter den jetzigen Bedingungen nicht mehr realistisch.

Sobald Sie das feststellen muss das eskaliert werden. Auch wenn die typische Reaktion ist. „Das wird schon nicht so schlimm werden.“ Die Antwort heißt: „Jep, es wird noch schlimmer“.

Bisher haben wir es noch nicht erlebt, dass es „nicht so schlimm geworden ist“.  Auch hier ist es Aufgabe des Projektmanagers sicherzustellen, dass die sich ergebenden Risiken und Änderungen vollständig betrachtet werden.

Der Brushoff: „Es wird schon nicht so schlimm werden“ wird ausschließlich von denen vorgebracht, welche nicht im Projekt stecken.

Die Richtige Antwort: Anschauen, Bewerten, PDCA

MAN.3.BP4: Define, monitor and adjust project activities.
SUP.10 Change Management

Dadurch dass sich die Anforderung des Kunden ändern, müssen die Ziele, also auch die Meilensteine permanent nachjustiert werden.

Empfehlung

Beginnen Sie wieder mit den o.a. Anforderungen!

Sobald Sie die Änderungen erhalten, bewerten Sie diese mit einer CIA == „Change Impact Analysis“.

Eine „Große Änderung“ entpuppt sich als relativ einfach umsetzbar, eine „kleine Änderung“ kann dazu führen, dass Sie die gesamte Architektur Ihres Systems neu aufsetzen müssen.

Die Risikobeurteilung muss überarbeitet werden.

Dies betrifft auch die sogenannte „Make or Buy“ Entscheidung. Mit anderen Worten: „Kaufe ich jetzt die möglicherweise kritische Leistung ein oder entwickle ich es nach wie vor selber mit all den weiteren Risiken, welche möglicherweise latent in den bisherigen Anforderungen noch steckt.

Bei allen Schätzungen und Annahmen, geben Sie an, warum Etwas das Sie verwenden, so ist, wie es ist.

Möglicherweise haben Sie die Erfahrung, Sie haben jemanden gefragt, oder Sie haben eine Methode verwendet, um das Etwas abzuleiten.

Annahmen und Einschränkungen sowie Methoden können sich ändern, und daher ist eine Änderung für jedes Element leichter zu verstehen, wenn Sie und die Anderen wissen, wie Sie zum Ergebnis gekommen sind.

Am besten erstellen Sie eine Checkliste oder eine Methode, die in Ihrem Unternehmen anwendbar ist.

Es gibt je nach Vision oder Zielsetzung für das Projekt mehrere Schätzmethoden die je nach Umfang der Funktion ihre absolute Berechtigung haben.


[1] Heraklit 2500 BC

Unzureichende Vision oder Zielsetzung für das Projekt

Fang schon mal an, das ist doch so einfach. Dann, sobald man erste Ergebnisse liefert ändert sich alles. Die Anforderungen – s.o. sind unklar. Den Projektumfang zu definieren fällt interessanterweise auch gestandenen Projektleitern häufig schwer. Dabei ist es vermutlich relativ einfach für einen Außenstehenden zu erkennen, was das Unternehmen oder das Projekt gerade machen soll. Es geht auch gar nicht so sehr darum diesen Arbeitsumfang so hochgradig akademisch oder auch entsprechend stilvoll zu beschreiben, sondern vielmehr darum den aktuellen Zustand oder Umfang des gesamten Arbeitsgebietes zu erfassen.

MAN.3 BP1 Define the scope of work.

Aus Sicht der Entwicklung sind diese Anforderungsbeschreibungen des Projektumfangs häufig eine eher lästige Aufgabe, aber aus Ressourcen Sicht macht dieses schon viel mehr Sinn. Wie wollen Sie eigentlich im Projekt überhaupt sinnhaft vermitteln was sie eigentlich genau tun, wenn Sie es noch nicht mal selber beschreiben können?

Beispiel: Steuergerät für eine Alarmierung im Auto.

Sie können jetzt das Steuergerät für die Alarmierung einfach nur nennen, oder Sie können es auch als eine Neuentwicklung betrachten oder eine Weiterentwicklung, also nur diese beiden Namen verwenden.
Leider weiß dann aber der Leser nicht mehr um was es überhaupt geht und was möglicherweise der zeitliche Horizont ist? Im englischen nennt man dieses den sogenannten „Sense of Urgency“. Damit es gemeint wie wichtig es Ihnen eigentlich ist. Die interne Kommunikation wird sich dann dahingehend auch sofort auf diese recht schludrige Beschreibung einschießen und letztlich genauso arbeiten. Achten Sie immer auf die Wirkung der Worte.

Empfehlung

Der Arbeitsumfang stellt eine allgemeine Zieldarstellung dar. Zurückkommend auf das Beispiel wäre zum Beispiel ein durchaus gangbarer Ansatz zu schreiben:

Wir entwickeln ein Steuergerät für ein Alarmierungssystem, das sicherstellen soll, bis Ende des Jahres 100 % der Funktionen umzusetzen auf Basis von Automotive SPICE PAM 3.1. Der Vorteil dieser Schreibweise ist, dass sie mindestens zwei Dimensionen in ihrem Text enthalten nämlich einen Mengenbezug und einen Zeitbezug und damit auch entsprechende Umfänge grob beschreiben. Sie können natürlich dem Projekt selber noch einen kurzen klingende Namen geben. Die hier beschriebene Art und Weise sorgt dafür, dass Sie ohne Weiteres sehr schnell nach außen hin kommunizieren was sie eilig in dem Projekt machen wollen und bis wann sie damit fertig werden wollen. Die Verfeinerung dieser Tätigkeiten findet dann in der Strategie statt.

Unzureichende Sponsorenunterstützung

Planung und Ressourcen (s.o.) sind hier erneut die entscheidenden Faktoren.

Projekte, welche „einfach mit einem „mach mal eben“ begonnen werden, sind aus Unternehmerischer Sicht abzulehnen.

Empfehlung

Projekte mit unklarer Definition des Arbeitsumfangs, sind abzulehnen. Die Arbeit, welche jemand in die Erstellung eines Projektsteckbriefes investiert und eine Grobe Planung erstellt, ist signifikant geringer, also das „verbrannte vor sich hin dümpelnde Projekt“.

Zusammenfassung der obigen Themen

Rein im Projektmanagement Prozess sind die Praktiken

  • MAN.3.BP3: Evaluate feasibility of the project.
  • MAN.3.BP4: Define, monitor and adjust project activities.
  • MAN.3.BP5: Define, monitor and adjust project estimates and resources.

welche direkt beim Projektmanager liegen, die größten Brocken, wenn man diese Studie als Maßstab nimmt.

Das ADJUST also das Anpassen an die Fakten ist der Bereich, welcher der Schwierigste ist.

GESICHTSPUNKTE

Tools:

A Fool with a Tool

Beim Projektmanagement geht es nicht darum, schöne Diagramme und Grafiken zu zeichnen, die dem Stakeholder/dem Management präsentiert werden sollen. Auch besteht die Aufgabe nicht darin komplizierte Werkzeuge zu benutzen und sich für die Fähigkeit feiern zu lassen.
Es geht darum:
„Eine Gruppe von Personen an einem Ziel auszurichten und diese als Team arbeiten zu lassen“.

Kein Werkzeug wird Ihnen helfen, wenn Sie nicht über die Fähigkeiten verfügen, die Prozesse und Methoden ins Leben zu bringen.
Wenn also jemand zu Ihnen stürmt und Ihnen sagt, dass er das Tool gefunden hat, das Ihre Probleme löst, seien Sie sich dessen bewusst. 
„Ein Narr mit einem Werkzeug ist immer noch ein Narr.“

Neue Methoden die alles besser machen.

Wenn neue Methoden und Prozesse auf den Markt gebracht werden, neigen die „Berater und Experten“, welche diese Methoden und Prozesse implementieren dazu, die bekannten und etablierten Grundlagen des Erfolgs zu vergessen[i].
Die richtige Aktion, wenn es neue Methoden und Prozesse gibt ist es diese gemäß einem Prozessverbesserungsprozess (PIM.3)[ii] zu testen und zu implementieren, wenn es sich bewährt oder zu verwerfen, wenn es sich nicht bewährt. Vergessen Sie den Schritt „es zu verwerfen“ nicht, auch wenn die „neue Methode“ das Steckenpferd des Chefs ist.

Studieren Sie bei der Initiierung eines neuen Projekts diese Liste erfolgreicher Vorgehensweisen, um festzustellen, welche davon wertvolle Beiträge zu diesem Projekt leisten können. Studieren Sie die Ursachen der Fehlschläge und stellen Sie sicher, dass sich diese nicht wiederholen. (Lessons Learned, vs. Ignored.)

Normen/Standards wie ISO oder IEEE enthalten kondensiertes Wissen. Daher raten wir dringend zu regelmäßigen Schulungen. Bauen Sie die entsprechenden Aktivitäten in Ihre Überlegungen und Pläne ein.[iii]

Kein Pilot eines Airbus wird die Anflugverfahren für seine große Maschine ändern, weil irgendjemand mit dem Drachen oder Hubschrauber tolle Dinge machen kann. Nutzen Sie Methoden die zu Ihrem Unternehmen passen.

Retrospektive (Process Improvement)

Am Ende aller wichtigen Projektschritte steht eine Überprüfung.
Eine Überprüfung ist eine Qualitätsmaßnahme. Testen.

Menschen neigen dazu zu planen, vorausgesetzt, alles, was sich entwickelt hat, ist in Ordnung. Nicht alle Tests ihrer Entwicklung sind „passed“.  Basierend auf den Erfahrungen in Ihrem Unternehmen sollen eine bestimmte Anzahl von Fehlern und die erforderliche Zeit für die Korrektur geplant werden.
In sicherheitsrelevanten Angelegenheiten kann ein nicht bestandener Test ein Blocker sein.
Führen Sie diese Loop-Zeiten also nach jeder qualitätsbezogenen Aktion aus. (Überprüfung, Test usw.) Unternehmen verlangen in der Regel die Planung für das Beste, realistische und Worst-Case-Szenario, wobei oftmals vorausgesetzt wird, dass der beste Fall immer eintritt. Wenn Sie Erfahrung im Unternehmen haben, können Sie den Ressourcenbedarf für ein ähnliches Produkt vorhersagen. Seien Sie sich bewusst, dass jedes Projekt, das Sie in einem „unbekannten Gebiet“ durchführen, Risiken birgt, über die Sie nie nachgedacht haben, und Herausforderungen birgt, die Sie noch nie zuvor gesehen haben. Planen Sie Puffer.

Erledigtes

Notieren Sie die geschätzten und die tatsächlichen Werte, sowie das Bezugssystem, mit dem Sie diese Werte ermittelt haben.

Um sich für die Zukunft zu verbessern, sollten Sie die Zeit und die Ressourcen, die für eine Aufgabe benötigt werden, dokumentieren und die Mitarbeiter dazu bewegen im Rahmen der gesetzlichen Vorgaben die Aufwände zu dokumentieren.

Planen Sie das Ungeplante

Kein Plan überlebt den ersten Kontakt mit der Realität. Dinge entstehen – Änderungen passieren und Sie haben einen Plan, der nicht mehr aktuell ist, meist noch bevor Sie beginnen. Gehen Sie auf Risiken und deren Auswirkungen ein, um einen Puffer für das Unerwartete abzuleiten.

Priorisieren Sie

Wenn alles gleich wichtig ist, können Sie nicht arbeiten. Also priorisieren! Erstellen Sie sich Ihre Kriterien für die Prioritäten

Als Pilot würden Sie nicht starten, wenn Sie nicht genügend Treibstoff an Bord haben, und Sie würden auch keinen Jet wählen, wenn Sie einen Hubschrauber benötigen, und umgekehrt. Nehmen Sie die Sicht eines verantwortlichen Piloten und handeln Sie entsprechend. Beginnen Sie nicht, wenn Sie wissen, dass einer der folgenden Punkte nicht ausgerichtet ist.

  1. Finanzen
  2. Personal zur Ausführung
  3. Zeitplan
  4. Ausrüstung
  5. Projektziele einschließlich Qualitätsziele

In dem Maße, in dem Sie Unsicherheiten in Bezug auf diese Ziele haben, erben Sie Risiken.

Nochmal der Viewset eines Piloten.

· Was passiert, wenn wir nicht auf dem gewünschten Flughafen landen (Ziel)?          

  • Sie verspäten sich (Personal, Ausrüstung, Finanzen) und müssen die Reise verlängern.
  • Gibt es Ausweichhäfen?
  • Komme ich von dort wieder weg?

· Können Sie vom Plan abweichen, wenn Ihnen ein Gewitter in den Weg kommt?          

· Können Sie geplante Ziele neu organisieren, falls sich eine Situation ergibt?          

· Was ist „MUSS“?          

· Was sind „Ich will nicht haben“?          

· Was ist „schön zu haben“?              

· Was sind triviale Ziele?          

Beachten Sie, dass all diese Aktionen nicht „in Stein gemeißelt“ sind und sich ändern können.


[i] Siehe auch „Hype driven Development“ https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22

[ii] Beispiel wäre der PIM.3 Process Improvement Prozess der Automotive SPICE©

[iii] Templates, welche in einem Tool stehen und „150%“ oder mehr spezifiziert haben, sind hier hilfreich.
Streichen Sie was Sie nicht benötigen, ist besser als auch nur eines zu vergessen.

Konfigurationsmanagement

SUP.8

Konfigurationsmanagement sieht man typischerweise nicht in der Hauptverantwortung des Projektleiters.
Das Thema ist allerdings genau der Bereich, welches dafür sorgt, dass man überhaupt vernünftig planen kann.

Automotive SPICE® gibt Ihnen eine Liste von 128 zu liefernden Arbeitsprodukten und 122 einzuhaltende Base Practices, die ISO 26262 auch noch mal 120 Arbeitsprodukte. Die Gesamtzahl der Qualitätskriterien auf diesen Arbeitsprodukten übersteigt die 1000. Und „on TOP“ kommen nun noch die „Reifegrade“.
Das Schlimmste ist, damit ist das Produkt noch gar nicht erstellt worden, das ist nur der „Rahmen“.
Das ist verdammt schwer zu vermitteln.
Aber, da viele der Artefakte sich im Unternehmen in einem „Container“ (Objekt gleicher Klasse) zusammenfassen lassen, sind es erheblich weniger Artefakte. Und auch die Qualitätskriterien kann man sich entspannt ansehen
(Eine Gehaltsabrechnung hat > 30 Kriterien, also ist die Gesamtzahl von > 1000 nicht so schlimm.)

Die Normen SPICE und ISO 26262sind kondensiertes Wissen. Nutzen Sie es!

Empfehlung

Erstellen Sie sich eine Liste ALLER Artefakte in der Norm und eine Zusammengehörigkeitsliste – das ist einmal Fleißarbeit

Verfolgen Sie den Zustand gemäß den Prozessen des SUP.8 „Report Status“

Wenn Sie einmal sich daran gewöhnt haben, ist Konfigurationsmanagement, Ihr „Cockpit“.

Es zeigt Ihnen alle Artefakte und deren Status, sowie die Abweichung zwischen Plan und soll.
Sie regelmäßigen Statusmeetings zeigen immer den Status der Artefakte, welche unter Konfigurationskontrolle sind, sowie deren Zusammenfassungen.

Wenn Sie die Qualitätskosten senken wollen, stellen Sie sicher, dass die „Must haves“ immer „im grünen Bereich“ sind.

Ein Hexenwerk ist es nicht, das im Griff zu behalten, es ist „nur Arbeit“.

 

Schreibe einen Kommentar