Leben und Sterben lassen – das berüchtigte “Tote Pferd” reiten

Wer kennt das nicht in Entwicklungsprojekten:

Situation:
Das Projekt hat erhebliche Schieflage.
Das Reporting nach oben vermeidet jegliches Problem.
Intern wird der Aufwand diese Nachrichten zu vermeiden immer schwieriger und aufwändiger.
Neuplanung reiht sich an Neuplanung in immer aufwändigeren Sitzungen und wachsendem Personenkreis.
Upper Management arbeitet bereits operativ mit (oder auch dagegen) und verlangt stündliche Statusmeldungen bzw. immer neue Reports.
Alle Tools zur Verbesserung werden zeitgleich angewandt und die (meist gleichen) Erkenntnisse werden mangels Zeit nicht umgesetzt.
Ressourcen springen zwischen Prio-Themen herum und die Prio 1-Themen haben bereits mehrere Subprioritäten.

Erkenntnis:
Viele Projekte kranken an einem klaren Exit-Kriterium auf den einzelnen Entscheidungsebenen und -kriterien und den Mut diese auch konsequent anzuwenden.
Dabei liegt das Hauptproblem oft am Projekt-Setup, Vorarbeiten und den Vorgaben der einzelnen Fachdisziplinen und weniger an den beteiligten Leuten.
Meilensteine werden oft mit (teilweise erheblichen Abweichungen) durchgewunken und technische Schulden stillschweigend akzeptiert.
Oft werden auch wichtige Fragestellungen kontinuierlich vertagt und andere (einfachere bzw. schnell lösbare) Themen vorgezogen.

Es ist oft unglaublich schwer, entgleiste Projekte in einem späten Stadium wieder einzufangen.
Das ursprüngliche Projektziel an sich kann dann oft schon gar nicht mehr erreicht werden.
Ob es jemals rentabel in den Markt gebracht werden kann ist ohnehin schwierig zu bestimmen. In einer solchen Situation praktisch unmöglich.
Nicht zu vergessen die dann oft schon riesige Mannschaft und das Problem, das eigene Halbwahrheiten klar erkennbar als falsch angenommen werden müssen.
Und niemand geht gerne zuerst mit seinem Kopf in die Schlinge, nicht wahr?

Um sich das (zumindest teilweise) zu ersparen lohnt es sich sehr Zeit in die Formulierung von (Zwischen-) Zielen zu stecken.
Entsprechend gilt dies für die jeweiligen Prozesse auf Projektebene.
Diese Rahmenbedingungen sind dann aber auch uneingeschränkt einzufordern bzw. umzusetzen.
Dabei ist es egal auf welcher Ebene im Projekt man tätig ist und des jeweils behandelten Artefakts, wie z.B.:

  • Ebene Projekt: “Quality Gate”:
    Meilenstein mit Kontrollfunktion: Definiert zu erreichende Ziele und erlaubt kein passieren ohne Zielerreichung. Nicht nur Marketing-Ziele, sondern beinharte Kriterien die auch konkret nachgewiesen werden können.
  • Ebene Projekt: “Exit Criteria”:
    Überlegen Sie genau, wie weit Sie in einem Projekt zu gehen bereit sind.
    Das startet mit dem Budget, dem Zeitrahmen oder auch Kriterien wie Kopfanzahl oder Bürofläche. Planen Sie Kriterien zum Beenden eines Projektes (z.B. wegen fehlender Wirtschaftlichkeit) und Szenarien mit unterschiedlichen Budgets.
    Wichtige Termine können hier Kriterien sein (z.B. wenn nach einem Termin die Marktchancen erheblich absinken).
    Dies kann aber durchaus auch für ungelöste Mindestanforderungen gelten (wenn z.B. nicht die erforderliche Anzahl an Fachkräften verfügbar gemacht werden kann oder wenn elementare Wissensträger nicht oder nicht mehr verfügbar sind).
  • Ebene Prozess: “Tailoring”:
    Wie sieht der globale, allgemein formulierte Prozess im Projekt konkret aus?
    Welche Tools werden wie verwendet?
    Wie können die geforderten Ergebnisse erreicht und nachgewiesen werden?
  • Artefakt Feature: “Acceptance Criteria”, “Definition of Done”: Zielsetzung auf Ebene der Entwicklung eines Features; Definiert das Abschlusskriterium der Aufgabe.
    Diese Ziele erfordern oft Vorarbeiten im Bereich Architektur, Risikobewertung, Requirement Engineering oder auch technische Studien.
    Verwaschene Kriterien und Durchwinken sind hier aber schlechte Berater (wenn auch im Verlauf bequem).
  • Artefakt Abweichung: “Expected Result”: Wie soll sich das Produkt / der Prozess in der behandelten Situation richtig verhalten?
    Hier zeigen sich oft Spezifikationslücken auf oder widersprüchliche Vorgaben. Wenn hier in der Klärung geschlampt wird kann man oft die nächste Abweichung garantieren.
  • Vorgang Review: “Scope”, “Criteria”: Wer soll welchen Sachverhalt (typischerweise entsprechend seiner Rolle) prüfen?
    Ein oft gesehenes Problem bei Reviews ist das fehlende Rollenverständnis. Die Prüfung der Seitennummerierung kann für Quality-Rollen relevant sein, nicht für Entwickler.
    Review können (je nach Definition) auch sehr umfangreich und damit teuer werden.
    Es sollte daher immer klar definiert sein, wer für welche Aspekte zwingend Verantwortung zeigt. Ansonsten ist der Wert dieses wichtigen Instruments nur eingeschränkt erkennbar.
  • Artefakt Dokument: “Approval”: Wer gibt das Dokument frei? Ist eine Freigabe erforderlich? Wie werden Änderungen durchgeführt? Wer ist für Reviews verantwortlich?
    Leider fast immer mit Klärungsbedarf versehen ist die Frage nach Freigabeaktivitäten. Oft zeigen sich hier Lücken im Prozessverständnis oder Lücken in der Definition.
    Fast immer ist die Klärung nervig, manchmal auch teuer.
  • Artefakt Anforderung: “Requirement Maturity”: Erreichen die Anforderungen an das Produkt Best-Practice, zur Vermeidung späterer Aufwände zur Detailklärung?
    Unklare oder sogar widersprüchliche Anforderungen erzeugen immer Aufwände und Kosten in der (späteren Klärung). Wenn kein Akzeptanzkriterium definiert werden kann ist ein Nachweis der Erfüllung unmöglich und Änderungen zu sehr späten Projektphasen unumgänglich.

Sehr oft scheitert man an fehlenden Festlegungen und mangelnder Konsensfähigkeit der Projektteilnehmer. Viele Nebenprozesse und offene Punkte führen zu unklaren Vorgaben und Vermutungsfestlegungen. Praktisch immer zu Verzug im Projekt zur Klärung von (oft auch einfachen) Sachverhalten.
Und das führt praktisch immer zu “cover your ass”, das hier weitere die Möglichkeiten im Projekt einschränkt.

Fazit:
Tun Sie sich selbst einen Gefallen und Fragen Sie früh und beständig nach solchen Punkten. Klären Sie zeitnah und umfassend, oder Sie werden lange daran zu arbeiten haben. Und wenn es wirklich nicht mehr geht, haben Sie den Mut das Projekt (in der aktuellen Form) zu beenden und vielleicht mit den erarbeiteten Erfahrungen neu zu starten.
Tote Pferde reiten sich schlecht und Rennen lassen sich damit nie gewinnen.

100% Vor Ort – Nicht immer notwendig im Projektgeschäft!

Wer kennt das nicht? Gesucht wird: XXX, 100% Vor Ort für….

Im Umfeld von Kundenprojekten wird gerne die vollständige Verfügbarkeit vor Ort als Kriterium herangezogen und oft auch als Ausschlusskriterium definiert.
Dies ist in vielen Projekten tatsächlich erforderlich, manchmal aber auch sicher nicht.
Warum diese Forderung gestellt wird ist oft sehr verschieden, ich versuche aber mal die (für mich) häufigen Gründe zu benennen:

  • Es gibt Gerätschaften, die nur vor Ort zu nutzen sind (weil z.B. Hands-On erforderlich ist)
  • Die IT erlaubt keinen VPN-Zugang bzw. ist dafür nicht vorbereitet
  • Es wird auf eine gewisse Nähe zum Team wert gelegt, z.B. um spontane Gespräche zu erlauben oder weil die Tätigkeit stark koordinationslastig ist
  • Man möchte keine Diskussionen im Team, z.B. bei Angestellten, die hier oft wesentlich eingeschränkte Möglichkeiten zur Gestaltung haben.
  • Man fürchtet seine Kontrollpflichten nicht ausreichend nachkommen zu können.

Grundsätzlich muss man sich klar machen bzw. klären, warum ein (potentieller) Kunde hier entsprechende Forderungen formuliert.
Oft hat man es hier auch mit Leuten zu tun, die sich kaum mit dem Umgang von Freiberuflern bzw. Selbstständigen beschäftigt haben und nur aus dem Projektdruck heraus damit auseinandersetzen müssen. Häufig auch zum ersten Mal und unter Zeitdruck.
Wenn man sich dann auch klar macht, das schon die Aquisegespräche an sich oft für die Beteiligten ein Problem sind kann man die allgemeinen Forderungen oft gut nachvollziehen.

Was aber nicht bedeutet, dass man das auch so akzeptieren muss.

Jeder externe wird aufgrund seiner Expertise ins Projekt genommen (für Standardaufgaben sind wir zumeist zu teuer).
Damit sollte eigentlich jeder in der Lage sein, zu beurteilen ob Vor-Ort zwingend erforderlich ist, nur sinnvoll oder einfach nicht notwendig.
Hier ist (wie oft) Verhandlungsgeschick und Timing notwendig, um gute Ergebnisse zu erzielen.

Auch hier kann ich nur über meine Erfahrungen berichten, ein Standardvorgehen gibt es nicht:

  • Am einfachsten ist es bei Arbeiten, die seitens der Arbeitsmittel stark IT-lastig sind und wenig Interaktion mit anderen Projektmitarbeiter erfordern (Dokumente bearbeiten, Konzeptarbeiten, Programmierung, Softwaretest,…).
    Hier lassen sich gut Strukturen und Vereinbarungen schaffen die auch Remote mindestens gleichwertig bearbeitet werden können.
    Ein Firmenlaptop, VPN, Onlinemeetings, Kollaboration-Tools und vieles ist möglich.
  • Bei Abhängigkeiten, z.B. Prüflinge, ist es oft nicht möglich diese Tätigkeiten Remote zu erledigen.
    Hier bleibt aber immer noch die Option die ganzen administrativen Tätigkeiten entsprechend zu gestalten.
    Manchmal ist es auch möglich (hängt auch von Euren Möglichkeiten ab) ein “privates” Testlabor aufzumachen und die Testobjekte dann im eigenen Umfeld zu bearbeiten. Das erfordert natürlich oft erhebliche Vorarbeit und Werbung beim Kunden, habe ich aber schon erlebt.
  • Tätigkeiten mit starken Koordinationsaufwand erfordern viel Organisation und spontanes Handeln.
    Hier empfiehlt sich ein gewisser vor-Ort Anteil, schon im eigenen Interesse. Schnell ist man vom “Flurfunk” abgeschnitten und wird auch in wichtige Entscheidungsfindungen nicht mehr ausreichend eingebunden (z.B. weil man bei spontanen Klärungen ein Online-Meeting als zu aufwändig ansieht)

Grundsätzlich muss man also erst mal für sich klären, was überhaupt möglich ist und dazu was sinnvoll wäre.
Auch muss klar sein, welche (nicht verhandelbare) Bedarf an Remote-Zeiten erforderlich ist.
Zuletzt sollte man sich (sofern bisher nicht erfolgt) klar machen, das dieses Kriterium (wie jedes andere auch) die Beteiligung am Projekt unmöglich macht.
Dies gilt grundsätzlich natürlich für jeden Aspekt der Projekttätigkeit, ist gerade für Anfänger oder wenig spezialisierte Projekttätige oft ein Problem.

Aus meiner Erfahrung heraus möchte ich hier mehrere Punkte zeigen, an denen man das Thema diskutieren bzw. gestalten kann:

  • In der eigenen Präsentation (z.B. das Profil) bzw. in der ersten Kontaktaufnahme.
    Wenn wir Einschränkungen des eigenen Angebots zwingend durchsetzen müssen (z.B. weil Betreuungsaufgaben zu leisten sind) sollte das auch klar formuliert werden. Solche Fakten erst im Projektverlauf zu erzwingen ist unprofessionell und oft auch nicht erfolgreich. Zuweilen ist es auch nicht ein K.O.-Kriterium, zumindest wenn der Kunde wirklich interessiert ist. Hier ist Spezialwissen ein hilfreiches Merkmal.
  • Im Erstgespräch mit dem Vermittler (wenn vorhanden).
    Hier kann noch relativ “ungefährlich” über die eigenen Vorstellungen gesprochen werden. Je nach Persönlichkeit und Interesse des Vermittlers können hier schon wertvolle Informationen zum Kunden und seinen Vorstellungen. Auch kann oft schon der Vermittler entsprechend “geimpft” werden. Wenn hier gut argumentiert wird, hat man oft schon jemanden der den Boden bereiten und manches “Schlagloch” vorab vermindern kann. Dies kann besonders wertvoll sein, wenn der Vermittler schon einige Zeit im Hause des Kunden tätig ist und schon eine gewisse Vertrauensstellung geschaffen hat.
  • Im Gespräch mit dem Kunden.
    Hier ist es meist schwierig, vor allen wenn der Kunde hier keinerlei Motivation zum Entgegenkommen zeigt.
    Aber auch hier ist es möglich zumindest die Grundforderung zu formulieren und auch entsprechende Gestaltungsmöglichkeiten zu zeigen.
    Bei entsprechender diplomatischer Eignung (oder schlicht guter Ausgangsposition) kann auch hier eine höhere Bereitschaft zum Entgegenkommen erzielt werden. Das Thema sollte aber kein Schwerpunkt im Gespräch werden.
  • Im Projektverlauf.
    Je mehr Einblick man in ein Projekt hat, desto besser kann man die eigenen Möglichkeiten verstehen und verhandeln.
    Auch wenn beim Start keine Remote-Tätigkeit angeboten wird, kann dies nach ein paar Wochen durchaus anders aussehen.
    Man ist dem Kunden besser bekannt (was viel Unsicherheit wegnimmt) und kennt auch die IT des Kunden.
    Das Projektteam ist bekannt und man selbst dem Team auch (was die Akzeptanz eigener Vorschläge wesentlich erhöhen kann) und die eigenen Aufgaben sind viel besser beschrieben.
  • Bei Vertragsverlängerungen.
    Obgleich nicht ideal, können hier bisher verweigerte Forderungen neu verhandelt werden.
    Je nach eigener Position und realistischer Einschätzung kann hier manche Position verbessert werden.

Die Argumentation ist natürlich kaum zu vereinheitlichen, anbei trotzdem ein Paar Ideen dazu:

  • Schlecht möglichst: Die Stärke der eigenen Position bzw. die Abhängigkeit des Kunden ausspielen.
    Hier kann man sich manchmal durchsetzen, wird aber feststellen das diese Abhängigkeit von Kunden zeitnah bereinigt wird. Wenn es sein muss auch auf Kosten des Projekts.
  • Die kundeneigene IT bietet ausreichend Möglichkeiten Teile der eigenen Tätigkeiten vollständig Remote auszuführen (z.B. Kunden-Laptop und VPN).
    Hier kann sehr einfach ohne besondere Aufwände eine (Teil-) Verlagerung der Tätigkeit durchgesetzt werden. Der administrative Aufwand beschränkt sich oft auch wenige IT-Anträge und im Projekt limitieren zumeist nur Meetings den Rahmen.
  • Eigenes Equipment bzw. Projektflächen sind vorhanden bzw. lassen sich organisieren.
    Hier ist der Aufwand auf beiden Seiten zumeist höher. Es kann sich aber für beide Seite auszahlen, da z.B. der Kunde Testflächen verlagern kann bzw. eigene Engpässe mildern (z.B. für Arbeitsplätze). Man kann ja z.B. die Einrichtung auf eigener Seite kalkulieren und für den Kunden kostenneutral gestalten (sofern betriebswirtschaftlich interessant). Auch ist hier die Sicherheit (IT und Örtlichkeiten), Vertraulichkeit und Verfügbarkeit ein Thema.
    Diese Option funktioniert bei kleinen Kunden besser, in größeren Unternehmen zumeist gar nicht.
  • Manchmal ist das Umfeld des Kunden derart ablenkend, das die eigene Konzentration stark eingeschränkt wird (z.B. Großraumbüro, Baustellen, Fertigung, Fragen von Kollegen). Hier kann eine Teilverlagerung für den Kunden wertvoll werden, da man bessere Ergebnisse liefern kann oder in kürzerer Zeit.
  • Abgrenzungskriterien.
    Manchmal kann es besser sein, als Externer nicht zu sehr in das Projektteam hinein zu wachsen. Zum einen betrifft es das Thema Scheinselbständigkeit bei dem die “Integration” als Indiz angesehen wird. Andererseits kann es in manchen Teams politisch sinnvoll sein diese Trennung gegenüber Angestellten stärker zu gestalten. Dies ist z.B. in Projekten mit Schieflage und internen Reibereien manchmal notwendig, um intern Eskalationen zu vermeiden.
  • Stundensatz.
    Das Thema lässt sich hier gut in beide Richtungen einbringen. Zum einen kann man einem Kunden (nach Möglichkeit) einen günsteren Stundensatz anbieten, wenn im Gegenzug die Reisekosten (durch die vor-Ort Tätigkeit) entsprechend reduziert werden können. Umgekehrt können evtl. geforderte Vergünstigungen am Stundensatz durch eine entsprechende Regelung auch leichter “verrechnet” werden.
    Da dieser Block in Städten wie München oder Stuttgart schnell mal 10€ und mehr am effektiven Stundensatz ausmachen kann, gibt es hier erhebliches Potential für beide Seiten.
    Manchmal kann auch eine Vereinbarung über beide Sätze geschlossen werden (Remote und vor-Ort). Da kann das ganze dann sogar flexibel gestaltet werden.

Für mich funktioniert oft eine anteilige Remote-Tätigkeit am besten, oft in Abhängigkeit von Projektphasen. 100% in beide Richtungen hat meist wenig Sinn und ist auch selten zu begründen (von beiden Seiten).

Grundsätzlich gibt es also bis zum Projektende viele Möglichkeiten das Themenfeld zu bearbeiten und die eigenen Vorstellungen besser umzusetzen.
Dies setzt aber immer voraus, das man hier auch Gestaltungsspielraum einräumen kann und will bzw. man auch selber zumindest zeitweilig ein “suboptimales” Ergebnis akzeptieren kann.
Auch kann dies nur in Kooperation mit und durch den Kunden funktionieren und ist manchmal auch bei guten Willen aller Beteiligter nicht erfolgreich.
Aber auch das ist im Projektgeschäft normal und sollte auch niemanden (mehr) überraschen.

Buchempfehlung: “Der Termin” von Tom DeMarco

Heute möchte ich ein schon etwas älteres Buch vorstellen: “Der Termin – Ein Roman über Projektmanagement” von Tom DeMarco.

Es ist ein schöner und leicht lesbarer Roman, der ganz nebenbei zu einer absurd-lustigen Story manche typische Projektsituation reflektiert und einfach formulierte Grundstrategien im Umgang dazu formuliert.
Wer schon in Projekten gearbeitet hat wird sicherlich die eine oder andere Parallele zur persönlichen Erfahrung finden.
Dadurch sind viele der Erkenntnisse im Buch durchaus auf die eigene Realität anwendbar und auch schön aufbereitet.

Aus meiner Sicht eines der am freundlichsten geschriebenen “Fachbücher”, bei denen Lesen und Lernen zusammen passt und man ganz nebenbei etwas Reflektion gegen eigene Erfahrung gewinnen kann oder einfach nur ein Paar gute Ideen für’s nächste Mal.

Beschreibung:
Tom DeMarco beschreibt in seinem Roman über Projektmanagement lebhaft und anschaulich die Prinzipien und Absurditäten, die die Produktivität eines Software-Entwicklungsteams beeinflussen.
Mr. Tompkins, ein von einem Telekommunikationsriesen soeben entlassener Manager, hat die Aufgabe, sechs Softwareprodukte zu entwickeln. Dazu teilt Tompkins die ihm zur Verfügung stehende gigantische Entwicklungsmannschaft in achtzehn Teams auf – drei für jedes Produkt. Die Teams sind unterschiedlich groß und setzen verschiedene Methoden ein. Sie befinden sich im Wettlauf miteinander und haben einen gnadenlos engen Terminplan.
Mit seinen Teams und der Hilfe zahlreicher Berater, die ihn unterstützen, stellt Mr. Tompkins die Managementmethoden auf den Prüfstand, die er im Laufe seines langen Managerlebens kennen gelernt hat. Jedes Kapitel endet mit einem Tagebucheintrag, der seine verblüffenden Erkenntnisse zusammenfasst.
(Übernommen aus Artikelbeschreibung bei Amazon)

  • Verlag: Carl Hanser Verlag GmbH & Co. KG (8. November 2007)
  • Sprache: Deutsch
  • ISBN-10: 3446414398
  • ISBN-13: 978-3446414396
  • Originaltitel: The Deadline

Nachtrag:
Ein häufig genannter Kritikpunkt auch an dieses Buch ist die “Oberflächlichkeit” der Inhalte bzw. das es für “Fortgeschrittene” wenig neues bietet.
Diese Kommentare sind weder falsch noch richtig. Aus meiner Sicht ist das Buch inhaltlich eher zeitlos als ein Fachbuch zu einen speziellen Thema. Es gibt sicherlich umfangreiche Alternativen zum Thema, die wesentlich mehr fachliche Details bieten.
Ebenso gibt es sicher bessere Bücher zur Unterhaltung für günstigeres Geld.
Für mich war es ein schönes Buch zum Lesen ohne Anspruch danach ein besserer Projektleister in einer Fachdisziplin zu sein.
Und inhaltlich war es für meine schwarze Seele ein erfrischend anderes Buch mit Fachbezug und einer Aufforderung seine Werte und Vorgehensweisen zu hinterfragen. Und manchmal (wenn auch eigentlich selbstverständlich) ist ein solcher Anstoß unbezahlbar.

Selbständige – selbst und ständig – gemeinsam stärker

Selbständige sind es gewöhnt auf eigene Faust nach Lösungen zu suchen.
Dies funktioniert auch oft innerhalb des eigenen Rahmens sehr gut, manchmal muss man aber einsehen dass es gemeinsam viel besser funktioniert.
Viele von uns haben in den letzten Jahren den zunehmenden politischen Druck vor allen auf kleine Selbständige, Einzelunternehmer und auch Teilzeit-Selbständige verfolgen und erleben dürfen.
Dies ist eine Situation, die nicht mehr alleine gelöst werden kann, hier müssen wir gemeinsam agieren.
Andernfalls werden wir gegenüber den Verantwortlichen scheitern, einzelne finden hier nicht mehr ausreichend Gehör.

Daher meine Bitte und Aufforderung, unterstützt den VGSD als Vertreter in dieser Sache um hier mehr Einfluss und Gehör zu bekommen.
Auf das wir weiterhin entsprechend unseren Ideen und Vorstellungen eine selbständige und eigenverantwortliche Tätigkeit am Markt wahrnehmen können.

Denn das ist es schließlich, was wir eigentlich wollen.

 

Selbständige und Gründer brauchen eine Lobby.

Wir brauchen nur einen …. zum … für … mit … asap.

Dieser Artikel beschreibt das gängige Verfahren im IT-Projektgeschäft im klassischen Vertragskonstrukt Berater – Vermittler – Kunde.

Ich möchte hier explizit nicht das Modell angreifen, lediglich über eine Beschreibung der einzelnen Schritte erklären.
Diese sind vor allen bei komplett neuen Kontakten üblich.
Sollte der Berater beim Kunden oder Vermittler bereits aus früheren Tätigkeiten bekannt sein, fallen hier Teile weg oder erfolgen deutlich beschleunigt.

Über die Jahre zeigt sich bei den meisten Kunden ein wiederkehrendes Grundvorgehen bei der Beauftragung von Beratern über Projektbeauftragungen:

  • Der Kunde erarbeitet eine Liste an Aufgaben und die aus seiner Sicht erforderlichen Qualifikationen und streut diese über seine bevorzugten Lieferanten.
  • Diese erarbeiten aus Ihren eigenen Datenbanken eine Anzahl von geeigneten und verfügbaren Kandidaten.
  • (Optional): Sofern der Lieferant hierzu nicht ausreichend Kandidaten anbieten kann, wird die Anforderungen an die bevorzugten externen Berater des Lieferanten gestreut.
  • (Optional): Sofern auch hier nicht ausreichend Kandidaten gefunden werden können wird in den einschlägigen Foren oder Plattformen über entsprechende Ausschreibungen gesucht.
  • Wenn sich aus Sicht des Vermittlers geeignete Kandidaten gefunden haben, werden diese kontaktiert.
  • Zumeist wird (vor allen bei unbekannten Kandidaten) ein Vorabgespräch zwischen Vermittler und Kandidat erfolgen.
    Hier wird von beiden Seiten ausgelotet, inwiefern Kandidat und Projekt zusammen passen und ob der Projektrahmen erfüllt werden kann.
  • Bei entsprechender Eignung und Einigkeit wird der Kandidat dem Kunden vorgestellt.
  • Wenn der Kunde interessiert ist, erfolgt ein Vorstellungsgespräch entweder vor Ort beim Kunden oder per Telefonkonferenz.
    Hier wird der Kandidat vom Kunden bewertet. Allerdings kann hier auch der Kandidat den Kunden und das potentielle Projekt bewerten.
    Zumeist endet das Gespräch aus der Sicht des Kandidaten ergebnisoffen.
  • Sofern der Kunde interessiert ist und sich mit dem Vermittler einigen kann wird die Zusammenarbeit vereinbart.
  • Der Berater wird vom Vermittler informiert.
  • Die jeweiligen Verträge werden verhandelt und unterschrieben.
  • Am vereinbarten Startdatum findet man sich vor Ort beim Kunden ein und startet in das Projekt.

Danach geht es erst richtig los, dies ist aber für einen anderen Artikel mit entsprechendem Schwerpunkt vorgesehen.

Die Liste ist sicher nicht komplett und auch nicht immer gültig, jedes Projekt ist etwas anders und manchmal auch gar nicht mehr abbildbar.
Aus meinen Erfahrungen ist es aber ein gutes “Standardmodell” wie es derzeit von der Masse gelebt wird.

Jede der Schritte hat seine Fallstricke, aber auch Potential sich und seine Dienstleistung besser zu präsentieren und manche ermüdende “Grundsatzklärung” schon sehr früh zu klären.
Nicht zu vergessen sind deutliche Abweichungen auch manchmal ein Hinweis für den Berater, z.B. wie ein Vermittler sich aufstellt oder ob evtl. weitere Instanzen in der Projektanbahnung tätig sind.

Was auch immer geschieht, man kann aus allem lernen und sollte sich nie zu sehr unter Druck setzen lassen.
Zwang ist für alle Seiten keine Lösung in wird im Projekt früher oder später ein Problem werden.

Möge der Erfolg mit uns sein!

Launch von 1Vi.de

Nach einigen Jahren Projekterfahrung in verschiedenen Rollen der Produktentwicklung war es Zeit das Angebot neu zu strukturieren.

Diese Restrukturierung zeigte auch den Bedarf, das Projektgeschäft für sich genommen zu behandeln und von anderen Tätigkeitsfeldern zu trennen.

Auch ist es zunehmend erforderlich, Informationen zur Qualifikation und Projekthistorie in verschiedenen Formen und Tiefen zu strukturieren.

Um dies besser zu erreichen, sind nun unter 1Vi.de die Ergebnisse dieser Bemühungen komplett verfügbar.

Ich hoffe, das Ergebnis entspricht Ihren Erwartungen. Sollten Sie Anregungen haben, schicken Sie mir doch bitte eine Email mit möglichen Verbesserungen.

Beste Grüße
Boris Dirnfeldner

Wir benutzen Cookies ausschließlich für essentielle Funktionen, z.B. bei der Benutzeranmeldung. Diese können technisch nicht deaktiviert werden, allerdings durch Browsereinstellungen unterbunden. Wir gehen von einer Zustimmung aus wenn Sie weiter diese Seite benutzen.