Es gibt die verschiedensten Fachbereiche. Wenn sie z.B. im Bereich embedded Software Entwicklung engagiert sind, dann ist bereits bei der Festlegung der Hardware- und Software Architektur und bei der Testfall Entwicklung die detaillierte Kenntnis der Anforderungen der entscheidende Projekterfolgsfaktor.

Warum?

Nun, neuerdings reden viele von Scrum, der agilen Projektmanagement Methode. Aber auch, wenn man iteratives Projektmanagement anwendet, ist es wichtig und nicht nur dann, bereits bei Projektbeginn das Endprodukt, die vereinbarte Leistung im Detail zu kennen. Denn durch den iterativen Prozess ist man unter Umständen nur auf den ersten Iterationsschritt fixiert und vernachlässigt wichtige Erkenntnisse für das Gesamtprodukt. Nicht wer sofort anfängt erreicht sein Ziel schneller, nein, wer genau weiß was zu leisten ist, ist klar im Vorteil.

Nebenher gesagt, es scheint so, dass das V-Modell und/oder Wasserfallmodell bereits aus der Mode sind und man vergisst dabei, dass die Requirements auch bei SCRUM die Basis zum Erfolg sind.

Die Anforderungen zu spezifizieren ist nicht immer einfach. Der Kunde schreibt ein Lastenheft, grob ausgedrückt eine Wunschliste an das Produkt, und dass womöglich aufgeteilt in unterschiedliche Funktionen, welche noch dazu von unterschiedlichen Funktions-Verantwortlichen geschrieben wurden. Mit anderen Worten die Anforderungen sind nicht konsolidiert.

Aus diesem Grund sind die Anforderungen des Kunden oftmals sehr unterschiedlich innerhalb eines Produktes und es kann sein, dass so manch ein Wunsch mit unterschiedlichen Worten, in mehreren Funktionen beschrieben ist. Um diese aufzulösen, bedarf es Requirement Engineers welche diese gleichgearteten Wünsche erkennen und in einem Tool bewerten und zueinander verlinken. Zudem ist es dabei wichtig, dass jedes Requirement eindeutig als umsetzbar ist. Dazu empfiehlt es sich die Requirement zu bewerten und mit dem Auftraggeber abzustimmen. Requirement , welche nicht umsetzbar sind, sind ebenfalls mit dem Auftraggeber zu besprechen und zu begründen.

Man kann die Requirements Bewertung wie folgt ausführen:

• Wird umgesetzt
• Bedarf zusätzlicher Informationen
• Kann technisch nicht realisiert werden

Noch ein Hinweis. Mit dem Kunden abgestimmte Requirement  helfen zu einem späteren Zeitpunkt, wenn der Kunde Änderungen möchte, denn dann können sie als Auftragnehmer einen Change Request einfordern, welcher sich Monetär zum Vorteil für ihr Unternehmen auswirken kann. Das Thema Change Request folgt in einem weiteren Kapitel.

Über welche Requirement reden wir im Generellen?

Da sind die Funktionalen Anforderungen und die nicht funktionalen Anforderungen.

Die funktionalen Anforderungen sind diejenigen, welche sehr leicht zu identifizieren sind. Sie beschreiben einen Funktionszustand. Dazu ein Beispiel: Kundenforderung ist, mit dem Lichtschalter neben der Tür muss das Deckenlicht über dem Esstisch eingeschaltet werden können. Diese Aussage ist an und für sich eindeutig, oder doch nicht?

Das funktionale Requirement beschreibt eine Funktion, um jedoch dem Kunden die konkret geforderte Leistung zu erbringen, stellen sich bei dieser Kundenanforderung jedoch viele Fragen.

Offene Fragen sind, welche Spannung soll geschaltet werden? Wo soll der Schalter exakt montiert werden, daher in welcher Höhe und mit welchem Abstand zum Türrahmen. Welcher Schalter Typ, welches Design, wer liefert den Schalter. Und so weiter. Sie sehen, mit der einfachen Aussage des Auftraggebers entwickeln sich viele Fragen, welche es zu klären gibt um den Kundenauftrag erfolgreich umzusetzen.

Hier noch ein wichtiger Hinweis, Anforderungen beschreiben was gefordert ist, jedoch nicht das wie. Daher ein gutes Requirement beschreibt nicht wie eine Funktion umzusetzen ist, sondern welche Forderungen durch die Teams umzusetzen sind.

Der zweite große Block sind die nicht funktionalen Anforderungen. Was verbirgt sich dahinter?

Kurz ausgedrückt, nicht funktionalen Anforderungen beschreiben was ein System, ein Produkt leisten soll.

Daher, nichtfunktionalen Anforderungen an ein System können unterschiedlichster Art sein. Man hat versucht im Rahmen des ISO Standards 9126 unter anderem folgende Typen von nichtfunktionalen Anforderungen (Qualitätsattribute) zu identifiziert:

System Performanz: z.B. wie performant ist ein IT-System, wie lange läuft ein IT-System ohne Absturz etc.

Nutzbarkeit ist ein weiteres Thema. Ein großes Feld, denn bei Produkten schließt es die Funktionalität, die Handhabbarkeit, daher Einfachheit der Nutzung mit ein.

Denkt man an IT-Systeme, dann geht es auch um Portabilität

Und zuletzt, egal bei welchem Produkt oder System geht es auch um die Sicherheit der Menschen, welche mit dem Produkt arbeiten oder in irgendeiner Art in Berührung kommen.

Die Kunst liegt nun darin, dass die Requirement  Engineers die nichtfunktionalen Anforderungen erkennen, diese abstrakten Attribute als messbare Qualitätsattribute festschreiben und mit dem Auftraggeber abstimmen.

Das Ziel ist, für nicht funktionale Anforderungen verlässliche messbare Qualitätsvorgaben zu definieren.

Ein Beispiel für eine nicht funktionale Anforderung. Das System ist leicht zu bedienen. Nun, wie kann man das sicherstellen. Dies ist eine häufig anzutreffende Formulierung, die in Lastenheften festgeschrieben ist. Was bedeutet jedoch leicht zu bedienen?

Sie sehen, funktionale und nicht funktionale Anforderungen sind wichtig und aus meiner Sicht bilden diese das Rückgrat für ein erfolgreiches Projekt.

Gruß

Kurt Jelinek (MSc, Beng.)

Ihr Unternehmen hat neue Projekte aufgelegt und sie persönlich als Projektleiter für ein Projekt auserwählt. Toll, oder auch nicht. Es liegt nun an ihnen das Projekt zum „Fliegen“ zu bringen, daher aufzusetzen, aber was bedeutet das? Jetzt kommt es darauf an ob sie bereits in der RfI und RfQ Phase im Projekt dabei waren und schon gut informiert sind oder ganz von vorne beginnen müssen. Jedoch ungeachtet der Ausgangs Situation sollten sie folgende Fragen stellen und beleuchten.
Ist es ihr erstes Projekt, dann kann es durchaus sein, dass sie sie sich ein wenig überfordert fühlen, auch wenn sie die Projekt-Management-Kurse der unterschiedlichen Anbieter absolviert haben.

Wenn ich ein Projekt aufsetze, dann richte ich folgende Fragen an meinen Auftraggeber:

• Welche Ziele verfolgt das Projekt
• Ist es ein internes oder ein externes Kundenprojekt
• Wenn es ein externes Projekt ist, wer ist der Kunde, wie lautet der Auftrag
• Sollte der Auftraggeber die Fahrzeugindustrie sein, dann möchte ich wissen, wann der vom Auftraggeber vorgegebene Start of Production (SOP) ist.
• Wann soll das Projekt starten, wann muss es abgeschlossen sein
• Gibt es Vorgaben, geplante Iterationsstufen vorgegeben vom Auftraggeber für die Projektphasen
• Sind bereits grobe Meilensteine mit dem Auftraggeber besprochen
• Wie groß ist das Budget
• Welche Mitarbeiter stehen bereits für das Projekt zur Verfügung und wie kann ich die zusätzlichen Fachleute/Spezialisten rekrutieren
• Muss ich das Projekt nur mit internen Mitarbeitern umsetzen oder kann ich externe Mitarbeiter zukaufen

Die Frage, welches Ziel will man mit dem Projekt erreichen ist ein ganz essentiell für die Projekt-Planung. Da in den meisten Fällen die Projektziele sehr global gehalten sind, wird es notwendig sein die Ziele im Detail zu beleuchten, um eine entsprechende personelle Kapazitätsplanung ausführen zu können. In dieser Phase erwarte ich vom Auftraggeber, dass er die Ziele in Form eines Lastenheftes der Projektleitung zur Verfügung stellt. Das Lastenheft, ob intern oder externer Auftraggeber gibt eine grobe Zielsetzung zum Projekt. Erfahrene Projekt-Manager können anhand der Lasten bereits grobe Kapazitätsplanungen durchführen und abschätzen ob das angedachte Budget passen könnte. Budget ist ein Stichwort, denn manche Projekte sind vom Auftraggeber mit einem Budget ausgestattet, bei manchen Projekten müssen sie planen und dann das Budget beantragen. Sie sehen, es geht so oder auch so rum.

Projekte aus der Automobil-Industrie sind ein etwas anders geartetes Kaliber im Bereich Projekt-Management. Warum? Nun, wenn man für die Automobil-Industrie eine Fahrzeugprojekt aufsetzt, dann ist der Termin Start of Production das Projekt-Ende-Datum, aber aufgepasst, wenn sie ein Produkt liefern müssen, dann muss durchschnittlich 6 Monate vor SOP das Produkt fertig sein, damit es den Industrialisierungsprozess durchlaufen kann. Was es zu 99,9% nicht gibt ist, dass der Auftraggeber den Liefertermin verschiebt. Das lässt sich damit erklären, dass in einem Automobil-Industrie-Projekt speziell für ein Neufahrzeug sehr viele Abhängigkeiten sind. Was die wenigsten Ingenieure und Projekt-Manager beachten ist, dass neben der Technik schon die gesamte Werbung für das neue Produkt anläuft und es wäre extrem peinlich für den Hersteller, wenn er seine werblichen Ankündigungen zurücknehmen muss.

Die meisten der zu planenden Projekte werden in unterschiedliche Projektabschnitte unterteil, wann der Auftragnehmer eine bestimmte Leistung erhalten soll bzw. welche Leistungen zu einem Zeitpunkt geliefert werden müssen. Hier kann ich nur einen Tipp abgeben. Stellen sie bereits bei Projektbeginn sicher, dass sie den gesamten vereinbarten Leistungsumfang kennen, das gilt speziell für Entwicklungsleistungen im elektronischen Hardware und Software Bereich. Nichts ist schlimmer, als wenn sie im Zuge der nächsten Leistungsstufe erkennen müssen, dass die bisher geleistete Arbeit als Basis nicht ausreicht, die Hardware für die nächste Stufe nicht passend ist, der Softwareumfang zu groß wird, die Flashzeiten zu lange dauern und so weiter. Daher Sorgfalt beim Projekt aufsetzen.

Ein weiterer Punkt ist die Mitarbeiter Auswahl. Sie werden in den ersten Projektphasen erkennen welche Mitarbeiter, Ingenieure in welcher fachlichen Ausprägung sie für das Projekt benötigen, die exakte Anzahl lässt sich erst bei der Entwicklung der Arbeitspakete und Terminpläne ermitteln.

Daher aufgepasst, stellen sie vor dem Aufsetzen eines Projektes die richtigen Fragen, denn ein Projekt fährt schneller an die Wand als oftmals aufgesetzt. Deshalb wünsche ich ihnen viel Erfolg und einen guten Start.

Gruß

Kurt Jelinek (MSc, Beng.)

Nehmen wir an, sie sind verantwortlich für ein Projekt und sie müssen nun ein Team von Spezialisten zusammenstellen. Meistens hat man wenig Zeit und möchte die Besten für die Aufgaben. Wie findet man mit sehr geringem Zeitaufwand die geeigneten Mitarbeiter für ein Projekt?

Haben sie sich bereits einmal Gedanken darüber gemacht, wie man am effizientesten vorgeht um die geeigneten Spezialisten für das Projekt zu bekommen. Kenn sie eine Methode mit der sie in sehr kurzer Zeit folgendes über den Kandidaten oder die Kandidatin erfahren. Klar, sie haben das Profil angefordert und gelesen. Stimmt das was im Profil steht. Können sie durch Interviewtechnik die Fähigkeiten eines Kandidaten oder Kandidatin feststellen?

Gerade im technischen Projektgeschäft ist es extrem wichtig die richtigen Mitarbeiter und Mitarbeiterinnen an Bord zu bekommen. Wie erfährt man treffsicher ob ein Bewerber eine gewünschte Fremdsprache, ggf. auch noch in einer Fachsprache der gewünschten Fremdsprache beherrscht, wie finden sie heraus ob jemand Texte interpretieren und diese visualisieren kann. Und wie steht es um die Präsentation der Ergebnisse, Erklärung des Ergebnisses und Diskussion zum Thema, daher Kommunikationsfähigkeit?

Dieses Dilemma hat mich viele Jahre begleitet. Die Interviews waren zum Teil langatmig, haben nicht in aller Klarheit gezeigt ob der Kandidat die erforderlichen Kenntnisse hat. Eines Tages kam mir der zündende Gedanken wie ich zielsicher die für das Projekt wichtigen Fähigkeiten des Kandidaten herausfinden kann, ohne mich mit den endlosen Fragen im Interview und den Teilweise sehr vagen Antworten abzumühen. Haben sie eine Idee wie man diesen Bewerbungsprozess verkürzen kann?

Für den Bereich Requirement Management, -Engineering, Software- Hardware Entwickler, Konstrukteure und oder Projekt-Manager ist das A4 Verfahren geeignet, welches ich hier vorstelle. Ob es auch für Buchhalter funktioniert, habe ich es noch nicht getestet, dazu fehlen mir persönlich die fachlichen Grundlagen.

Für den A4 Eignungs-Gespräch/Test benötigt man lediglich ein A4 Blatt. Auf dem Blatt steht im Wesentlichen ein kurzer Text, ca. eine viertel Seite lang, in der von ihnen benötigten Sprache. Englisch, Deutsch, was auch immer. Der Text sollte unbedingt mit der Tätigkeit, für die gesucht wird, in Verbindung stehen. Die Aufgabe sollte in sich logisch sein, jedoch nicht unbedingt eindeutig, je nach Fachgebiet. Im technischen Bereich ersuchen sie Ihren Kandidaten, das Gelesene zu visualisieren. Geben sie dem Probanden dazu ca. 10 Minuten Zeit den Text zu lesen um das Thema zu visualisieren. Dire Visualisierung sollte je nach Fachbereich ein Ablaufdiagramm, ein Blockschaltbild, „Use-Case“ sein. Es liegt an ihnen, welche Schwerpunkte sie setzen. Im Anschluss ersucht man den Kandidaten sein Ergebnis zu erklären, daher zu präsentieren. Diskutieren sie mit dem Kandidaten warum er den Text so gesehen hat und zu diesem Ergebnis aus seiner Sicht gekommen ist.

Hinweis: Es gibt kein wirkliches Falsch oder Richtig, denn jeder Mensch liest aus Texten, Vorgaben einen anderen Sinn heraus, außer sie gestallten den Text so, dass dadurch Eindeutigkeit entsteht. Bedenken sie, wenn sie einen Requirement -Engineer suchen, dann sollten sie allgemeine Formulierungen verwenden und die Aufgabe besteht darin, dass der Proband mehrere Eindeutige Mussanforderungen daraus formuliert und dass in der gewünschten Sprache.

Um mit dem A4 Eignungs-Gespräch/Test erfolgreich zu sein bedarf es einiger Vorbereitungen. Überlegen sie zuerst welche Sprache für das Unternehmen wichtig ist, wählen sie ein Thema, dass der Teilnehmer für die ausgeschriebene Position beherrschen muss. Bleiben sie in der Aufgabenstellung ein wenig ungenau, vage, damit der Proband interpretationsspielraum hat, das hilft bei der Präsentation, denn dort wird die Sichtweise des Kandidaten sichtbar und bei der Diskussion, denn dann sehen sie die Kommunikationsfähigkeit des Kandidaten in der geforderten Fremdsprache.

Wozu ist das A4 Eignungs-Gespräch/Test nicht geeignet? Das Thema Teamfähigkeit können sie damit nicht abdecken. Bedenken sie, auch in einem einstündigen Bewerbungsgespräch werden sie als Gesprächsteilnehmer die Teamfähigkeit des Probanden nicht zu 100% feststellen. Es stellt sich auch die Frage warum benötigen sie Teamfähigkeit? Geht es um die Kommunikation mit den Kollegen oder geht es um einen generellen Konsens in Gesprächen. In Entwicklungsteams bevorzuge ich persönlich Mitarbeiter, welche klar zu deren fachlichen Meinung stehen, diese kommunizieren können und keine „gedankenlose“ Mitläufer sind.

Gruß

Kurt Jelinek (MSc, Beng.)

Nehmen wir an, als Unternehmen wurden sie zum Request for Information eingeladen, und sind unter den letzten drei Kandidaten, welche jetzt aufgefordert sind, den Request for Quotation auszufüllen, das bedeutet ein konkretes Angebot abzugeben. Bereits in dieser Phase sind viele Projekte zum Scheitern verurteilt. Warum denn das?

Dafür gibt es einige gravierende Gründe.

• Das Unternehmen ist von sich so überzeugt, dass es meint trotz fehlender Expertise, ggf. durch Zukäufe, in der Lage zu sein das Projekt zu stemmen
• Das Unternehmen möchte den Auftrag, ungeachtet dessen was es kostet.
• Der häufigste Grund ist, dass man in der Phase „Request for Quotation“, kurz RfQ, zu wenig in die Anforderungsdetails investiert

Was heißt das?

Das Anforderungsmanagement, zu neudeutsch Requirement Engineering, ist notwendig um die gesamten Anforderungen an ein Produkt zu kennen. Früher aber auch heute noch, haben Unternehmen Lastenhefte entwickelt und der Auftragnehmer hat daraus ein mit dem Kunden abgestimmtes Pflichtenheft entwickelt. Im Pflichtenheft stehen die detaillierten mit dem Kunden abgestimmten Anforderungen.

Gerade bei der Neuentwicklung von Produkten ist eine detaillierte Kenntnis der Kunden Requirement unverzichtbar, und da ist der Casus knacksus. Nur anhand der im Pflichtenheft festgeschriebenen und mit dem Kunden abgestimmten Requirements kann ein profundes Angebot, was heutzutage als RfQ bezeichnet wird, abgegeben werden. Diese detaillierten Anforderungen im Pflichtenheft sind notwendig, um den gesamten Projektaufwand und die Kosten einzuschätzen.

Ja, es ist großartig wenn man als Unternehmen nominiert wird und nun beginnt die nächste Phase im Projekt, das Planen, die passenden Mitarbeiter rekrutieren, das Projekt aufsetzen. Dabei geht es auch um die Projekt-Management Methoden, welche zum Einsatz kommen sollen oder werden. Neuerdings werden viele Projekte mittels Scrum Methode aufgesetzt, jedoch kann auch Scrum die fehlenden detaillierten Requirements nicht wettmachen.

Genau an diesen fehlenden exakten Requirements scheitern viele der Projekte, ungeachtet der Projekt-Management Methode. Denn viele der Projekte bei denen ich zu einem späteren Zeitpunkt als Interim-Manager engagiert wurde, standen wegen der Fehleinschätzungen der Kosten, der fehlenden detaillierten Requirements bereits in tiefroten Zahlen und waren bereits erheblich im Zeitverzug. Die Risiken das Projekt erfolgreich zu managen wurden mit jedem Tag größer.

Wie kann man ein Projekt retten, welches sich in der Schieflage befindet?

Dazu gibt es kein Allheilmittel. Aus meiner Sicht ist der erste Schritt, die Anforderungen mit dem Kunden umgehend zu verifizieren, denn nur anhand eindeutiger Requirements können die Entwickler die Anforderungen erfüllen. Und es geht weiter, anhand der präzisen Requirements, kann und muss das Testteam die Teststrategien entwickeln.

Warum ist Eindeutigkeit unumgänglich?

• Der Ausführende einer Aufgabe weiß genau, welche Ergebnisse von ihm bzw. vom Team erwartet werden
• Die Rückfragen, um die Unklarheiten der Aufgaben zu klären, werden drastisch verringert
• Die Zeitschiene, der Zeitaufwand sind durch genaue Aufgaben leichter einzuschätzen
• Risiken für einzelne Entwicklungsschritte sind besser vorhersehbar

Mit anderen Worten, es lohnt sich in die Anforderungsanalyse in jeder Phase, ob beim Angebot oder im Projekt, viel Zeit und Wissen zu investieren.

Fest steht die Auftraggeber schreiben in den meisten Fällen ein sogenanntes „Wunschkonzert“ aus, welches sich bei genauer Betrachtung als teilweise schwer zu realisierende Gesamtaufgabe erweist.

Gruß

Kurt Jelinek (MSc, Beng.)