Monat: März 2021

Ich bin viele Jahre als Freiberufler durch den europäischen Raum gereist, um frohe Kunde zu verbreiten in Sachen Projekt-Realisierung. Genau genommen wurde ich gebucht, um Projekte zu realisieren oder – und das prozentual nicht zu wenig – zu retten. Und um ganz nebenbei noch ein wenig Struktur reinzubringen und good practices zu vermitteln.

Dabei habe ich die folgenden Erkenntnisse sammeln dürfen, welche ich bei über 80% der Projekte vorfand:

1. Viele versuchen oft, fachlich-logisch oder technisch komplexe Projekte erst einmal selber anzugehen, obwohl die notwendigen Skill-Sets ggfls. gar nicht vorhanden waren.
2. Obwohl ich schon frühzeitig im Gespräch war, bin ich oft erst dann gebucht worden, wenn der Karren schon knietief im Morast steckte.
3. Ich bin immer als „Projektmanager“ gebucht worden, obwohl meine Kernkompetenzen eigentlich woanders liegen, und ich habe aber dennoch fast ausschließlich meine Kernkompetenzen ausgeübt und nicht das Projekt „gemanaged“, im klassischen Sinne.

Die drei Punkte schauen wir und jetzt noch mal genauer an.

Wir fangen schon mal an

Obwohl in überraschend vielen Fällen am Anfang gar nicht so richtig klar ist, was eigentlich im Detail realisiert werden soll, habe ich eine Frage sehr oft gehört:

„Könnt ihr nicht schon mal anfangen?“

Das ist so, als würde ich den Tischlermeister bitten, doch schon mal anzufangen, die neue Küche zu bauen. Welche Fronten dran sollen und welche Schränke ich benötige, … ach, das können wir doch später klären.

Solch Herangehensweisen zeigten und zeigen, dass sich Viele der inhaltlichen und prozessualen Tragweite eines Projektes gar nicht bewusst sind. Und damit lässt sich auch zumindest verstehen, warum ebenso Viele glauben, dass man komplexe Projekte auch von Personen steuern lassen kann, die weder das prozessuale, steuernde noch logische Verständnis für das zu realisierende Produkt oder Projekt vorweisen können. Von technischen Aspekten einmal ganz abgesehen.

Insbesondere wenn Projekte primär einen Bunte-Bilder-Charakter haben, also einen Marketing-Fokus besitzen, bspw. eine Biermarken-Seite oder eine Firmenpräsenz, wird gern mal jemand Junioriges in die Position des Projektmanagers erhoben, weil er oder sie gerade frisch vom Marketing-Studium durch ein Assessment an einen freien Arbeitsplatz neben dem Drucker gestolpert und verfügbar ist.

„Dann kann die/der gleich mal zeigen, was sie/er kann!“

… oder auch nicht kann.

Für manche dieser armen Seelen, die glauben, dass man ihnen mit so einem Projekt einen Gefallen getan hat und eine Chance geboten hat, sich zu beweisen, ist XML eine chinesische Nudelsuppe. Und genau so sieht das Ergebnis dann auch aus.

Das Thema „gescheiterte Projekte“ gehe ich irgendwann in einem separaten Beitrag einmal an.

Der Karren ist wieder frei

Die möglichen Folgen von vergaloppierten Projekten können vielschichtig sein:

• Zeit und Geld verbraten
• unzufriedene Kunden und auch Mitarbeiter
• Image-Schäden
• komplette Projektstops
• im worstcase auch Firmeninsolvenzen

In komplexen Projekten gilt daher meistens: „Wer spart, zahlt doppelt!“ Oder noch schlimmer. Insbesondere an der Besetzung von Schlüsselpositionen entscheidet sich oft der Erfolg eines Projektes. Wer da nicht zum richtigen Zeitpunkt weiß, was wann zu tun und was noch zu klären ist, läuft gern mal wochenlang komplett im grünen Status bis ins offene Messer.

Wenn dann jemand (auch Externe) gefunden und auf das Projekt gesetzt wird, um den Versuch zu starten, dieses zu retten, sind meist erst einmal die folgenden und nicht selten schmerzlichen Schritte zu durchleben:

• Einarbeitung in vorhanden Prozesse des Auftragnehmers/Auftraggebers/Projektes
• Einarbeitung in den aktuellen Projektstand
• Einarbeitung in den bisherigen Verlauf (Kommunikation, Anforderungen, Entscheidungen, Entwicklungsschritte)
• Identifikation der Problemstellungen
• Initiale Schritte zur Behebung einleiten
• Die Fragen des Kunden beantworten, wie das denn alles sein könne und warum er das nun noch mal alles erklären muss und wann wird das Projekt denn jetzt fertig.

Eigentlich bin ich was Anderes

Jetzt ist es passiert, ein Projekt ist gegen die Wand gefahren, ich werde als „Projektmanager“ oder „Projektleiter“ gebucht und soll retten, was zu retten ist.

Nach den üblichen Einarbeitungsschritten stellen wir dann fest:
Nicht das klassische Projektmanagement war das Problem. Denn offensichtlich haben sich viele Projektbeteiligte ja irgendwie zusammengefunden und Dinge begonnen oder schon realisiert, von denen alle der Meinung waren, dass es gut ist, das zu tun.

Nein, es ist das verfluchte alte Leiden der Kommunikation sowie differierender Wahrnehmungen und Erwartungshaltungen. Das kannten bestimmt schon die alten Römer.

Es sitzen also zahlreiche erwachsene Personen in Meetingräumen, Video- und Telefonkonferenzen und schaffen es nicht, zu definieren, was denn eigentlich Phase ist, in diesem Projekt. Der eine sagt grün, der andere versteht rot, beide nicken zustimmend, der Designer designt terrakotta-orange, der Entwickler leitet mangels sauberem Briefings ein eher fäkales Braun ab und am Ende schreit man sich an.

Es ist also nicht das Problem, dass man sich zum Arbeiten zusammenfindet und vielleicht sogar eine einigermaßen schlauen Arbeitsprozess gefunden hat, sondern die Anforderungen sind einfach komplett unklar. Oder schwammig. Oder nicht fachlich durchdacht. Oder nicht logisch durchdacht. Oder mit der Direktoren-Ebene nicht abgeglichen. Oder alles zusammen.

Ein Projektmanager bringt also nichts, wenn sich die restlichen Projektmitglieder nicht „belastbar“ verstehen und der PM diese Missverständnisse nicht ausräumen bzw. nicht einmal identifizieren kann oder nicht klar ist, wer eigentlich das Sagen hat.

Entweder braucht man dann einen Business Analysten oder Requirements-Engineer oder beides oder am besten einen business-analysierenden, Anforderungsmanager mit Projektsteuerungsambitionen.

Zugegeben: Diese gibt es nicht wie Sand am Meer. Nicht einmal in der Sandmenge der Sandkiste meines Sohnes. Selbst die Skills einzeln zu finden, gleicht oft schon einer Suche nach der Büroklammer im Papiermülleimer.

Was bleibt? Wenn du niemanden hast oder einkaufen kannst, der dafür sorgt, dass soetwas nicht passiert, dann gibt es eigentlich nur die folgenden Möglichkeiten:

1. Lass die Finger von solchen Projekten…
2. … oder hör auf zu heulen und nimm diesen Riesen-Stress mit allen Auswirkungen hin.
3. … oder staffe dein Projekt richtig.

Rollen

Das Thema Projekt-Rollen oder erforderliche Skill-Sets gehe ich in einem separaten Beitrag noch einmal an. Die Erkenntnis für den Moment:
Es zeigt sich noch zu häufig, dass viele Entscheider gar nicht dafür sensibilisiert sind, welche Rollen bzw. Skill-Sets mit welchem Qualifizierungsgrad an welcher Stelle und zu welchem Zeitpunkt erforderlich sind.

Erst seit 2021 habe ich merkbar das Gefühl, dass zunehmend solche Skill-Sets gesucht werden. Seit Anfang 2021 erhalte ich nicht nur erstmalig sondern auch gleich so dermaßen viele Anfragen über XING und LinkedIn, in denen Anforderungsmanager oder Product Owner gesucht werden, so dass ich nicht mal mehr die Zeit finde, allen absagen zu können.

Vielleicht ist man da auf einem guten Weg.

Natürlich ist das Problem nicht neu. Auch vor 25 Jahren gab es das schon. Da standen und fielen Projekte jedoch damit, ob man einen „guten“ oder einen „schlechten“ Projektmanager hatte. Alles schön subsumiert unter Projektmanagement. Oder Kundenberatung.

Oder: Wie man Missverständnisse bei Anforderungen vermeiden muss.

Wir lernen von Kindesbeinen an, wie wir uns im Optimalfall in der Gesellschaft zu bewegen haben. Dazu zählen auch zahlreiche akzeptierte Kommunikationsmuster: Wie sprechen wir jemanden an, den wir nicht kennen, wie sprechen wir als Kind einen Erwachsenen an, wie verhalten wir uns kommunikativ im Berufsleben.

Zugegeben, insbesondere unter Freunden oder schlimmer noch, unter alten (männlichen) Buddies, sind die unterirdischsten Schimpfworte als guter Opener einer gesellschaftlich akzeptierten Begrüßung etabliert. Dabei sind Einleitung wie „na, alte Ratte“ noch in der Kategorie „Charmant“ einzustufen.

Ansonsten gilt aber unangetastet ein höfliches Raster: Sehr geehrte Frau…, sehr geehrter Herr …, guten Tag, bitte, danke, das wäre sehr nett, würden Sie freundlicher Weise, ich hätte sehr gern das und das, auf Wiedersehen, tschö mit ö, usw.

Es gibt einen Bereich, in dem man diese verinnerlichten und rückenmarksgesteuerten Floskeln sowie andere, gelernte Kommunikationsraster (bspw. publizistischer Natur), tunlichst unterlassen sollte: IT-Projekte. Genauer gesagt, in einem Teilbereich, dem Requirements-Engineering bzw. Anforderungsmanagement.

Holen wir einmal kurz aus:

Im Requirements-Engineering geht es darum, sämtliche Anforderungen einer (oft großen) Gruppe von Stakeholdern (Personen, die eine Anforderung an ein Produkt haben), zu analysieren und so zusammenzutragen, dass diese von spezialisierten Kräften (software-)technisch umgesetzt werden können.
Ein weit verbreitetes Problem sind dabei die nicht durchdachten und schwammig formulierten Anforderungen. Während ich mich zum Thema „nicht durchdachte und schwammige Anforderungen“ an anderer Stelle äußern werde, gehen wir in dieser Abhandlung fiktiv davon aus, dass die Anforderungen grundsätzlich inhaltlich und fachlich durchdacht sind. Bleibt also „nur noch“ die Formulierung der Anforderungen.

Dabei sind zwei Primäraspekte zu berücksichtigen:

1. Wie formuliere ich so, dass eindeutig klar wird, was gemeint ist?

2. Wie schaffe ich es, alle unnützen Informationen auszufiltern?

Ob und wie sich das mit Mustern der hippen Agil-Welt vereinbaren lässt oder ob sich das sogar beißt, dazu werde ich mich an anderer Stelle später separat auslassen.

Wie formuliere ich so, dass eindeutig klar wird, was gemeint ist?

Das, was gewünscht ist, muss unmissverständlich von jedem lesenden Lebewesen auf diesem Planeten dasselbe und eindeutige Verständnis für das „was“ hervorrufen. Wir sprechen hier also von interpretationsspielraumfreien Texten.

Zugegeben: Das hinzubekommen, ist schwierig bis unmöglich. Es muss also eine bestmögliche Annäherung an „unmissverständlich“ und „interpretationsspielraumfrei“ geben.

Aber grundsätzlich gilt, wenn ein Entwickler etwas Emotionsloses und letztendlich auf Einsen und Nullen (also fließt Strom oder fließt keiner) basiertes Stück Logik in Form einer Software umsetzen muss, dann müssen die Anfroderungen verdammt noch mal eindeutig formuliert sein.

Wenn man seine Anforderungen nicht verständlich zusammentragen kann, passiert das, was keiner will aber zum Tagesgeschäft der meisten Firmen oder Projekte gehört:

„Ach, das haben wir uns aber ganz anders vorgestellt!“

Dieser Satz steht stellvertretend für:

• vergebens aufgewandte Entwickler-Zeit
• verbranntes Budget
• vergeudete Zeit grundsätzlich
• Frustaufbau
• Strapazieren von zwischenmenschlichen Beziehungen

Typische Probleme bei der Aufnahme und Formulierung von Anforderungen sind:

• Kommunikationsprobleme, Sprachbarrieren
• widersprüchliche Sichten auf den Ist-Zustand
• unklare Zielvorstellungen des „was“
• hohe und nicht mehr greifbare Komplexität der zu lösenden Aufgaben
• sich ständig ändernde Ziele u. Anforderungen
  • marktbedingt (Märkte sollen sich angeblich sehr schnell ändern können)
  • oder weil bereits mit unabgestimmten oder unklaren Anforderungen einfach mal losgelegt wurde
• schlechte Qualität der Anforderungsbeschreibung
  • mehrdeutig, redundant, widersprüchlich, ungenau…
  • unnötige Produktmerkmale

Natürlich verstecken sich viele Firmen mittlerweile hinter der Agilität und behaupten, man müsse sich einfach viel mehr unterhalten.

Ja klar, wenn man nicht in der Lage ist, seine Anforderungen klar zu strukturieren und zu formulieren, kann man viel intensiver direkt mit den Entwicklern sprechen und Unklarheiten ggfls. durch viele Einzeltherapien aus dem Weg räumen. Aber dann muss man auch hinnehmen, dass man die wenig verfügbare und kostbare Entwicklerressourcen-Zeit zu einem Großteil verbrät anstatt sie entwickeln zu lassen.

Wir müssen darüber hinaus noch zwischen fachlichen und funktionalen Anforderungen unterscheiden und konzentrieren uns in diesem Fall auf ersteres.

Ein paar kleine Beispiele:

„Das Produkt soll das Wetter der nächsten 24 Stunden anzeigen!“

Hierbei ist bspw. unklar, ob das aktuelle Wetter der nächsten 24 Stunden angezeigt werden soll oder ob das für die nächsten 24 Stunden vorhergesagte Wetter angezeigt werden soll.

„Der Zustand der Patienten wird automatisch untersucht und aufgezeichnet!“

In diesem Fall könnte gemeint sein, dass sowohl automatisch aufgezeichnet als auch automatisch untersucht wird, oder dass nur automatisch untersucht wird und manuell aufgezeichnet.

„Wenn der Nutzer den Papierstreifen einsetzt, wird das Tamagotchi auf die Standard-Werte zurückgesetzt!“

Die Anforderung beschreibt ein technisches Gerät, bei welchem mit einem virtuellen Charakter gespielt werden kann. Sowohl der virtuelle Charakter als auch das Gerät selbst heißen „Tamagotchi“, so dass nicht eindeutig ist, ob das Gerät oder lediglich der Charakter auf die Standardwerte zurückgesetzt werden soll.

„Wenn der Nutzer den L-Button drückt, wird der Alarm ausgeschaltet!“

Unklar ist, ob ein ggfls. aktivierte Alarm ausgeschaltet wird oder die grundsätzliche Fähigkeit des Systems, Alarme auszulösen.

Oder zum Abschluss ein Klassiker

 „Schatz, wir haben kein Brot mehr, könntest du bitte zum Supermarkt gehen und eins holen? Und wenn sie Eier haben, bring 6 Stück mit.“

Was wird passieren? Er bringt 6 Stück Brot mit und keinerlei Eier. Und hat aus logischer Sicht alles richtig gemacht.

Das sind nur einige sehr einfache Beispiele. Die mögliche Menge der Unklarheiten und Fehlinterpretationen ist grenzenlos groß.

Wie schaffe ich es, alle unnützen Informationen auszufiltern?

Kommen wir nun zur Unhöflichkeit und betrachten dazu folgendes Beispiel:

„Es wäre schön, wenn die Software hier eine Meldung ausgeben könnte, wenn mit nicht zu großem Aufwand machbar. Wenn zu viel Aufwand, dann könnte man das auch weglassen.“

Kling total nett. Netter Kollege. Mit dem will man auch gern mal ein Bier trinken oder was Leckereres. Das hilft nur im Projekt niemandem weiter. Hier haben wir eine Anforderung, die aus unklaren und sinnlosen Anforderungen besteht. Nehmen wir zuerst die Höflichkeitsmuster aus der Anforderung, dann bleibt:

„Die Software gibt hier eine Meldung aus, wenn Aufwand nicht zu groß, ansonsten könnte man das weglassen.“

Die Entscheidung, ob etwas umgesetzt wird oder nicht, ist im Normalfall nicht Bestandteil einer Anforderung sondern gehört in eine separate Bewertungs- und Priorisierungs-Skala.

Übrig bleibt:

„Die Software gibt hier eine Meldung aus.“

Durch das Weglassen von Floskeln sehen wir die folgenden Effekte:

• Die Anforderung wird präziser
• Es muss weniger geschrieben werden (weniger Zeit)
• Es muss weniger Sinnloses interpretiert und rausgefiltert werden. Das spart noch mal Zeit und wir nähern uns einer Unmissverständlichkeit.

Und jetzt alles zusammen

Wenn wir jetzt noch die Erkenntnisse aus dem vorherigen Abschnitt einfließen lassen, haben wir nach Wegfiltern der sinnlosen Floskeln noch diverse Unklarheiten zu beseitigen bzw. verständlich zu machen:

• Die Software → Welche Software genau?
• hier → Wo ist hier „hier“? Wenn jemand in der anderen Seite des Raumes sitzt, wird das vielleicht als „da“ interpretiert? Das haben wir schon in der Sesamstraße gelernt: https://www.youtube.com/watch?v=Z-MRqTJMapY
• hier → „hier“ ist in diesem Fall vielleicht nicht nur eine Frage nach dem „wo“ sondern auch nach dem „wann“?
• eine Meldung → Was für eine Meldung? Was sagt die Meldung aus? Wie sieht sie optisch aus? Wie verhält sie sich?

Würden wir nun noch die Bedingungen für eine Bewertungs- und Priorisierungs-Skala hinterfragen und einfließen lassen, auch wenn wir sie eigentlich losgelöst von der eigentlichen Anforderung betrachten wollen, dann:

• großer Aufwand → Ab wann ist ein Aufwand zu groß? Ist die Umsetzungsdauer gemeint oder der Ressourcen-Aufwand? Und wenn ja, wie viel davon?
• Könnte → Wenn Aufwand zu groß, was dann? Was bedeutet könnte? Gar nichts machen oder eine einfachere Lösung umsetzen oder erst Rücksprache oder machen wir das vom Wetter abhängig?

Aus

„Die Software gibt hier eine Meldung aus.“

könnte man bspw. folgendes machen:

„Der Content Editor zeigt beim Speichern eines Artikels eine Meldung ‚Artikel erfolgreich gespeichert‘. Das Fenster ist ein Standard-Alert-Fenster mit weißer Schrift auf rotem Hintergrund. Das Fenster schließt sich nach vier Sekunden selbständig oder das Fenster schließt sich sofort bei beliebigem Mausklick. Umsetzung nur, wenn Aufwand <= 2 Personentage und Umsetzungsdauer <= eine Woche.“

Bzw. gliedern wir die Entscheidung, ob etwas getan werden soll in unsere Bewertungs- und Priorisierungs-Skala aus und setzen das Ganze noch etwas mehr als Stichpunktliste, um die Umsetzung später deutlich besser abnehmen zu können (Akzeptanzkriterien, Testszenarien), dann:

1. Der Content Editor zeigt beim Speichern eines Artikels eine Meldung ‚Artikel erfolgreich gespeichert‘.
2. Das Fenster ist ein Standard-Alert-Fenster mit weißer Schrift auf rotem Hintergrund.
3. Das Fenster schließt sich nach vier Sekunden selbständig.
4. Das Fenster schließt auch bei beliebigem Mausklick.

Was haben wir alles gemacht?

• Nicht hilfreiche Floskeln entfernt.
• Unpräzise Anforderungen eindeutig gemacht
  • gestückelte, kleine Sätze
  • schwammige oder unklare Anforderungen wurden ausformuliert
• Listen bringen Verständlichkeit, bessere Testbarkeit und bessere Abnahme-Möglichkeit
• Nummerierungen (bzw. eindeutige und globale IDs) bringen Transparenz in Abhängigkeiten und Zusammenhänge.
  Man kann mit IDs eindeutig Anforderungen verknüpfen und auch viel transparenter drüber sprechen.

Wer muss das alles tun?

In etablierten Projektstrukturen gibt es eine Kompetenz-Ebene mit der Bezeichnung „Requirements-Engineering“ oder bei Abneigung gegen Anglizismen heißt es dann Anforderungsmanagement. Gibt es diese nicht, turnt meist eine übergreifend anayltisch und konzeptionell qualifizierte Projektmangement-Instanz durchs Projekt. Die machen das, was da oben steht. Teilweise in stunden-/tagelangen Workshops mit den Stakeholdern, indem alles hinterfragt und finalisiert ausformuliert wird.

Bei vielen mir bekannten Firmen ist das ein wenig anders. Es gibt nahezu keine gewerkeübergreifende Analyse- und Konzeptionskompetenz und auch keine für diese Tätigkeit abgestellte Personenmenge. Und das schon gar nicht auf Detailebene. Dazu kommt eine Vielzahl an Anforderungsstellern, die auf verschiedenste Zielsysteme schießen. Bei der Menge an Personen und Anforderungen können die Anforderungen nicht von einer Person aufgenommen, analysiert und konzeptionell finalisiert werden. Das ist von der schieren Menge her nicht machbar. So müssen Anforderungen bereits von den Stakeholdern oder eine spezialisierten Gruppe an Stakeholdern zumindest annähernd in der o.a. Qualität formuliert werden.

Das bedeutet?

Hört auf zu schwafeln und bitte, danke, hätte, könnte in Anforderungen prosaisch zu verpacken. Bringt es auf den Punkt. Sagt, was gefordert ist.