Zum Inhalt springen

Wie laufen bei euch Kundenprojekte ab?


carstenj

Empfohlene Beiträge

Hi,

momentan läuft es bei uns so, dass unsere Kunden mit meinen Vorgesetzten sprechen, die kaspern dann die Termine und die Details ab, und ich bekomme dann die Infos was wann und wo zu tun ist. Ich habe, bis ich zum Kunden fahre, eigentlich nie wirklich mit ihm gesprochen.

Nur leider fehlt da oft was, die Infos sind unvollständig und ich stehe beim Kunden wie der Depp da. Sowas passiert natürlich immer mal, ist aber nun zum wiederholt Male vorgekommen.

Manchmal werden Dinge auch nur zwischen "Tür und Angel" besprochen, was natürlich auch überhaupt nicht geht. Wenn ich sowas anspreche, wird das eher runtergespielt. Ich bin kein Projektleiter, sondern nur der Durchführende, aber irgendwie habe ich das Gefühl, dass die Vorgehensweise in unserer (kleinen) Firma nicht optimal ist.

Ich dachte dann, dass es sinnvoller wäre, wenn ich grob wüsste, worum es überhaupt geht und die Details, Termine etc. dann selber mit dem Kunden abstimme, damit eben keine Infos verloren gehen. Aber irgendwie scheint das auf taube Ohren zu stoßen.

Wie sind eure Erfahrungen diesbezüglich? Wie läuft das bei euch ab? Da ich bisher immer Inhouse gearbeitet habe, habe ich mit Kundenprojekt(ch)en eher weniger Erfahrung.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich dachte dann, dass es sinnvoller wäre, wenn ich grob wüsste, worum es überhaupt geht und die Details, Termine etc. dann selber mit dem Kunden abstimme, damit eben keine Infos verloren gehen. Aber irgendwie scheint das auf taube Ohren zu stoßen.

Kommt mir irgendwie bekannt vor, von meinem alten Arbeitgeber...

Nach einer recht einseitigen "Diskussion" mit einem Vertriebsmenschen, die über zwei Gebäudeetagen deutlich zu vernehmen war, hatte sich die Situation etwas gebessert. Trotzdem wurde mein Arbeitgeber zu meinem Exarbeitgeber.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich kenne das eher genau andersherum: Der Chef sagt "kümmern Sie sich mal drum", da das dann jeder Kollege nach seiner Auffassung macht, kommt dann durch fehlende Absprachen häufig Chaos bei raus.

Ich denke was Du machen kannst, ist einmal mit dem Chef und den Kollegen aus theoretischer Sicht die Geschäftsprozesse definieren, d.h. man schaut sich an, wer für was zuständig ist, welcher Teil von welchem anderen abhängig ist und man definiert dann klare Zuständigkeiten, damit kann / sollte dann eben der "Fachmann" für den Bereich die Entscheidung treffen und auch der Chef muss sich an diese Definitionen halten.

Ich bin zwar nicht so sehr der Freund von "harten" Definitionen der Zuständigkeiten, weil damit natürlich auch Flexibilität verloren geht, aber es kann für den Anfang durchaus hilfreich sein. Generell würde ich mal schauen ob andere Kollegen ähnliche Probleme haben und das man evtl dann mal eine Lösung erarbeitet und diese dem/den Chef/s präsentiert

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich habe für die Projektabwicklung bei uns einen Abwicklungsprozess modelliert. Klingt zwar starr, bringt aber ganz spürbare Verbesserungen mit sich. Vertrieb und Technical Pre-Sales gehen zusammen zum Kunden und erarbeiten die Lösung. Der Projektleiter (nicht der Vertrieb) hat vor Projektbeginn ein Kickoff mit dem Kunden und stimmt Aktivitäten und Arbeitspakete ab. Die Arbeitspakete werden Mitarbeitern zugeordnet und durch die Dispo mit dem Kunden terminiert. Die Kommunikation läuft über ganz wenige Personen, die sich immer eng abstimmen. Funktioniert sehr gut, auch bei größeren und zeitlich gestreckten Projekten.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Bei uns läuft es recht gesittet ab. Unsere Consulter nehmen die Anforderungen auf, sprechen sie ggf. mit den Entwicklern ab und erstellen dazu dann ein ToDo-Ticket in einer "Abarbeitungsliste" ... Der Leiter der Entwicklung liest die Tickets gegen, klärt ggf. noch offene Fragen und weist die Tickets zur Abarbeitung den jeweiligen Entwicklern zu. Meistens werden die Entwickler im Büro eingesperrt. Aber manchmal dürfen wir durch die heilige Pizza-Pforte zum Kunden und arbeiten vor Ort an dem Ticket.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vertrieb und Technical Pre-Sales gehen zusammen zum Kunden und erarbeiten die Lösung. Der Projektleiter (nicht der Vertrieb) hat vor Projektbeginn ein Kickoff mit dem Kunden und stimmt Aktivitäten und Arbeitspakete ab.

Ergänzung: Der Pre-Sales Consultant ist der Projektleiter für das Projekt. So verhindern wir Abstimmungsprobleme zwischen den Personen, die mit dem Kunden die Lösung besprochen haben und der Person, die das Projekt leitet.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Servus!

  1. Kunde stellt Produktanfrage
  2. 1-, maximal 2-tägiger Workshop beim Kunden (Natürlich ohne anwesende Entwickler)
  3. Erstellung Lasten-/Pflichtenheft (Natürlich ohne Entwickler)
  4. Aufgabenverteilung (Natürlich nur für Entwickler)
  5. Projektdurchführung inkl. ungefähr 8000 Änderungen, die das ursprüngliche Pflichtenheft eigentlich völlig obsolet machen
  6. Überstunden
  7. Projekt wird verspätet und halbfertig dem Kunden zum Betatest übergeben weil unser Chef weder Aufwände noch technische Mittel akkurat einschätzen kann/will und das blaue vom Himmel verspricht \o/
  8. Mein Telefon klingelt sturm, weil Änderungen für Module gewünscht werden, an denen ich zu ungefähr 0% beteiligt war

dilbert-pointy-haired-boss.png

Ähnlichkeiten mit fiktiven oder real existierenden Personen sind rein zufällig und nicht beabsichtigt.

Gruß, Ziege

Bearbeitet von Goulasz
Link zu diesem Kommentar
Auf anderen Seiten teilen

Servus!

  1. Kunde stellt Produktanfrage
  2. 1-, maximal 2-tägiger Workshop beim Kunden (Natürlich ohne anwesende Entwickler)
  3. Erstellung Lasten-/Pflichtenheft (Natürlich ohne Entwickler)
  4. Aufgabenverteilung (Natürlich nur für Entwickler)
  5. Projektdurchführung inkl. ungefähr 8000 Änderungen, die das ursprüngliche Pflichtenheft eigentlich völlig obsolet machen
  6. Überstunden
  7. Projekt wird verspätet und halbfertig dem Kunden zum Betatest übergeben weil unser Chef weder Aufwände noch technische Mittel akkurat einschätzen kann/will und das blaue vom Himmel verspricht \o/
  8. Mein Telefon klingelt sturm, weil Änderungen für Module gewünscht werden, an denen ich zu ungefähr 0% beteiligt war

dilbert-pointy-haired-boss.png

Ähnlichkeiten mit fiktiven oder real existierenden Personen sind rein zufällig und nicht beabsichtigt.

Gruß, Ziege

Kann ich so unterschreiben. Ist bei uns leider auch so.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das sind eigentlich wieder schöne Beispiele, warum es sowohl aus Sicht der Projektleitung als auch aus Sicht des Teams Sinn macht, agile Methoden zu benutzen. Ich bin völlig glücklich mit SCRUM. Wir bekommen Stories zu Features die gebraucht werden mit Informationen was damit gemacht werden soll. Diese werden für 2-Wochen-Sprints regelmäßig geplant und abgearbeitet. Natürlicherweise kommen immer noch "kleine Änderungen" durch den Product Owner, aber generell vermeidet man so, sich zu überladen. Wir committen uns auf eine Anzahl von Stories, die von uns mit bestimmtem Aufwand geschätzt wurden und die liefern wir ab. Ich spüre damit nicht den Hauch von Druck, da feststeht, was wir schaffen und was gemacht werden soll. Und scheinbar kann das Management damit auch ganz gut arbeiten.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Servus!

  1. Kunde stellt Produktanfrage
  2. 1-, maximal 2-tägiger Workshop beim Kunden (Natürlich ohne anwesende Entwickler)
  3. Erstellung Lasten-/Pflichtenheft (Natürlich ohne Entwickler)
  4. Aufgabenverteilung (Natürlich nur für Entwickler)
  5. Projektdurchführung inkl. ungefähr 8000 Änderungen, die das ursprüngliche Pflichtenheft eigentlich völlig obsolet machen
  6. Überstunden
  7. Projekt wird verspätet und halbfertig dem Kunden zum Betatest übergeben weil unser Chef weder Aufwände noch technische Mittel akkurat einschätzen kann/will und das blaue vom Himmel verspricht \o/
  8. Mein Telefon klingelt sturm, weil Änderungen für Module gewünscht werden, an denen ich zu ungefähr 0% beteiligt war

dilbert-pointy-haired-boss.png

Ähnlichkeiten mit fiktiven oder real existierenden Personen sind rein zufällig und nicht beabsichtigt.

Gruß, Ziege

So laufen bei uns auch Projekte intern.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...