Projektmanagement: PRINCE2 - Zertifizierung

[ElBollo]

Hidiho,

bin mich nicht so recht sicher wohin das Thema gehört. Würde ganz gerne eine Projktmanagement-Zertifizierung machen. Da scheint PRINCE2 ja der shit zu sein. Aber irgendwie habe ich da wenig Überblick was es da noch so gibt... PRINCE2 scheint man auch regelmäßig erneuern zu müssen?
Wie schwer ist die Prüfung? Reicht da ein 3-tägiger Onlinekurs zur Vorbereitung?

Gibts Alternativen?
Kann hier jemand mit Erfahrung glänzen und mir den Einstieg erleichtern?


Danke!

 

[Shihatsu]

Hab Foundation und Practitioner - beides innerhalb einer Woche geschult und geprüft. Irgendwann dieses Jahr muss ich mal rezertifizieren. Musste halt alle 5 Jahre machen, kleine Prüfung angelegt an den practiti-Krams. Online würde ich sowas nie machen, da gehen die ganzen Tips unter die die (guten) Teacher so geben zum Bestehen der Prüfung - fachlicher Inhalt ist ja nur die halbe Miete.
Foundation is super easy, Practitioner schon schwieriger. Noch nicht wirklich knackig, aber konzentriert rangehen und Erfahrungen mit TÜV-Prüfungen haben hilft sehr.
Als Alternativen kenne ich noch IPM für amerikanische Sachen, oder Six Sigma für eine Ebene drüber, und IPMA für rein deutsche Geschichten. IPM ist schweineteuer, Six Sigma halt für PLs und IPMA bringt international wenig - daher ist PRINCE schon eigentlich gesetzt.

 

[Zweifeuerkraut]

Hab auch Foundation und Practitioner. Vor Ort Kurs lohnt sich schon, da die Hälfte des Kurses darin besteht, dass dir der Teacher beibringt, wie du die Prüfungsfragen lesen und beantworten musst. Ist aber alles Multiple Joice und ich hätte behauptet, rezertifizieren musst du dich alle 3 Jahre.

Wir in der Schweiz machen gerade die Erfahrung, dass kein Hahn mehr nach PRINCE2 kräht und alle IPMA wollen. Ab Level B(?) musst du dann auch echte Projekterfahrung vorweisen, bei PRINCE2 machste einfach ne WOche n Kürschen und häkelst dich durch die Prüfung und Basta, egal ob du je ein Projekt in irgend einer Form geleitet hast.

 

[ElBollo]

Thx für die Infos, Jungs! Dann werde ich mich mal nach dem IPMA schlau machen.

 

[parats']

Prince2 ging Ende 2017 auch bei uns durch inkl. diverser Schulungen, soll nicht so schwer gewesenen sein.

 

[Mackiavelli]

Ich hab IPMA Level D also mit Prüfungen und ner eigenen Projektarbeit.

War schon einiges an Aufwand: Anwesenheitspflicht bei den Veranstaltungen, ca 40 S. Arbeit schreiben (ein Wochenende mit fleißig Copy&Paste ) und 2 Tage für die Prüfungen lernen.

Man lernt ein paar nette tools und die ganzen relevanten Begriffe fürs bullshit-bingo und hat noch das nette Zertifikat. Aber wenn dich der Wisch nicht irgendwie nach vorne bringt, würde ich es lieber nicht machen. Das ist halt alles theoretischer Kram.

Prince kam bei mir übrigens nicht gut weg, ist wohl nicht so gefragt, aber ich weiß nicht mehr warum.

 

[TheGreatEisen]

Mal ehrlich, wer braucht so einen Mist und welche Qualifikationen sollen damit nachgewiesen werden?

3-Tages-Kurse, ein MC Test, hört sich nach billigem Titelsammeln an. Jede meiner Veröffentlichungen ist aufwändiger als so ein Käse.

 

[Gelöschtes Mitglied 683020]

Hab das auch so 5-10 der größeren Anbieter (IPMA, Six Sigma [x]-Belt, PRINCE, ITIL, AGILE und hastenichtgehört) in Deutschland gefragt, nachdem die das alle mit Bildungsgutscheinen gefördert haben wollten. So wirklich beantworten konnte das keiner, scheint aber eine Gelddruckmaschine zu sein, wenn man sieht, wie die Anbieter sich gegenseitig ankacken, nur um in den Suchrankings einen Tacken weiter oben zu sein. Beim letzten Check, ob das tatsächlich signifkant was bringt, waren irgendwie (nicht überraschend) keine Daten da. Evtl. noch für ne kleine Firma, die ihre Projektprobleme durch einen Berater "während der inhouse-Schulung" für etwas billiger analysieren lassen kann oder so?

 

[Xantos2]

Neugier-Fragen:
1. Macht ihr es a priori aus Interesse am Inhalt, oder weil es irgendwo gefordert oder zumindest förderlich ist?
2. Im Nachhinein, hat es euch weitergebracht? (Insb. an diejenigen, die vorher schon in der Praxis größere Projekte gemanaged haben -- als Neuling ist ja am Ende jedes solide Training bereichernd.)

 

[Shihatsu]

ITIL ist dann doch schon was anderes. Servicemanagement, Incidentmanagement und co sind bei Providern absolutes Pflichtprogramm, und ohne methodisch geschultes Personal geht es nunmal nicht. Das ganze hat deutlich mehr Hand und Fuss als die restlichen genannten Geschichten, der praktische Nutzen ist hier sehr gut erkennbar - ebenso wie die militärische Effizienz.
@Eisen: Das geht jetzt doch etwas am Thema vorbei. Ja, das ist Titelsammeln, ja das ist teilweise Mist, aber nein, du verkackst bei den aufwendigeren dieser Geschichten (CISP, TISP anyone?) völlig mit deiner Veröffentlichung. Und unvorbereitet ist man als jemand der noch nie Projektmanagement gemacht hat mit dem Practitioner oder ner IPMB auch überfordert. Und ja, das ist natürlich viel Bullshitbingo - nur leider wird genau dieses Bingo von dir erwartet wenn du nem Heini mit KRawatte erklären sollst wo der Break-Even des Projekts liegt, warum du genau diese Leute an diesen Positionen willst oder warum der Kunde möglichst nicht wissen soll das das Ding ne höhere interne Laufzeit hat als besprochen. Manager stehen nunmal auf den Scheiss. Und das Zeug schult darin deren Scheiss zu verstehen und zurückspielen zu können.
Nen Kumpel von mir hat IPMA mal bei ner 3-wöchigen Inhouse Schulung inklusive Excel, Project und ITIL gelernt - das fand ich eigentlich von der ERzählung her sehr cool, der ist danach mit 3, 4 netten Templates rausgegangen. Leider ists selten so praxisorientiert.

 

[parats']

Da muss man Shi beipflichten, ITIL ist mal absolut kein Vergleich zum dem ganzen Projektgedöns und bringt sogar einen Mehrwert im Serviceprovider Bereich.

 

[ElBollo]

Aus meiner Sicht definitiv Titel sammeln, der Praxisbezug hält sich in Grenzen. Richtig was für meinen Job haben mir damals nur meine Oracle DBA Zertifizierungen gebracht. Der ISTQB z.B. und später der IREB war eigentlich nur damit ich ihn habe... so wirklich was gelernt für später habe ich da nicht. Das war dann Hands on. PM mache ich ja auch schon einige Jahre...
Genau so sehe ich auch die PM-Zertifizierung. Daher wäre mir etwas mit geringem Aufwand ohne Verjährung am liebsten.
Ja. Titel-Bullshit-Bingo, aber so läufts nun mal wenn Du beim Kunden aufschlägst.
Welcome to Germany.

 

[Zweifeuerkraut]

Ich würde ITIL nicht über Projektgedöns stellen. Ist in seiner Form auch nur ein Framework und wird selten in Reinkultur betrieben. Wenn eine Firma ihre Projekte nach PRINCE2 bzw. nach einer anderen Projektmethode abwickelt, dann macht es durchaus Sinn, sich als (angehender) Projektleiter darin schulen zu lassen. Macht keinen Monster-Projektleiter aus dir, aber du weisst anschliessend welche Rollen und Zuständigkeiten es in einem Projekt gibt und wozu all die Produkte in so einem Projekt dienen.
Wenn die Firma natürlich keine Projektmethode im Einsatz hat, bringt die Zertifizierung ohne zusätzliche Erfahrung wenig bis gar nichts.

Aber gerade PRINCE2 muss sich sicher den Worwurf gefallen lassen, sehr theoretisch zu sein (eine Methode eben und nicht mehr). Du bekommst im Kurs also weder irgendwelche Tools noch Vorlagen (wir haben unter der Hand welche vom Teacher bekommen). Kannste dir dann alles selber aufbauen. Ist bei ITIL aber imho nicht anders, kriegst ja auch kein Ticketing System und keine CMDB mit auf den Weg.

Auf eine gewisse Art ist es also Titel-Sammeln, aber oftmals wird es (in der Schweiz zumindest) einfach gefordert. Sei das bei einer Bewerbung auf einen Projektleiter Job oder als Berater bei der Ausschreibung eines Mandates (z.B. mind. IPMA Lebel B und 2 Projekte mit mind.1 mio Personal-Budget). Beweist zwar nicht, dass du es kannst, aber du hast immerhin schon mal davon gehört und hast genug gelernt um eine Prüfung dafür zu bestehen).

 

[deleted_24196]

Spoiler

Am Ende der Woche prüfe ich, was ich erledigt habe und was offen blieb. Von den offenen übernehme ich den einen Teil in die Folgewoche etc. pp.

Also ne Todo List bloß in Fancy? Hört sich genauso Hip an wie "agiles Projektmanagement".

 

[ElBollo]

Also ne Todo List bloß in Fancy? Hört sich genauso Hip an wie "agiles Projektmanagement".

Bis Du PM oder im Entwicklungsprozess involviert?
Jetzt bin ich aber mal gespannt was Du Dir unter agilem Projektmanagement vorstellst und warum das scheisse ist. Und bitte ohne vorher zu spicken...

Nutzen das seit Jahren, funktioniert wunderbar, obwohl wir nach außen, wie nahezu jeder, mit Festpreis arbeiten müssen.

 

[piko]

mir reicht zur planung ein schnödes textfile, setze mich da i.d.r. sonntags hin und plane während der arbeitszeit die kommende woche durch. prioriäten ergeben sich anhand der wochentage, bzw. logischer deadlines wie korrekturfristen oder festen terminen.

 

[deleted_24196]

Bis Du PM oder im Entwicklungsprozess involviert?

Ich bin der Leidtragende, der die "tollen Ideen" und "kurzfristigen Richtungsänderungen" umsetzen muss.

Jetzt bin ich aber mal gespannt was Du Dir unter agilem Projektmanagement vorstellst

Scrum.

und warum das scheisse ist. Und bitte ohne vorher zu spicken....

Weil sich keiner mehr Gedanken macht, was die aktuelle Änderung oder Anforderung für langfristige Folgen hat. Heute hü, morgen hott. In der Sprintplanung kommt Anforderung A vom Kunden, Anforderung A wird innerhalb des Sprints umgesetzt, in der nächsten Sprintplanung wird Anforderung B in den Raum geworfen, welche allerdings mit Anforderung A kollidiert. Also wird A leicht abgeändert, damit B funktioniert. Wieder in der nächsten Sprintplanung kommt der Kunde mit Anforderung C um die Ecke, welche nahezu 1:1 Anforderung A entspricht, nur anders formuliert und in Feinheiten etwas anders funktioniert. Man hat nahezu 4 Wochen verschenkt, nur um wieder an der gleichen Stelle zu stehen. Hätte man sich vorher mal vernünftig Gedanken darüber gemacht, aber ne, das wäre ja nicht "agil" und "hip".

 

[Valhalla]

Weil sich keiner mehr Gedanken macht, was die aktuelle Änderung oder Anforderung für langfristige Folgen hat. Heute hü, morgen hott. In der Sprintplanung kommt Anforderung A vom Kunden, Anforderung A wird innerhalb des Sprints umgesetzt, in der nächsten Sprintplanung wird Anforderung B in den Raum geworfen, welche allerdings mit Anforderung A kollidiert. Also wird A leicht abgeändert, damit B funktioniert. Wieder in der nächsten Sprintplanung kommt der Kunde mit Anforderung C um die Ecke, welche nahezu 1:1 Anforderung A entspricht, nur anders formuliert und in Feinheiten etwas anders funktioniert. Man hat nahezu 4 Wochen verschenkt, nur um wieder an der gleichen Stelle zu stehen. Hätte man sich vorher mal vernünftig Gedanken darüber gemacht, aber ne, das wäre ja nicht "agil" und "hip".

Das Problem ist doch nicht das da niemand Bock hat sich vorher Gedanken zu machen, sondern das die Anforderungen zum Planungszeitpunkt überhaupt noch nicht abschließend klärbar sind.

 

[n00dl]

vielleicht sollten wir mal ein projektmanagementthread machen :->
wobei so ne fancy bulletpoint liste sicher nicht in der liga von scrum/lean/sprint/whatever spielt sondern eher zum managen der eigenen zeit und prio. dafür habe ich in den letzten jahren eigentlich ein zim wiki genutzt, das hat viele vorteile, aktuell vermisse ich aber doch sehr eine über mehrere plattformen synchronisierte lösung...

 

[Clawmens]

Also ne Todo List bloß in Fancy? Hört sich genauso Hip an wie "agiles Projektmanagement".

Da plant man deutlich mehr als beim normalen Projektmanagement.

 

[parats']

Weil sich keiner mehr Gedanken macht, was die aktuelle Änderung oder Anforderung für langfristige Folgen hat. Heute hü, morgen hott. In der Sprintplanung kommt Anforderung A vom Kunden, Anforderung A wird innerhalb des Sprints umgesetzt, in der nächsten Sprintplanung wird Anforderung B in den Raum geworfen, welche allerdings mit Anforderung A kollidiert. Also wird A leicht abgeändert, damit B funktioniert. Wieder in der nächsten Sprintplanung kommt der Kunde mit Anforderung C um die Ecke, welche nahezu 1:1 Anforderung A entspricht, nur anders formuliert und in Feinheiten etwas anders funktioniert. Man hat nahezu 4 Wochen verschenkt, nur um wieder an der gleichen Stelle zu stehen. Hätte man sich vorher mal vernünftig Gedanken darüber gemacht, aber ne, das wäre ja nicht "agil" und "hip".

Dann besorgt euch mal lieber PMs die auch Businessanalysten sind und nicht einfach nur bots die stumpf in MS Project ihre Sprints planen. Effektives Projektmanagement erfordert von allen beteiligten eine proaktive Arbeitsweise und Kenntnisse von der Materie. Auch ich habe teils PMs mir gegenüber die etwas verstrahlt sind und wenig Plan haben. Mit entsprechenden Rückmeldung innerhalb der Sprintplanung läuft das aber.

 

[deleted_24196]

Was hat das mit den PM bzw. Scrum Mastern zu tun? Die Anforderungen kommen vom Kunden. Der will agil. Der will nicht mehr wirklich nachdenken, was er am Ende haben will.

Gibt auch nen (imo) guten heise.de Artikel dazu: Missing Link: Agil leben im digitalen Kapitalismus. Teil 1 - Der neue alte Geist des Kapitalismus

Gute Kommentare (Auswahl):

Ist agiles Arbeiten eine neue Bezeichnung für "Flickschusterei"?
Man hat also ein Ziel, aber keinen Plan, wie man das erreichen will, sondern macht erstmal drauf los und aus den Defiziten ergeben sich dann die weiteren Arbeitsschritte.

Wer keine Anforderungen definiert, weiß nicht wo er hin will !
Ständige Anforderungsänderungen (moving targets) führen dazu, dass man sich ständig im Kreis dreht und dabei das System durch ständige Rucksacklösungen verkompliziert.

Agil ist Synonym für Frickelei
Die sogenannten "Agilen" Projekte die ich bis heute erleben durfte waren allesamt nichts weiter als etwas bessere Bastelarbeiten, unstrukturiert, von Launen geprägt und von den spontanen Wünschen der Kunden (könnt ihr das noch schnell mal einbauen) geprägt. Am Projektende hatte man dann eine Software die irgendwas macht, von der keiner mehr wusste warum sie das macht und wo eigentlich steht dass sie das machen sollte, jede Fehlerbehebung hat dann mindestens zwei neue Fehler zur Folge die dann in weitere Bugfixrunden ausarten. Besonders lustig wird es dann wenn man feststellen muss dass die Architektur nicht stimmt und der Endtermin absolut nicht mehr einzuhalten ist weil die Software bestenfalls für die Tonne geeignet ist.

Warum baut man keine Brücken agil ?
Wenn sich Risse bilden, stellt man noch ein paar Holzstützen unter.
Wenn man eine weitere Fahrspur braucht, zimmert man die an die alte Brücke dran.

Warum macht man das nicht ?
Etwa, weil auch ein laienhafter Endkunde den Murks sofort erkennen und ablehnen würde ?

Ich empfinde es als vollkommen unethisch, Auftraggebern und Endanwendern Software auszuliefern, die im übertragenen Sinn genau so aussieht, wie die oben skizzierte Brücke !

 

[Benrath]

Ich find das eigentlich ne interessante Diskussion. Ich hab nichts gegen vernüftiges Projektmangament, aber habe auch bisher noch nie erlebt was Agiles PM ist und keine Vorstellung was der wirkliche Unterschied zu gutem PM sein soll. Das es schlechtes PM gibt ist keine Frage. Für mich setzt gutes PM voraus, dass ein klares Ziel definiert wurde.


Imho könnte das ein Mod rausteilen.

 

[ElBollo]

Finde das auch eine sehr interessante Diskussion.

Ich finde mich bei Morphs Aussagen aber auch noch nicht wieder. Btw. weiß ich nun immer noch nicht was genau Deine Rolle im SCRUM-Team ist, das das "ausbaden muss". Tester, ReleaseManager, Dev, Consulatant, Technical Architect, Functional Architect?

Imho bedeutet Agile nicht, dass man plötzlich das Planen sein lässt und von einer Ecke in die andere taumelt. Und _notwendige_ Anforderungen (wichtiges Kapitel im RE: Fokus/Systemgrenzen) nicht definiert. Der Aggregationsgrad der Anforderungen spielt aber bei Agile eine Rolle. Dafür ist ein gutes Productbacklog nötig. Wo die Reise hin geht, muss man natürlich wissen. Du kritisierst im Grunde nicht Agile, sondern schlechtes Requirements Engineering. Es ist Aufgabe meiner Consultants ein Konzept zu erarbeiten, damit übergreifend einen Konsens zu schaffen und sprunghafte Fach-/Prozessverantwortliche, Entscheider und KeyUser damit an die Kandarre zu nehmen. Und ihnen Konsequenzen Ihres Handelns aufzuzeigen. Klappt mal besser und mal schlechter. Da hängt natürlich dann auch viel von der Qualität der Personen ab, aber nicht umsonst werden die Leute ordentlich bezahlt.

Um in Deinem Brückenbeispiel zu bleiben:
wer noch nicht mal weiß in welche Richtung, wie Groß, für wie viele Autos, LKWs, Züge die Brücke gebaut werden soll, der kann natürlich noch nicht anfangen zu bauen.
Man muss aber nicht direkt klären welche Geländerform, Gullideckel oder welche Randsteine genutzt werden sollen, manche Dinge kann man klären wenn es soweit ist. Ein guter RE muss das im Blick und unter Kontrolle haben.

Und das man sich durchaus mal im Kreis dreht hat agile Entwicklung definitiv nicht exklusiv. Aber das ist halt auch das Gute daran, man merkt das recht schnell durch das Fast Prototyping. Ich habe noch zu Beginn meiner Laufbahn als RE das gute, alte Wasserfallmodell kennengelernt. Mit Pflichtenheften von hunderten von Seiten, wo anschliessend die Key User nur gesagt haben: "DAs kann ich gar nicht mehr abnehmen, das Überblicke ich gar nicht mehr. Wenn ich das Lesen und verstehen muss mach ich erstmal einen Monat nichts anderes mehr. DAs geht nicht."
Schön ist aber das man dem Kunden transparent macht welche Ressource man in einem Sprint hat und das die Entscheidungen des Kunden eben Auswirkungen auf diese Ressourcen und damit den Projektfortschritt haben.

Das Thema Softwareentwicklung ist einfach zu komplex, um es direkt zu erfassen und keine Fehler zu machen. Gerade für fachfremde Menschen, denen geht sehr schnell die Vorstellungskraft aus. Manche fangen dann an zu blockieren, die gefährlichere Sorte nickt plötzlich alles ab. Und ohne Sprintzyklen nach denen lauffähige Artefakte vorhanden sein sollten sind wir dann beim Projektleiter der aus dem 20 Stock fällt und sich bei jedem Stockwerk denkt: "Geil, bisher ist ja noch alles gut gegangen, ich hab es top im Griff!"

 

[tic0r]

Aber öffnet das nicht Missbrauch Tür und Tor? Um bei deinem Beispiel zu bleiben: Du hast also die groben Elemente definiert und bepreist und fängst erst an über Geländer und Gulli zu reden, wenn die Brücke schon zu 90% fertiggestellt ist. Jetzt fragt der Kunde also nach einem einfachen Stahlgeländer und du bietest ihm das dann für einen absurd überteuerten Preis an. Klar, im Beispiel könnte er dann eine andere Firma beauftragen, aber gerade bei Software ist das im Normalfall doch gar nicht möglich? Letztlich kauft er also die Katze im Sack; kann mir nicht vorstellen, dass das gerne freiwillig mitgemacht wird.
Dazu kommt, dass in meinem Bereich die meisten Aufträge über Ausschreibungen vergeben werden und die Vergleichbarkeit dann ja fehlt. Oder versteh ich das irgendwie falsch?

Im Baugewerbe gibt es auch oftmals 500+ Seiten Leistungsverzeichnis. Um das zu entschlanken wird teilweise versucht, auf "funktionale Ausschreibungen" zurückzugreifen. Dabei wird nur noch die gewünschte Funktion definiert, die Umsetzung liegt dann komplett beim AN. Das funktioniert aber vorne und hinten nicht, da das System kein Stück darauf ausgelegt ist. Will sagen: Der Bauherr mischt sich trotzdem ununterbrochen ein und über jede Kleinigkeit wird diskutiert, ob das jetzt Teil der Funktionalität ist oder eines Nachtrags würdig wäre. Totales Chaos meines erachtens nach.

 

[parats']

Der Vergleich mit einem Bauvorhaben ist da vielleicht nicht ganz treffend, da es in der Softwareentwicklung nicht direkte Kosten für verwendete Materialien gibt. build, ship and run.

 

[tic0r]

Stimmt schon, was das ganze imo aber noch einfacher zu missbrauchen macht. Wenn du 1.000.000€ für 1m Stahlgeländer verlangst, hat man über Direktkosten des Materials schonmal einen groben Rahmen, der es offensichtlich absurd macht. Bei Softwareentwicklung bestimmst du aber doch die Kosten eigentlich nur über Zeitaufwände. Kann man da nicht einfach irgendwelche absurd hohen Werte ansetzen, die man letztlich gar nicht weiter begründen muss bzw. kann?

 

[poefan]

Kann man schon, nur wäre man dann wohl seinen Ruf los

 

[Clawmens]

Re: Brückenbeispiel:

Das fängt schonmal falsch an Eine User Story kann niemals lauten "Ich möchte eine Brücke." Evtl. brauchst du garkeine Brücke sondern ein Boot oder eine Seilbahn. DAS findet das agile Vorgehen heraus. Das tatsächliche Bauen der Brücke, also das WIE, das wird auch im agilen Projektmanagement rigeros durchgeplant. In der Realität sehen die meisten Backlogs jedoch tatsächlich so aus "Ich möchte den ersten Abschnitt der Brücke bauen." "Ich möchte den zweiten Abschnitt der Brücke bauen." "Ich möchte die Brücke testen." Das kann natürlich nur schiefgehen.

Generell bedeutet agiles Projektmanagement größeres Overhead durch Planung und durch Schneiden der Planung in kleine Stücke. Man ist also erst einmal ein gutes Stück langsamer. Dafür hat man am Ende eben ein funktionelles Boot und keine vergoldete Brücke (falls ein Boot in dem Fall die beste Wahl ist).

 

[deleted_24196]

Btw. weiß ich nun immer noch nicht was genau Deine Rolle im SCRUM-Team ist, das das "ausbaden muss". Tester, ReleaseManager, Dev, Consulatant, Technical Architect, Functional Architect?

Ich bin Projektmitarbeiter und habe User Stories die ich abarbeite/umsetze (IT-Administration). Keine Ahnung wie genau meine Rolle in Scrum-Sprech heißt.

Vielleicht wird es bei uns im Konzern auch falsch gelebt. Da insgesamt aber eine hohe zweistellige Zahl an Externen dabei ist, und diese noch nie widersprochen haben, denke ich nicht dass wir komplett neben der Spur liegen.

Und natürlich ist ganz grob definiert was am Ende des Projektes bei rauskommen soll: es muss funktionieren

Wow, so much input. Aber nicht selten erlebe ich das von mir oben genannte. Anforderungen, die im letzten Sprint noch ultra wichtig waren, wurden in der nächsten Planung durch eine neue Anforderung ersetzt oder teilweise ersetzt. Dazu kommt dann noch MS Teams, worin die gesamte Projektplanung stattfindet und Dokumentation stattfindet.

Und was auch noch wichtig ist: Agiles Projektmanagement ist Mitbestimmungspflichtig* durch den Betriebsrat!

*ich hoffe das ist das richtige Wort, bin mir nicht mehr ganz sicher (Shi?)

 

[Clawmens]

Ich bin Projektmitarbeiter und habe User Stories die ich abarbeite/umsetze (IT-Administration). Keine Ahnung wie genau meine Rolle in Scrum-Sprech heißt.

Stories sind dem Team zugeordnet, die diese in idealerweise gemeinsamer lösen. Du meinst evtl. Tasks.

Vielleicht wird es bei uns im Konzern auch falsch gelebt. Da insgesamt aber eine hohe zweistellige Zahl an Externen dabei ist, und diese noch nie widersprochen haben, denke ich nicht dass wir komplett neben der Spur liegen.

Die wurden evtl. schon gefeuert.

Und natürlich ist ganz grob definiert was am Ende des Projektes bei rauskommen soll: es muss funktionieren

Wenn ihr Scrum nutzt, tut es das schon nach 2 Wochen

Und was auch noch wichtig ist: Agiles Projektmanagement ist Mitbestimmungspflichtig* durch den Betriebsrat!

Die Idee von Scrum ist, dass man diese ganze Idee mit den vielen Köchen und Abteilungen dadurch beseitigt, dass es genau einen einzigen Product Owner gibt. Mitentschieden kann von Team-Seite bzgl. wieviel ihr pro Sprint erledigt und in welcher Reihenfolge ihr die Stories und Tasks im Sprint umsetzt. Und natürlich wie ihr es umsetzt.

 

[drwilly]

Ich habe noch zu Beginn meiner Laufbahn als RE das gute, alte Wasserfallmodell kennengelernt. Mit Pflichtenheften von hunderten von Seiten, wo anschliessend die Key User nur gesagt haben: "DAs kann ich gar nicht mehr abnehmen, das Überblicke ich gar nicht mehr. Wenn ich das Lesen und verstehen muss mach ich erstmal einen Monat nichts anderes mehr. DAs geht nicht."

Ich hab bis 2010 noch in einer Firma gearbeitet, wo das (erweiterte) Wasserfallmodell das einzig zulässige war und dementsprechend für alle Projekte verwendet wurde. Ich könnte noch mal nachfragen, aber ich glaube fast nicht, dass sich das inzwischen geändert hat.

 

[deleted_24196]

Diese Management-Tools dürften dort, wo man sie einführt, auch das Interesse der Betriebsräte und Datenschutzbeauftragten (sofern vorhanden) wecken. Denn sie verarbeiten personenbezogene Daten und müssten deshalb Bestandteil des betrieblichen Verfahrensverzeichnisses werden. Und sie ermöglichen eine ins Detail gehende Leistungs- und Verhaltensüberwachung der in Scrum-Projekten Beschäftigten. Zum Teil ist das für die operative Kapazitätsplanung durch die Projektmanager zwar erforderlich. Aber die betriebliche Praxis zeigt leider auch, dass mit solchen Funktionen oftmals Missbrauch und Unsinn getrieben wird, falls man keine klaren Regelungen für ihre Nutzung trifft.

https://www.betriebsrat.de/portal/forum-allgemein/t/scrum-agile-methoden-7259.html

 

[Clawmens]

https://www.betriebsrat.de/portal/forum-allgemein/t/scrum-agile-methoden-7259.html

Hört sich mehr nach einem Problem mit dem jeweiligen Software-Tool an. Zettel an der Wand sind recht anonym.

 

[ElBollo]

@Morph: Deinen Job würde ich dann unter dem Technical Architect ansiedeln... je nach Anzahl kann das ja auch ein Team sein. Wobei diese Leute nicht zwangsläufig Teil des SCRUM-Teams sein müssen (ich als PL bin bei uns zum Beispiel kein SCRUM-Mitglied). Wobei man da nicht sklavisch an der Theorie klammern muss. Erlaubt ist was funktioniert und stellenweise muss man dann halt auch mal an die Organisatorischen Gegebenheiten anpassen.

Und der Mann mit der Doppelweste hats ja schon mal richtig angemerkt... das Problem bei Eurem Projekt scheint nicht das agile Vorgehen zu sein, sondern die Anforderungsermittlung (Requirements Engineering). Wenn Du da Leute sitzen hast, die keinen guten Überblick haben und auch dazu neigen heute "hüh!" und morgen "hott" zu sagen, dann hat das Projekt schon mal ein Problem. Wenn dann noch Entwickler/Test dazu kommen die mit Kopf unterm Arm arbeiten, sprich sich eben auch keine Gedanken machen was deren Arbeit gerade für Auswirkungen haben, wird's richtig eklig.
Geht halt nur zusammen.

 

[deleted_24196]

Und der Mann mit der Doppelweste hats ja schon mal richtig angemerkt... das Problem bei Eurem Projekt scheint nicht das agile Vorgehen zu sein, sondern die Anforderungsermittlung (Requirements Engineering).

Es scheint ja aber nicht nur bei uns so zu sein, sondern ist eher ein globales Problem. Schau dir den heise.de Artikel an, insbesondere die Kommentare (ich zitiere bereits einige). Anforderungen von gestern werden für neue Anforderungen über den Haufen geschmissen, und am Ende hat man etwas lauffähiges, wobei keiner mehr weiß warum und wieso etwas so ist, wie es ist.

 

[ElBollo]

Und das ist beim Wasserfallmodell groß anders? Dann plant man ewig, schreibt Spezifikationsdokumente, fängt dann an, um dann beim Abarbeiten der Spezifikation zu merken... shit, so funktioniert das nicht. Meist macht man dann auch erst, typisch menschlich, das Einfache, Klare. Damit man vorankommt. Um am Ende zu merken, dass das alles nicht so passt und die schweren Brocken Projektblocker sind. Und dann beginnt ebenfalls das große Rumdoktoren an der Spezifikation. Nur mit dem Unterschied das schon viel Zeit mit dem schreiben einer großen, relativ nutzlosen Spezifikation und dem Entwickeln von Fragmenten, die plötzlich nicht mehr passen, vergangen ist.

Agil bedeutet nicht Chaotisch. oder alles schnell über den Haufen zu werfen weil das plötzlich so einfach ist. Oder nicht mehr strukturiert zu planen. Agil kann auch nicht hexen. Etwas über den Haufen zu werfen hat immer noch die selben Probleme wie vorher, es verzögert das Projekt. Aber man merkt es deutlich schneller. Ähnlich wie in der LeanProduction wo man mit niedrigen Lagerbeständen arbeitet, damit man schnell merkt wo Probleme sind, da es keine Puffer gibt, die diese Probleme abfedern und verdecken.
Deswegen steht man auch morgens beim Daily zusammen, damit man mitbekommt, wie es im Team läuft. Damit man helfen kann und sich nicht jemand eine Woche zurückzieht, vor sich hin prokrastiniert oder ein Problem nicht in den Griff bekommt, wo jemand anderes mit Expertise vielleicht helfen kann. Auch erzeugt es hin und wieder bei manchen Leuten den notwendigen Druck Gas zu geben

Gibt ja viele Definition, aber für mich bedeutet "Agile" hauptsächlich schnell (Sprintzyklen, bei uns mittlerweile 2 Wochen) und transparent (Taskboard oder wie wohl bei den meisten die Software JIRA) lauffähige Softwarefragmente zu erzeugen.
SCRUM ist dabei eigentlich nur das Vorgehensmodell zur Erzeugung dieses Ziels. Wie Claw sagt, SCRUM funktioniert relativ schnell von selbst. Das ist normalerweise nicht das Problem und auch nicht der Grund für Anforderungen, die ständig über den Haufen geworfen werden. Leuten die das denken, muss man das schnell klar machen.
Und da liegt der Ball bei den RE-Consultants... das meiste meiner Zeit geht für Betreuung und Support von "kritischen" RE-Consultants drauf (auch bei der Softwareentwicklung gilt imho die Rule of ten), bzw. ich mache da einiges selber. Einfach weil es hilft hier wirklich gute Vorarbeit zu leisten (jaja, protz, aber am Ende halte ich für den Kram nun mal den Kopf hin, dann will man es wenigstens als selbst auch verbockt haben).
Auch die vielen Iterationsrunden mit dem SRUM-Team (Schätzrunde, Abnahme, Retropektive) helfen da ungemein die Anforderung zu verbessern. Und der Input macht alle ein Stück weit besser und aufeinander eingestellt. Ich sage immer, dass ein RE-Consultant genau weiß, wann ein Entwickler mit seinen Anforderungen begonnen hat. Dann sollte recht schnell das Telefon klingeln...
Wenn nicht ist es wirklich trivial oder das Team genial.

Vielleicht braucht da Deine Firma mal eine ordentliche Schulung?

 

[Gelöschtes Mitglied 683020]

https://starcraft2.ingame.de/forum/threads/241139-Projektmanagement-PRINCE2-Zertifizierung

inb4 kompletter derail

herren und frauen moderation

 

[Fexx]

Hidiho,

bin mich nicht so recht sicher wohin das Thema gehört. Würde ganz gerne eine Projktmanagement-Zertifizierung machen. Da scheint PRINCE2 ja der shit zu sein. Aber irgendwie habe ich da wenig Überblick was es da noch so gibt... PRINCE2 scheint man auch regelmäßig erneuern zu müssen?
Wie schwer ist die Prüfung? Reicht da ein 3-tägiger Onlinekurs zur Vorbereitung?

Gibts Alternativen?
Kann hier jemand mit Erfahrung glänzen und mir den Einstieg erleichtern?


Danke!

In meinem Bereich (ERP Implementierung) war bis Anfang der 2010er PRINCE2 ganz interessant, als reine Methodik. Allerdings lässt die Nachfrage stark nach. IMPA oder GPM, als komplette "Schulungen", sind nun die coolen Themen.

Richtig interessant werden zurzeit die agilen Sachen, SCRUM, Scrum Master etc. Wobei ich da nicht die Zertifikate auswendig kenne. Diese allerdings werden massiv nachgefragt, auch aus Non-IT Bereichen.

Ich selbst gehe auch letztere Schiene und werde dieses Jahr den Scrum Master angehen.

Letztenendes sind Zertifikate ja nichts anderes als "Signalling". "Hallo Kunde, ich mach sogar mehr als nur Praxis!"...

 

[deleted_24196]

Vielleicht braucht da Deine Firma mal eine ordentliche Schulung?

Mag sein, habe ich auch schon öfters gedacht. Aber wir sind halt nicht soooo klein (im Konzern ~10.000 Mitarbeiter), wir haben massig Externe in div. Projekten und mir kommt es so vor, als wäre das, was ich hier erzähle, Standard in der IT. Grundsätzlich läuft es, wir gewinnen Kunde auf Kunde dazu, alle sind happy, alle sind glücklich. Nur sehe ich verschenktes Potential. Aber vielleicht durchdringe ich diese ganze agile Projektmethodik einfach auch noch nicht...