Wie laufen bei euch Kundenprojekte ab?

[carstenj]

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.

[Thanks-and-Goodbye]

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.

[flashpixx]

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

[DocInfra]

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.

[Memento]

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.

[DocInfra]

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.

[Goulasz]

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
   

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

Gruß, Ziege

Bearbeitet 17. September 2012 von Goulasz

[sepp0]

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
   

Ä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.

[Ulfmann]

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.

[Hellspawn304]

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
   

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

Gruß, Ziege

So laufen bei uns auch Projekte intern.