MastersForum

In der Praxis sind die Grenzen m.E. ziemlich fließend und genaue Abgrenzungen gibt es nicht.

Dennoch würde ich von einem Consultant erwarten, dass sich sein Schwerpunkt mehr in Richtung Konzeption, Architektur und fachliche Arbeit verschiebt, anstelle reiner AE (also Programmierung).

Wenn Du Deinen Focus langfristig weniger in der rein technischen Umsetzung siehst, sondern mehr konzeptionell arbeiten möchtest, ist das schon der richtige Weg.

Mit Betriebswirtschaft hat das eher weniger zu tun und betriebswirtschaftliche Aspekte kommen idR erst im Projektmanagement hinzu. Software Consultant heisst aber nicht, dass Du zwangsläufig in Projektmanagement gehst. Man macht sicherlich auch mal Aufwandsschätzungen o.ä., aber das hängt stark davon ab, wie Euer Unternehmen organisiert ist (eher groß: es gibt für jeden Quark Spezialisten, eher klein: man macht von allem etwas).

Die genauen Definitionen und Profile unterscheiden sich überall und es gibt die verschiedensten modischen Bezeichnungen. Am ehesten kann Dir Deine Firma erklären, was sie sich unter einem Software Consultant vorstellen.

Wenn das Geld stimmt, mach es

Da "Software Consultant" keine geschützte Berufsbezeichnung ist, sondern mal für das eine, mal für das andere benutzt wird, wird Dir niemand eine Antwort darauf geben können was Dein Arbeitgeber darunter versteht, ausser er selbst natürlich. Man findet unter dem Oberbegriff Software Consultant Stellenanzeigen zu genau dem Thema welches Du in Zukunft nicht machen möchtest (Softwareentwicklung) aber auch zu Projektmanagement Aufgaben oder irgendwelchen Mischformen. Wenn Dir Dein Arbeitgeber ein entsprechendes Angebot gemacht hat, dann wird er doch auch Informationen dazu haben, was er ausbilden will. Oder Du hast schon genaue Vorstellungen, was Du später machen möchtest. Dann sprich mit Deinem Arbeitgeber drüber und schau, wie es sich mit den Plänen des Arbeitgebers deckt.

Oder anders gefragt: Wo möchtest Du denn hin und wann möchtest Du Dein Ziel erreicht haben?

Projektmanagement ist mit Sicherheit nichts triviales, was (bitte nicht falsch verstehen) jeder, der sein Studium erfolgreich abgeschlossen hat und 1 Jahr Praxiserfahrung hat aus dem Ärmel schüttelt. Die erfolgreichen Projektleiter / Projektmanager, die ich bisher kennengelernt habe (gibt natürlich auch viele Laberköpfe, die glauben alles zu können aber eigentlich nichts wirklich zustande bekommen) hatten allesamt fundierte Praxiserfahrungen - nicht nur im Informatikbereich bzw. in BWL allgemein, sondern auch ganz spezifisch in der Branche und dem direkten Umfeld in dem sie tätig waren.

btw: Warum kommt bei solchen Fragen eigentlich immer jemand daher und gibt Plattheiten ala "Wenn das Geld stimmt mach es" von sich? Ist doch ausgemachter Blödsinn, langfristig gesehen ist es nicht das Geld alleine, welches einen Job reizvoll macht.

Consultants ist für mich ein Synonym für Verkäufer, nur eben in der IT

Geld!!!

Alles in Ordnung, Max?

Zitat

Original von WW_Asmodean
Consultants ist für mich ein Synonym für Verkäufer, nur eben in der IT

Nein, das ist schwerpunktmäßig der Vertrieb.

Natürlich wird man auch als Berater sich und sein Unternehmen (bzw. dessen Produktpalette) verkaufen, aber normalerweise ist dem Kunden bereits eine Leistung verkauft worden, die der Consultant nun erbringt (sei es Analysen, Konzeption, Architektur, Realisierung, Test, QS).

Ein Consultant erbringt eine Dienstleistung, ein Verkäufer verkauft (Handel).

Ein Softwareconsultant kann aber auch einer sein der NUR programmiert. Meist projektbezogen aber das ist dann echt nen stupider Job....

In vielen erfolgreichen Softwareschmieden ist es so das man Consultant nur über den Weg des Projektmanagers werden kann. Ein Consultant ist IMHO eher ein Berater - er benötigt zwar ein hohes Maß an Know-How die eigene Software betreffend, es schadet auch nichts wenn er technisch versiert ist - aber mit den technischen Details setzt er sich im Regelfall nicht auseinander. Er ist oft auch dafür zuständig die Kundenwünsche auf die eigene Software zu mappen, oder den eigenen Leuten diese Wünsche verständlich zu kommunizieren. Er sollte sich also in der jeweiligen Branche des Kunden sehr gut auskennen.

Die Aufgaben sind sehr unterschiedlich, sehr stark abhängig davon ob man ein fertiges Produkt vertreibt oder ob man ein Systemhaus ist.

Ich bin in einem ganz ähnlichen Umfeld wie du, reine Programmierschlampe zu sein ist sicher nicht sehr erfüllend. Aber schon Projektmanagement und/oder die Architektur von Software verlangt einiges an Erfahrung ab und bietet äusserst spannende Herausforderungen. Meist sind diese Berufsbilder auch ineinander übergreifend.

Für meine Begrifflichkeit kommt ein guter Consultant also eigentlich immer aus dieser Ecke, gerade im Java (Enterprise) Umfeld. Eine simple "Ausbildung" oder auch ein "Studium" reicht aber bei allen genannten Berufsbildern nicht aus.

Im Prinzip sind die besten Leute diejenigen welche sich _alle_ dieser Hüte aufsetzen können ;-)

Ein Architekt welcher die Fachlichkeit nicht verstanden hat wird nur Müll produzieren. Ein Consultant welcher die technische Seite nicht kennt, wird Sachen versprechen die mehr Aufwand sind als er meint. Ein Programmierer, der keine Ahnung von Software Architekturen, Patterns und den verschiedenen Technologien (gerade in Java gibt es zum Glück so wenige ^^) hat, wird nicht sehr selbständig arbeiten können. Und zu guter letzt, ein Projektmanager welcher nicht von allem ein bisschen Ahnung hat, wird das Projekt gegen die Wand fahren.

Aber wie schon geschrieben, diese Berufsbilder sind nicht klar getrennt - und gerade bei einer 20 Mann Firma wird man sich wohl mehrere Hüte aufsetzen. Was abwechslungsreicher ist, und auch mehr Spaß macht.

Ich nenne mich zum Beispiel Software Entwickler - und mache über das Projektmanagement, über die Architektur bis hin zur Programmierung eigentlich alles (bei eigenen Projekten). Bei Fremdprojekten setze ich mir oft nur den Hut auf der gerade gebraucht wird, aber meistens - leider - brauchen diese Projekte genau diese Kombination. Weil irgendein "Entscheider" meinte es reicht für ein mittelgroßes Projekt irgendeinen PHP Frickler in der Schule anzuheuern. Aber das ist OT ^^

Jedenfalls ist ein "Programmierer" in meinen Augen alles andere als ein "Software Entwickler"

Zitat

Original von kOa_DrohhyN_

@methadon: Software Developer ist bei uns eindeutig abgegrenzt.

Jo, bei euch, ich habe auch schon mit Leuten zu tun gehabt die von SBS gekommen sind, die nannten sich Software Consultant und wurden von Projekt zu Projekt geschickt in ganz Deutschland und mussten dann echt das programmieren was man von Ihnen verlangt hat.

OK, hier ein Ernstgemeinter Rat:

Fang deine Karriere nicht in einer kleinen Firma an.

Der normale Weg wäre, unten in einer Großen Firma anzufangen, sich etwas nach oben zu arbeiten und nach etwa 2 Jahren in einen mittleren Betrieb wechseln, natürlich auf einen höheren Posten.
Dort wieder hocharbeiten, bis das Maximum erreicht scheint und dann an die Spitze eines kleinen oder "kleineren" mittleren Unternehmen wechseln.

Das scheint so in der Wirtschaft der übliche und erwünschte Weg zu sein.

Angeblich würden grosse Firmen ungern Leute aus kleinen Firmen einstellen, da diese durch zuviel Freiheit und automatischer Verantwortung die Leute angeblich "verdorben sind"

Also direkt in eine grosse Firma einsteigen, ohne Umwege. DIe FIrma will dich formen, und das kann sie nur wenn sie dich frisch von der Uni oder FH bekommt.


So zumindest wurde mir das im Seminar vor dem Praxissemester erklärt und angeblich wäre das in der Wirtschaft die einhellige Meinung.

Zitat

Original von MaxPower
DIe FIrma will dich formen, und das kann sie nur wenn sie dich frisch von der Uni oder FH bekommt.

Soche Denkweisen werde ich NIE verstehen. Lass Dich nie durch eine Firma formen und geh Deinen eigenen Weg. Bist Du gut genug, hast Du keinen Opportunismus nötig.

Karrieremöglichkeiten sind ja auch nur ein Kriterium unter mehreren, und zumindestens imho bei weitem nicht das wichtigste.

Zitat

Original von MaxPower
Angeblich würden grosse Firmen ungern Leute aus kleinen Firmen einstellen, da diese durch zuviel Freiheit und automatischer Verantwortung die Leute angeblich "verdorben sind"

Von wem kamen denn diese Aussagen? Von Deinen Dozenten / Professoren oder tatsächlich von Entscheidungsträgern grosser Konzerne? Ich habe nämlich in der Praxis eher andere Erfahrungen gemacht und sehe eher, dass Mitarbeiter externer Dienstleister, die sich bewährt haben, mit Kusshand genommen werden wenn sie bereit sind zu wechseln.

Natürlich muss man sich seinen Arbeitgeber gut aussuchen. Ein kleines Unternehmen, welches aber Projekte für namhafte Kunden mit interessantem fachlichem Background abwickeln ist sicher nicht die falsche Adresse. Bei einem Unternehmen welches (nur mal ein blödes Beispiel) bspw. Apothekensoftware entwickelt würde ich wohl eher nicht anfangen, wenn es sich vermeiden liesse (und das sollte im Moment für qualifizierte Informatiker nicht schwer sein). Im Hinblick auf Unternehmensberatungen muss man sich halt über eines im Klaren sein: Mit 5 Tagen irgendwo in der Pampa (vom eigenen Wohnort aus gesehen, für mich als Hamburger ist München eindeutig am Arsch der Welt) muss man rechnen und 5 Tage bzw. 4 Nächte im Hotel sind ein gehöriger Einschnitt in die Lebensqualität der sich zumindest in meinen Augen durch Geld nicht wirklich aufwiegen lässt. Aber es gibt ja auch viele Menschen, die genau das gerne machen.

Hört sich allerdings nicht so an, als ob es sich bei dem Arbeitgeber von Drohhyn um eine UB handelt, die ihre Mitarbeiter in der Weltgeschichte rumreisen lässt, denn in dem Falle könnte man ja nichts zum Arbeitsklima sagen, da es öfter mal wechselt.

Zitat

Original von Sheep
Karrieremöglichkeiten sind ja auch nur ein Kriterium unter mehreren, und zumindestens imho bei weitem nicht das wichtigste.

Naja, ehrlicherweise muss man sagen, dass es Menschen gibt, für die Karriere und viel Geld das wichtigste im Leben sind. In meinen Augen eine falsche Lebenseinstellung (ist ja nicht so, dass es sich um ein Spiel handelt, welches man nach seinem Ableben irgendwann einfach neu startet) aber das muss jeder für sich entscheiden.

Zitat

@tam: danke nochmal für deine Beiträge, sie sind sehr aufschlußreich. Da es um ein "Systemhaus" geht (zumindest größtenteils), höre ich aus deinen Aussagen raus, daß wohl eher Vielseitigkeit verlangt wird - genau wie es eben bei der (Individual-)Software nötig ist.

Ja, Vielseitigkeit spielt eine große Rolle. In letzter Zeit geht der Trend so wie ich das sehe definitiv in die Richtung sich die Consultants Projektspezifisch zu holen und Kenntnisse in der Branche vorauszusetzen.
(zB. Consultant im Banken-Umfeld, SAP Consultant in der Automobilbranche, etc)

Für mich käme Consultant desshalb nicht in Frage weil ich zu technik-verliebt bin. Aber da ich selbständig bin brauch ich mir darüber zum Glück nicht mehr den Kopf zerbrechen

Zitat

Daß ich nicht von vorne Herein der Überflieger als Analyst, Software-Architekt, Kundenknuddler, Projektmanager und Dolmetscher sein werde, ist jedem klar.

Die Frage ist ob das dann überhaupt dein Profil ist. Frage lieber bei dem Gespräch sehr genau nach was deine Firma unter einem Consultant versteht. Das wird dir sicher nicht negativ angerechnet, der Begriff Consultant ist einfach viel zu oft belegt.

Zitat

Ich habe zum Beispiel Defizite im Bereich Software-Architektur, Grund dafür ist die Ausbildung (Beispiel: an unserer Fakultät für Wirtschaftsinformatik sind Patterns nur ein Randthema, das ich mir derzeit selbst detailliert erarbeiten muß, weil ich es als notwendig ansehe) auf der anderen Seite habe ich dadurch Vorteile daß ich die Interdisziplinarität schon im Studium kennenlernen konnte und mich nicht erst im Nachhinein damit auseinander setzen muß.

Es gibt nichts was man sich nicht selbst beibringen kann, im Gegenteil. Es hat sogar Vorteile: die Architekturen und Patterns ändern sich rasant. Was du vor 2 Jahren in der UNI gelernt hättest wäre heute schon veraltet. Ich habe nie studiert und es geht auch

Buchempfehlungen:
Johannes Siedersleben - Moderne Software-Architektur
(sehr Aufschlussreich und allgemein gehalten, nicht technologiegebunden aber java-lastig. Beschreibt die QUASAR Architektur von sd&m)

Adam Bien - Enterprise Architekturen
Adab Bien - JavaEE 5 Architekturen
(Beides brauchbare Bücher über Java Enterprise - aber wirklich sehr enterprise-spezifisch)

Zitat

Original von fast_tam
Buchempfehlungen:
Johannes Siedersleben - Moderne Software-Architektur
(sehr Aufschlussreich und allgemein gehalten, nicht technologiegebunden aber java-lastig. Beschreibt die QUASAR Architektur von sd&m)

Ja, ist sehr gut. Es hängt einem zwar irgendwann zum Hals heraus, wenn man seine Studienarbeit darüber schreibt, aber das ist zum Glück ja nicht euer Problem.

Zitat

Original von fast_tam
Im Prinzip sind die besten Leute diejenigen welche sich _alle_ dieser Hüte aufsetzen können ;-)

Ein Architekt welcher die Fachlichkeit nicht verstanden hat wird nur Müll produzieren. Ein Consultant welcher die technische Seite nicht kennt, wird Sachen versprechen die mehr Aufwand sind als er meint. Ein Programmierer, der keine Ahnung von Software Architekturen, Patterns und den verschiedenen Technologien (gerade in Java gibt es zum Glück so wenige ^^) hat, wird nicht sehr selbständig arbeiten können. Und zu guter letzt, ein Projektmanager welcher nicht von allem ein bisschen Ahnung hat, wird das Projekt gegen die Wand fahren.

Grundsätzlich ist eine gewisse universelle Erfahrung sicher von Vorteil, andererseits ist Projektarbeit Teamarbeit. Man kann und soll nicht alles wissen.

Ist das Fachkonzept ausgezeichnet, kann auch der Architekt - ohne jedes Fachwissen - eine zugeschnittene Lösung finden. Ein Consultant, der die technische Machbarkeit im Detail bewerten kann, sollte sich zwecks Aufwandsschätzung Experten hinzuziehen, die es können.

Projekte leiten kann man am besten mit Projektleitungserfahrung. Ich habe selbst Projekte erfolgreich geleitet, wo ich z.B. vorher weder im Fachthema (Sicherheiten), noch von der technischen Systemumgebung (JAVA) Ahnung hatte. So lange die Teammitglieder, Teilprojektleiter einem zuarbeiten, ist das kein Problem. Je größer das Projekt, um so weniger Detailwissen ist erforderlich. Als Projektleiter eines ausreichend großen Projekts (>10 Leute) darf man sich mit fachl. / techn. Details gar nicht auseinandersetzen (gar keine Zeit dafür), sondern muss delegieren und nur die grobe Richtung vorgeben, sich für Entscheidungen entsprechend briefen lassen. Hier sind letztlich nur noch Management-Qualitäten gefragt.

Tam scheint mir als Einzelkämpfer oder in Miniteams unterwegs zu sein, wo der PL voll mit konzipieren/realisieren muss. da sieht das natürlich anders aus.

Aus meiner Sicht:
Consultant =/= PL, PM
aber der Weg zum PL, PM geht idR über den Consultant

Zitat

Ist das Fachkonzept ausgezeichnet, kann auch der Architekt - ohne jedes Fachwissen - eine zugeschnittene Lösung finden.

Um hinterher festzustellen das dieses Fachkonzept eben nicht vollständig oder fehlerhaft war, weil der Kunde falsch verstanden wurde und die Architektur nun an der falschen stelle Flexibilität erlaubt, und an der entsprechenden stelle unflexibel wie ein Stein ist.

Fachidioten, egal welcher Art sind nie von Vorteil

Sicher, ab einer gewissen Projektgröße müssen einfach hochspezialisierte Leute ans Werk. Aber in einem agilen Team ist dennoch der Kunde und das Projektziel im Fokus, und jeder weiß wo es hingehen muss und wieso. Der Software Architekt hat nicht nur ein Fachkonzept sondern spricht im Zweifelsfall auch selbst mit dem Kunden.

Zitat

Projekte leiten kann man am besten mit Projektleitungserfahrung. Ich habe selbst Projekte erfolgreich geleitet, wo ich z.B. vorher weder im Fachthema (Sicherheiten), noch von der technischen Systemumgebung (JAVA) Ahnung hatte.

Sehr gut, das sind mir die liebsten. Keine Ahnung von nichts aber das Projekt leiten ^^

Zitat

So lange die Teammitglieder, Teilprojektleiter einem zuarbeiten, ist das kein Problem. Je größer das Projekt, um so weniger Detailwissen ist erforderlich. Als Projektleiter eines ausreichend großen Projekts (>10 Leute) darf man sich mit fachl. / techn. Details gar nicht auseinandersetzen (gar keine Zeit dafür), sondern muss delegieren und nur die grobe Richtung vorgeben, sich für Entscheidungen entsprechend briefen lassen. Hier sind letztlich nur noch Management-Qualitäten gefragt.

Bei solch großen Projekten ist es meist von Vorteil die technischen Entscheidungen den Leuten zu überlassen welche Ahnung davon haben.. hier spielt der Projektleiter wie du schön sagst eher die Rolle des Managers.

Zitat

Tam scheint mir als Einzelkämpfer oder in Miniteams unterwegs zu sein, wo der PL voll mit konzipieren/realisieren muss. da sieht das natürlich anders aus.

Damit hast du zwar Recht, aber wir realisieren im Netzwerk auch größere Projekte. Das hat aber auch ganz praktische Gründe: je größer ein Team, desto unflexibler und bürokratischer der gesamte Ablauf. Der Overhead frisst mehr Resourcen als die Entwicklung. Es ist erstaunlich wie effizient man mit 3-5 _guten_ Leuten sein kann, und welche Softwareprojekte damit zu stemmen sind.

Wenn allerdings nicht jeder selbst mitdenken würde, bräuchte man wahrscheinlich noch ein paar mehr Leute zusätzlich um alles zu "managen".

Mir ist schon auch klar das in sehr großen Firmen die Prozesse einfach oft vorgegeben sind und es keine alternative gibt. Aber in letzter Zeit hat sich für den Begriff "selbst denken" ein neumodischer, business-kompatibler und trendiger begriff etabliert: Agile Software Entwicklung

Ein agiles Team ist letztendlich nichts weiter als ein verschlanktes, effizientes Team in welchem _jedes_ Mitglied das Projektziel vor Augen hat und die Zuständigkeiten wieder verschwimmen.

Zitat

Original von disaster
Projekte leiten kann man am besten mit Projektleitungserfahrung. Ich habe selbst Projekte erfolgreich geleitet, wo ich z.B. vorher weder im Fachthema (Sicherheiten), noch von der technischen Systemumgebung (JAVA) Ahnung hatte.

Die Aussage wundert mich doch extremst. Ich selber arbeite eher in Projekten großer Konzerne. Das können größere (von Mai 2004-Juli 2007 in einem internationalen Projekt Team mit 25-30 Mitarbeitern) aber natürlich auch mal kleinere Projekte (bspw. Juli 2007-November 2007 in einem kleinen 4 Mann Team) und Einzelaufträge (Dezember 2007 als Lückenfüller zwischen 2 Projekten) sein. Wenn ich mir so von ehemaligen Studienkollegen in entsprechend verantwortlichen Positionen oder auch von Kunden (bspw. grade vor ein paar Tagen ein CMMI Workshop bei einem Kunden) anhöre, wie sie Ihre Projekte optimieren fällt eigentlich immer ein Stichwort: Geschäftsprozessoptimierung. Wie optimierst Du Geschäftsprozesse ohne vom Fachthema auch nur die geringste Ahnung zu haben? In allen gut geführten Projekten in denen ich mitgearbeitet habe war es für den Projektleiter unabdingbar (natürlich immer unter der Prämisse das Projekt zeitlich und auch finanziell optimal zu Ende zu bringen) zu wissen, was sein Team dort tut. Grade in grossen Projekten ist dies wichtig, vor allem wenn es dann noch um Unternehmen geht die nach ISO9000 oder CMMI arbeiten, in irgendwelchen Soloeinsätzen oder Projekten mit ein paar Männchen braucht man keinen Projektleiter mit tiefgreifendem Durchblick, die sind in der Regel überschaubar genug, dass man sie auch ohne Erfahrung einigermassen über die Bühne bringt.

Das ein so geführtes Projekt durchaus trotzdem erfolgreich abgeschlossen werden kann will ich garnicht mal bestreiten, das liegt dann aber weniger am Projektleiter sondern an einem guten Team. Auch nicht, dass ein Projektleiter / -manager nicht jedes Detail wissen muss (kann er auch garnicht) obwohl ein gesunder Background in der Regel hilfreich ist, da ich Dir (bspw. als Teilprojektleiter an den Du delegierst) sonst einen vom Pferd erzählen kann, Du wirst es nicht mal merken, weil Du ja keine Ahnung vom Thema hast. Aber: Wenn man sich mal aktuelle Literatur und die aktuellen Projektmanagementmethoden mal zu Gemüte führt kann ich dort jedenfalls eine Aussage nicht finden: Ein Projektleiter braucht keinen fachlichen Background. In dem Falle ist das in meinen Augen kein Projektleiter, sondern jemand der allenfalls dazu gut ist Geld ranzuschaffen. Im Grunde kann er nicht mal einen Projektplan bzw. Meilensteine entwerfen oder auch nur verifizieren denn: Er hat ja keine Ahnung von dem, was sein Team da macht. Und eine Frage bleibt dann noch: Welchen Nutzen für das Projekt hast Du als Projektleiter ohne fachlichen Background denn wirklich? Das verbrauchen von Resourcen sehe ich nicht als Nutzen

Ich habe schon viele Projektleiter erlebt und jeder von denen dachte natürlich das er seine Arbeit gut macht. Aber man kann sehr wohl Unterschiede feststellen zwischen dem Gewinn den ein Projektleiter für ein Projektteam hat, der weiss wovon er redet und einem, der es nicht wirklich weiss.

Ein Beispiel:

Bei einem Auftrag im Versicherungsumfeld hatte ich einen Projektleiter der

a) hervorragende Branchenkenntnisse hatte
b) hervorragende fachliche Qualifikation (Informatik) hatte
c) hervorragende Programmierkenntnisse (Java / C++) hatte

Der war für mich als Teammitglied mehr als nur hilfreich, weil ich ihm nicht stundenlang erklären musste was ich überhaupt von ihm will. Er wusste wovon ich rede und er wusste wie er mir helfen kann ohne erst 30 Telefonate mit irgendwelchen anderen Mitarbeitern zu führen oder mich das einfach selbst machen zu lassen oder zu delegieren. Ich stell mir grade vor, ich hätte ihm noch die Grundlagen im LV Bereich nahe bringen müssen. Wäre für mich finanziell zwar lohnender gewesen, für das Projekt aber schädlich.


btw: Das hier grad "agiles Team" gefallen ist ein Buchtipp:

Ken Schwaber
Agiles Projektmanagement mit Scrum
Microsoft Press
ISBN 978-3-86645-631-0

Sehr interessant zu lesen selbst für Menschen wie mich, die immer noch gerne "Basisarbeit" sprich Softwareentwicklung machen

Zitat

Original von DS_Don_Grotto
[Die Aussage wundert mich doch extremst. Ich selber arbeite eher in Projekten großer Konzerne. Das können größere (von Mai 2004-Juli 2007 in einem internationalen Projekt Team mit 25-30 Mitarbeitern) aber natürlich auch mal kleinere Projekte (bspw. Juli 2007-November 2007 in einem kleinen 4 Mann Team) und Einzelaufträge (Dezember 2007 als Lückenfüller zwischen 2 Projekten) sein.

Hm, hatte eben einen längeren Text dazu verfasst, der nun im Daten-Nirvana gefressen wurde. Noch mal hab ich keine Lust, daher nur so viel:

2007 hat mich im Wesentlichen ein Migrationsprojekt mit ~400 Mitarbeitern und 50.000 Personentagen beschäftigt. Involviert waren zig Systeme in zwei Großbanken (Darlehen, Sicherheiten, Kundenbasisdaten, ektronische Akte, Buchung, Kontokorrent, Abschluß, DWH usw.) und die unterschiedlichten Systemumgebungen (SAP, Webmethods, Host, DB2, IMS, Oracle, MQseries, Websphere, JAVA, TLANT...)

Da hat weder die Gesamtprojektleitung, noch die TPL detailliertes Fach- oder technisches Wissen, sondern es sind reine Managementskills erforderlich, vergleichbar mit jenen im Top-Management von Unternehmen.

Ich hatte eine TPL auf Kundenseite inne und die Projektleitung aus Sicht unserer Firma (parallel dazu die Projektleitung weiterer kleinerer Festpreise mit interdisziplinären Teams). Das funktioniert hervorragend ohne Detailwissen in den verschiedenen Bereichen.

Eine Gesamtprojektleitung - wie oben - beschrieben traue ich mir (noch) nicht zu, möchte aber mittelfristig dort hin. Dazu muss ich weder alle fachlichen, noch alle technischen Bereich im Detail kennen.

Sei mir nicht böse, aber Dein Beispiel ist doch eher Peanuts und von der Dimension mehr eine TPL oder ein Arbeitspaket. Da schaut es u.U. noch anders aus (aber auch nicht zwingend). Natürlich ist es super, wenn der Projektleiter mehr Teammitglied ist, als Leiter. Ich habe aber auch schon häufiger erlebt oder beobachtet, dass sich PLs zwar bestens auskannten, sogar selbst noch ganz raffinierte Code-/Konzept-Teile geschrieben haben aber keinerlei Managementskills hatten, nicht entscheidungsfähig waren und damit sehenden Auges an die Wand gefahren sind.

Zitat

Original von disaster
2007 hat mich im Wesentlichen ein Migrationsprojekt mit ~400 Mitarbeitern und 50.000 Personentagen beschäftigt. Involviert waren zig Systeme in zwei Großbanken (Darlehen, Sicherheiten, Kundenbasisdaten, ektronische Akte, Buchung, Kontokorrent, Abschluß, DWH usw.) und die unterschiedlichten Systemumgebungen (SAP, Webmethods, Host, DB2, IMS, Oracle, MQseries, Websphere, JAVA, TLANT...)

400 Mann, 50000 Personentage. Ok, das sind natürlich andere Dimensionen, in denen ich mich nicht bewege und die ich nicht beurteilen kann, zumindest nicht von den involvierten Mitarbeitern (50000 Personentage kommen auch in kleineren Teams zusammen, selbst das von mir genannte dürfte schon bei 20000+ Personentagen gelegen haben, allerdings über 3,5 Jahre verteilt). Das in solchen Dimensionen der Gesamtprojektleiter nicht wirklich Ahnung vom technischen Umfeld haben muss sehe ich ein. Allerdings dürfte das für den Großteil der Arbeitnehmer uninteressant sein, für einen Studienabgänger sowieso. Personal- und Führungsverantwortung für solche Projekte bekommt man nicht ohne langjährige Projektmanagementerfahrung und ich bezweifel auch, dass sie Mitarbeitern übertragen wird, die keinerlei Erfahrung mit dem/den involvierten Unternehmen haben.

Grundsätzlich ist halt einfach die Frage wie man Gesamtprojektleiter oder Teilprojektleiter definiert. Ein Teilprojektleiter kann jemand sein, der ein kleines Team von 5-10 Mann leitet, in dem von Dir genannten Beispiel werden es wohl ein paar mehr sein. Der Gesamtprojektleiter für so ein Projekt ist da schon eher mit einem IT-Leiter oder Vorstandsmitglied zu vergleichen als das, was man üblicherweise unter einem Projektleiter versteht. Obwohl ich sagen muss, dass ich von IT-Leitern ohne IT Background genau garnichts halte (einfach schlechte Erfahrungen damit gemacht). Übrigens wollte ich damit nicht sagen, dass fachliche Kompetenz ausreicht, selbstverständlich muss auch Managementerfahrung vorhanden sein und der Projektleiter in der Lage sein Entscheidungen zu treffen, das steht vollkommen ausser Frage. Ich stelle aber nach wie vor in Frage, dass ein - sagen wir mal Managementgenie - ohne fachliche Kompetenz ein Projekt erfolgreich leiten kann. Wenn er, wie Du sagtest, nur delegiert, dann lag sein einziger oder wesentlicher Beitrag halt im delegieren. Der Erfolg des Projektes wird aber nicht davon beeinflusst, ob der Projektleiter ganz toll delegieren kann, irgendwer muss auch in der Lage sein die richtigen Entscheidungen für ein projekt zu treffen und dafür braucht man Fach KnowHow (nicht gleichzusetzen mit Informatik Know How)

Zitat

Original von disaster
Dazu muss ich weder alle fachlichen, noch alle technischen Bereich im Detail kennen.

Hierzu noch kurz: Es ging nicht darum, dass ein Projektleiter alle fachlichen und technischen Bereiche im Detail kennen muss. Du schriebst oben, dass Du sowohl von der fachlichen als auch von der technischen Seite keine Ahnung hattest und das das im allgemeinen für Projektleiter auch nicht nötig sei. Und diese Aussage halte ich für falsch.

Zitat

Original von disaster
Ich habe selbst Projekte erfolgreich geleitet, wo ich z.B. vorher weder im Fachthema (Sicherheiten), noch von der technischen Systemumgebung (JAVA) Ahnung hatte.

Einen solchen Projektleiter halte ich eher für schädlich, auf keinen Fall aber für wirklich hilfreich, was die Projektarbeit betrifft. Allerdings bezogen auf normale Teamgrössen, ich kann beim besten Willen nicht einschätzen, was ein Projektleiter mit Verantwortung über ein 400 Mann Team wirklich zu tun hat und deshalb nicht einschätzen was er wissen muss und was nicht.

Projekte in der Größenordnung sind nicht wirklich selten, jede Grossbank hat etwa 2-3 davon jährlich, vielleicht nicht gleich 400 MA, aber 200-300.

Gesamtprojektleiter für so ein Projekt sind nicht Vorstände oder IT-Leiter sondern Projektmanager. Hiervon gibt es weitaus mehr, als Du vielleicht denkst und gerne werden sie extern eingekauft. Es gibt diverse Weiterbildungen und Zertifizierungen dazu, ich bin z.B. über www.pmi.org zertifziert. Dort kann man sich auch ein Bild machen, was ein PM für Aufgaben hat, bzw. welche Skills er/sie mitbringen muss. Natürlich fängt man mit kleineren Projektverantwortungen an.

Zitat

Original von DS_Don_Grotto

Zitat

Original von disaster
Ich habe selbst Projekte erfolgreich geleitet, wo ich z.B. vorher weder im Fachthema (Sicherheiten), noch von der technischen Systemumgebung (JAVA) Ahnung hatte.

Einen solchen Projektleiter halte ich eher für schädlich, auf keinen Fall aber für wirklich hilfreich, was die Projektarbeit betrifft. Allerdings bezogen auf normale Teamgrössen.

Das beurteile ich aus eigener Erfahrung ganz anders. Auch bei kleineren Teamgrößen muss der PL nicht das fachliche oder technische Knowhow mitbringen.

In unserem Unternehmen sind wir so organisiert, dass kleine Projekte von Projektmanagern in Teilzeit geleitet werden. Ich habe stets mehrere kleine Projektverantwortungen parallel und das klappt sehr gut.

Bei der Aufwandsschätzung und Angebotserstellung hole ich mir die notwendigen Experten hinzu und auch wenn man z.B. kein JAVA kann, ist es aufgrund der Projekterfahrung, die man hat, möglich, in etwa die Schätzungen der Experten zu bewerten und sich ein Bild zu machen. Gleiches gilt für Architektur- und Lösungsvorschläge.
Im Projektverlauf verteile ich die Aufgaben, stelle den Fortschritt fest, bewerte Soll- und Ist-Aufwände aus dem Controlling, kümmere mich um Probleme oder CRs, finde Ressourcen, nehme an strategischen Abstimmunegn teil, Lenkungsausschüssen, Teammeetings, Jour Fixe etc.
Die "eigentliche Projekt-Arbeit", d.h. Konzeption, Realisierung, Test, QS etc., macht bei uns nicht der PL und da hätte ich weder Zeit zu, noch Bock drauf.
Da ich mich immer um mehrere Projekte kümmern muss, muss ich mich gut organisieren, effizient arbeiten, schnell entscheiden können. Aus meiner Sicht funktioniert das ganz hervorragend. Natürlich gibt es in den Teams dann immer noch jemand, der fachlich den Lead hat und sich bei gravierenden Scope-Changes etc. mit mir abspricht.

Bei uns ist ein PM nur PM und keine eierlegende Wollmilchsau... jeder tut, was er am besten kann.

Zitat

Original von disaster

Zitat

Original von WW_Asmodean
Consultants ist für mich ein Synonym für Verkäufer, nur eben in der IT

Nein, das ist schwerpunktmäßig der Vertrieb.

Natürlich wird man auch als Berater sich und sein Unternehmen (bzw. dessen Produktpalette) verkaufen, aber normalerweise ist dem Kunden bereits eine Leistung verkauft worden, die der Consultant nun erbringt (sei es Analysen, Konzeption, Architektur, Realisierung, Test, QS).

Ein Consultant erbringt eine Dienstleistung, ein Verkäufer verkauft (Handel).

Berater, sicher - so offiziell. Inoffiziell sind es Verkäufer oder Leute die man intern nicht mehr gebrauchen kann. Abgeschoben in den Vertrieb. Kann er nix kaputt machen. Arbeite > 10 Jahre in der IT. Projektmanagement, BPM & Autragsvergabe; ... 20 % der Consultants die uns die Firmen schicken taugen was. Der Rest hat entweder keinen Plan oder sind Verkäufer mit Softwarewissen. (ein Staubsaugervertreter mag sich ja auch als Dienstleister verstehen, für mich ist und bleibt er Verkäufer)

Oh man, selten so einen Quatsch von Dir gelesen und Du regst Dich über Pauschalisierungen wie "Bayernfan = Erfolgsfan" auf.

Sorry, aber oben steht genug, dass ich da nicht weiter darauf eingehen möchte. Wenn Eure Firma solche Typen bekommt (und bezahlt), wird sie die auch verdient haben!