Get best of the week

Wie man versteht, dass ein Projekt ein Projekt ist und es richtig ausführt

Zwei Tage vor der Demo. Das Team sieht spezifische Funktionen - die Integration unseres Produkts in Google Maps. Die Integration wird "auf dem Knie" gesägt - die Hauptsache ist, Zeit zu haben, um dem potenziellen Kunden die Fähigkeiten des Systems zu zeigen.

Die Demo wird bestanden und der Kunde macht eine Pause, um nachzudenken.

Sechs Monate später verkaufen Verkäufer eine andere Lösung mit Google Maps-Integration an einen anderen Kunden. Nun, sie haben gesehen, dass vor einem halben Jahr alles an der Demo funktioniert hat.

Was ist das Problem hier?

Ich habe in verschiedenen Unternehmen gearbeitet. Irgendwo war klar, dass wir dieses Projekt machen würden. Warum war das klar? Der Kunde kam und sagte, ich muss genau ein solches System erstellen und es beschreiben. Der Manager plant, wie viel Zeit und Geld das Projekt in Anspruch nimmt, verhandelt mit dem Kunden und arbeitet weiter. Es ist - die Charta, der Projektplan, die Risiken, die Qualitätskontrolle und andere Projektartefakte. Klar und verständlich.

In anderen Organisationen wurde das Projekt von oben gestartet - wir machen dies und das, nehmen Menschen und gehen. Weniger Weiten, aber auch klar und deutlich.

Drittens ist es am schwierigsten, bei Projekten nicht einfach zu sein. Meiner Meinung nach gibt es eine Reihe von Problemen, über die ich nur schwer nach meinem Niveau beurteilen kann. Alles geschah wie zu Beginn beschrieben - das Projekt ist eher tot als lebendig.

Welche Probleme treten auf?

  • , — . , .
  • .
  • , .

Das Projektteam begann mit der Ausarbeitung des Umsetzungsplans und „plötzlich“ erschienen Nuancen.

Ein Klassiker des Genres - sowohl wir als auch der Kunde haben beispielsweise „Integration“ oder den Begriff „Audit“ unterschiedlich verstanden. Für sie war es ein schreckliches Wort, das mit bösen Prüfern in Verbindung gebracht wurde, und für uns ein Begriff, der Funktionalität bedeutet.

Infolgedessen wird der Implementierungsprozess in ein Revisionsprojekt übersetzt. Formal hat sich der Entwurf der Charta nicht geändert, alle hochrangigen Ziele sind gleich geblieben.

Wie rollt man? Die Hauptaufgabe besteht darin, genau herauszufinden, was zu tun ist, Prioritäten, Zeitpläne, Ressourcen und Risiken festzulegen, alle interessierten Parteien zu benachrichtigen und verschiedene Entwicklungsszenarien vorzubereiten. Als Ergebnis - mit dem Kunden den erforderlichen Betrag zu vereinbaren, der in das erschwingliche Budget passt.

Die Hauptnuancen - das Projekt wurde bereits verkauft, es hat bereits ein Budget und den Arbeitsaufwand. Ziemlich strenge Einschränkungen. Dies bedeutet jedoch nicht, dass Sie alles schlucken und es zunächst für die Wahrheit halten müssen. In 99% der Fälle können Sie verhandeln, ob es sich um einen Kunden oder einen Sponsor handelt.

Wir starten das Projekt


Zufällig bin ich eher ein Befürworter klarer Pläne. Waterfall und der PMI-Ansatz sind im Geiste ähnlich, obwohl einige Aspekte von Agile nicht fremd sind.

Das Projekt beginnt also und der Beweis, dass das Projekt gestartet wurde, ist die Charta des Projekts. Für diejenigen, die wenig vertraut oder unbekannt sind, werde ich erklären, was für ein Tier es ist.

Gemäß der Ideologie von PMI ist dies ein Dokument, das die Ziele, Fristen, das Budget und die Risiken auf höchster Ebene beschreibt, dem Projektmanager formelle Befugnisse erteilt und vor allem den Namen des Projekts festlegt. Im Folgenden werde ich erklären, warum.

Oft wird die Charta vom Projektmanager vorbereitet und mit dem Sponsor, dem Kunden und anderen wichtigen Stakeholdern vereinbart.

In einer der Firmen, in denen ich gearbeitet habe, gab es keine klare Definition für ein Projekt. Es gab eine bestimmte Aktivität, einen bestimmten Fluss, der als Projekt bezeichnet wurde, aber tatsächlich nicht. Das war eine Annahme. Okay, nennen wir es ein Projekt und entscheiden uns zumindest für einen Namen, damit jeder versteht, wovon wir sprechen. Es gab Verwirrung mit den Namen, als der Sponsor sagte: „Wie ist der Fortschritt des Projekts zur Integration von Lösungen?“. Der Abteilungsleiter und der Manager dachten unterschiedlich. Der Abteilungsleiter nannte dieses Projekt „Kundenintegration“ und der Projektmanager „Datenbankoptimierung“. Jeder dachte auf seiner eigenen Ebene.

Agile hat kein Budget und keine Zeitpläne, auch nicht auf höchster Ebene, da alles flexibel ist und sich jederzeit ändern kann. Ja, Agile kann die Fertigstellungszeit schätzen, jedoch erst nach mehreren Iterationen, wenn die Leistung des Teams bewertet wird. Aber es gibt Ziele. Wir wissen, was wir tun wollen.

Ich werde ein Beispiel geben. Es gibt zwei Entwicklungsteams. Beide haben das gleiche Projekt - eine mobile Lösung für die Qualitätskontrolle von Lebensmitteln zu entwickeln.

Team A arbeitet am Wasserfall. Team B arbeitet an Agile. Unterschiedliche Planungs- und Entwicklungsansätze. Aber das Ziel ist eins. Warum also nicht gleich zu Beginn reparieren? Wie hoch ist die Wahrscheinlichkeit, dass Team B mitten im Sprint versteht, dass der Kunde keine Anwendung zur Qualitätskontrolle benötigt, sondern eine Anwendung zur Aufzeichnung von Fußballspielen? Sehr klein, mit größerer Wahrscheinlichkeit werden sie dennoch ihr ursprüngliches Ziel erreichen.

NB: Ich gehe davon aus und spreche von kundenspezifischer Entwicklung, nicht von Startups.

Mit dem Namen, dem Timing, dem Budget mehr oder weniger klar. Was ist mit den Risiken?

PMI bezieht sich formal darauf. Meiner Meinung nach ist der Risikomanagementprozess eine unabhängige Sache. Lassen Sie mich erklären, was ich meine.

Der Risikomanagementprozess besteht aus folgenden Phasen:

  1. Identifizierung
  2. Analyse
  3. Planung
  4. Überwachung

Dies ist im Wesentlichen ein iterativer Prozess. Es gilt sowohl für Operationen als auch für agile Ansätze.

Beim Starten eines Projekts besteht ein globales Risiko: Es kann fehlschlagen.
Edward Yordons Buch The Kamikaze Path hat einen interessanten Gedanken - es lohnt sich, jedes Projekt als Misserfolg zu behandeln. Mit dieser Einstellung müssen Sie eine Entwicklungsstrategie entwickeln, dh eine Reihe von Maßnahmen durchdenken, die ein erfolgreiches Projekt zum Scheitern bringen.

Warum also nicht von diesem Gedanken abspringen und ihn verwirklichen? Ja, zu Beginn sind nur wenige Daten vorhanden. Deshalb handelt es sich jedoch um Risiken auf hoher Ebene, um Interessenten zu zeigen, was schief gehen könnte.
Insgesamt - Der Chartaentwurf ist ein Dokument, mit dem sich alle wichtigen Parteien auf eine Terminologie, globale Ziele und Risiken auf hoher Ebene einigen können. Jeder versteht, wohin wir gehen, was wir erreichen wollen und was falsch passieren kann.

Projektzielsetzung


Viele unerfahrene Projektmanager haben dies durchlaufen - Sie müssen eine Charta erstellen und den Zweck (die Ziele) des Projekts bestimmen. Und solche Monster werden geboren:

  • Entwicklung und Implementierung eines Unternehmensprogramms und eines Projektmanagementsystems zur Verbesserung der Interaktion zwischen Abteilungen;
  • Recycling des Steuerbuchhaltungssystems zur Optimierung des Rechnungslegungsprozesses;
  • Implementierung eines Kostenkontrollsystems zur Steigerung des Gewinns von Abteilungen.
  • Solche Projekte können nicht abgeschlossen werden. Wenn Sie diesen Wortlaut in der Charta sehen, ist dieses Projekt bereits tot.

Warum sollte ein „Unternehmenssystem“ die Zusammenarbeit verbessern? Wie wird die Kundin verstehen, dass sie dies getan hat?

"Recycling des Buchhaltungssystems" - wir werden es überarbeiten, aber wie? Ändern Sie die Menüpunkte in der Benutzeroberfläche. Optimiert dies den Rechnungslegungsprozess?

„Implementierung des Steuerungssystems“ - Wie verstehen wir, dass das System implementiert ist? Angenommen, alle sind sich einig, dass es implementiert wird, aber wird es den Gewinn der Abteilungen steigern? Was ist, wenn wir nichts implementieren, aber der Gewinn aus Gründen steigt, die außerhalb unserer Kontrolle liegen? Können wir davon ausgehen, dass das Projekt sein Ziel erreicht hat?

Wenn wir die Ziele des Projekts formulieren, sollte dies eine Reihe von Zielen sein: Was muss konkret getan werden und wie verstehen wir, dass wir es getan haben? Was sollen wir sehen, fühlen? Was soll sich ändern? Welche Kosten sollen dies erreichen? Wann? Wenn es mehrere Ziele gibt, welche Prioritäten haben sie dann? Es kann sich herausstellen, dass die Ziele voneinander abhängen, oder es kann sich herausstellen, dass sich einige Ziele gegenseitig ausschließen.

SMART-Ziele setzen


  • Spezifisch - spezifisch.
    Was wollen wir machen? Etwas zu verbessern? Und wie viel?
  • Messbar - messbar.
    Können wir das Ziel in Geld, Prozent und Zeitersparnis messen?
  • Erreichbar - erreichbar. Haben wir genügend Ressourcen, Wissen, Erfahrung und Zeit, um das Ziel zu erreichen?
  • Relevant - relevant oder signifikant.
    Hier müssen Sie bestimmen, was erforderlich ist, um das Ziel zu erreichen?
  • Zeitgebunden - zeitlich begrenzt.
    Wie lange soll das Ziel erreicht werden?

Beispiel: Implementieren Sie ein auf Project Server basierendes Projektmanagementsystem für 20 Arbeitsplätze des Projektbüros mithilfe eines elektronischen Risikoregisters und von E-Mails mit der automatischen Benachrichtigung über die Verschiebung von Fristen.

Das System sollte dazu beitragen, die Zeitpläne für jedes Projekt innerhalb von 2 Monaten nach dem Start um 15% zu reduzieren.

Das System sollte in 6 Monaten, spätestens am 15. Dezember, implementiert werden.

Schon näher, aber noch verfeinernd.

Zusätzliche Fragen, die Sie stellen können:

  • Was soll getan werden?
  • Warum müssen Sie das tun?
  • Welche Vorteile sollte das Projekt bringen?
  • Ist jeder mit diesem Plan vertraut?
  • Versteht ihn jeder gleich?
  • Stimmen ihm alle zu?
  • Wann müssen Sie den Job beenden?
  • Wer ist der Endbenutzer?
  • Welche Qualität erwarten Sie?
  • Welche Funktionalität wird erwartet?
  • Welche Einrichtungen stehen zur Verfügung?
  • Wer kontrolliert den Erfolg und nach welchen Kriterien?
  • Was soll auf keinen Fall passieren?
  • Welche Arbeit gehört nicht zum Projekt?

Die letzten beiden Fragen sind die sogenannten "Nicht-Ziele".

Sie beschreiben, was für das Projekt nicht relevant ist und was nicht passieren sollte, da dies den Projektfortschritt stört oder interne Einschränkungen verletzt. Ergebnisse, die für das Projekt nicht relevant sind, sollten nicht als schädlich eingestuft werden. Sie sollten sich jedoch bewusst sein, dass der Kunde nicht für sie bezahlt.

Zusammenfassung


Sie sehen, es gibt eine gewisse Menge an Arbeit mit bestimmten Umrissen und es gibt sogar einen Zeitplan und ein Budget dafür? Mit hoher Wahrscheinlichkeit ist dies ein Projekt. Wir verhandeln mit Verkäufern, damit sowohl Manager als auch Ingenieure in den Verkaufsprozess einbezogen werden. Zumindest als Berater - und dann werden sie damit arbeiten.

Bevor wir beginnen, legen wir den Namen des Projekts und die Terminologie fest. Wir schreiben die Charta und bilden klare und verständliche Ziele. SMART ist unser Alles.

More articles:


All Articles