Wie managt man ein Projekt ohne bestehende Struktur?

Mein erster Rat ist, jeder Versuchung zu widerstehen, eine formelle Struktur einzuführen, nur damit alles offiziell aussieht. Beginnen Sie damit, den Zustand des Projekts zu bewerten; Bestimmen Sie, was gut funktioniert hat und was nicht, wenn überhaupt.

Um Ihre Frage zu beantworten, worauf Sie sich konzentrieren sollten: Konzentrieren Sie sich auf das, was gut funktioniert , und lassen Sie diese Dinge gleich. Stellen Sie sicher, dass Sie mit den vorhandenen Statusaktualisierungstools vertraut sind, und beginnen Sie dort, falls keine vorhanden sind. Wenn das Projekt gut läuft, bringen Sie das Boot nicht ins Wanken, indem Sie ein neues Regelwerk einführen.

Wenn es eine Reihe von Dingen gibt, die nicht gut funktionieren, verfolgen Sie einen pragmatischen Ansatz bei der Implementierung von Tools, um diese Anforderungen zu erfüllen. Gibt es unberücksichtigte Risiken? Erstellen Sie ein Risikoregister. Fehlt es an Kommunikation? Entwickeln Sie einen Kommunikationsplan. Gibt es unklare Erwartungen an das Projektteam? Du hast die Idee...

Viel Glück!

1. Treffen Sie sich mit dem Kunden / der Person, für die Sie das Projekt durchführen
2. Finden Sie heraus und bestätigen Sie, was sie erwarten und was sie getan haben wollen
3. Sehen Sie, ob das machbar ist oder nicht
4. Wenden Sie sich an sie und teilen Sie ihnen mit, was Sie in Bezug auf die Machbarkeit (Umfang, Zeitplan und Budget) herausgefunden haben.
5. Iterieren Sie, bis Sie zu einem realistischen Plan kommen (dieser Prozess ermöglicht es Ihnen auch, eine Beziehung zu ihnen aufzubauen)
6. Wenn möglich ausführen. Wenn nicht, stoppen Sie das Projekt.

Sie sagen nicht, wie lange das Projekt noch andauern wird, den Umfang oder was nach dem Ende des Projekts passiert ... was eine Antwort etwas schwierig macht. Wenn das Projekt wie „erwartet“ abläuft (basierend auf der Wahrnehmung einiger Führungskräfte, da es nichts Dokumentiertes gibt, an dem es gemessen werden kann), konzentrieren Sie sich auf die Übergabe nach der Inbetriebnahme. Helfen Sie bei der Kommunikation, wo immer es möglich ist (ohne bestehende Kommunikationsleitungen zu stören), halten Sie Ihre Augen/Ohren offen für raue Bereiche/Risikopunkte, auf die Sie Ihre Zeit verwenden können ... und helfen Sie der QA so gut wie möglich (Ende eines un -geführtes Projekt liefert oft interessante Ergebnisse)

Da es keine offizielle Übergabe von PM zu PM gab, befinden Sie sich in einer Position, in der Sie das Übergabeverfahren mit einem oder mehreren Teammitgliedern des Projekts durchlaufen müssen.

Es ist sehr wahrscheinlich, dass einige der Teammitglieder mehr über die Richtung des Projekts wissen als Sie. Anfangs müssen Sie sich öfter als sonst mit diesen Teammitgliedern treffen.

Genau wie das Wechseln einer Ressource mitten in einem Projekt führt auch das Wechseln des Projektmanagers zu Verzögerungen. Stellen Sie sicher, dass die Änderung jedem mitgeteilt wird, mit dem Sie zusammenarbeiten werden. Stellen Sie sich vor und stellen Sie klar, dass Sie dabei sind, dort weiterzumachen, wo der alte PM aufgehört hat. Lassen Sie die Leute wissen, dass Sie daran interessiert sind, ihre Meinung zu dem Projekt zu hören.

Stellen Sie Fragen dazu, wohin der vorherige Projektmanager mit dem Projekt gegangen ist. Welche Ziele hat er/sie sich gesetzt? Was war der Plan für die nächsten 3 Monate? Was sind die größten Probleme des Projekts? Welche Blocker behindern den Fortschritt? Fragen Sie nach ihren Empfehlungen.

Erstmal alles dokumentieren. Die Dokumentation hilft Ihnen, Notizen in eigenen Worten zu machen. Dies wird Ihnen nicht nur als Referenz dienen, sondern das Dokumentieren von Dingen wird Ihnen tatsächlich helfen, sich Dinge zu merken und ein besseres Verständnis des Projekts zu ermöglichen.

Zu diesem Zeitpunkt ist das Schlimmste, was Sie tun können, blind anzufangen und willkürlich Änderungen vorzunehmen. Ihre Aufgabe ist es jetzt, zu beobachten, Fragen zu stellen und so viel wie möglich über das Projekt zu lernen, damit Sie in naher Zukunft fundierte Entscheidungen treffen können.

Ich würde sagen, nehmen Sie sich Zeit, bevor Sie zu Schlussfolgerungen kommen. Keine Dokumentation und keine Struktur sind nicht dasselbe. Die meisten Manager neigen oft dazu, beides zu verwechseln, während in Wirklichkeit die meisten erfahrenen Entwicklungsteams ihre eigenen stillen Strukturen haben, die von außen nicht offensichtlich sichtbar sind.

Ich muss Criag zustimmen, dass der Versuch, zu früh zu viel Struktur zu schaffen, oft mehr Probleme schafft als löst. Sehen Sie, was funktioniert, und tun Sie es öfter. Ein Rat, den ich Ihnen geben kann, ist, viel Zeit damit zu verbringen, mit dem eigentlichen Produkt oder der Anwendung herumzuspielen und seine Funktionalität in- und auswendig zu verstehen. Verwenden Sie mündliche Kommunikation und schnelle persönliche Fragen, anstatt Meetings einzuberufen. Vielleicht fangen Sie sogar an, unterwegs ein paar Fehler zu melden, wenn Sie auf Fehler stoßen.

Dies hat mehrere Vorteile.

Einer davon ist, dass Sie sich auf das Projekt konzentrieren können, indem Sie aktiv sind und sich nicht in die Zeit und den Raum anderer Teammitglieder einmischen, die möglicherweise bereits beschäftigt sind.

Außerdem können Sie auf diese Weise an der Anwendung arbeiten und sie in- und auswendig kennen.

Nicht nur, dass Sie das Entwicklungsteam direkt kennenlernen und mit ihm zusammenarbeiten. Wenn sie gut sind und das Projekt bisher überlebt hat, verwenden sie wahrscheinlich bereits eine Art Struktur (Test Driven Development, Unit Test Cases usw.). Es ist einfach nicht offensichtlich oder für Sie sichtbar. Durch die Zusammenarbeit mit dem Team können Sie sie kennenlernen, wissen, welche bestehenden Entwicklungsmethoden sie verwenden und welche Fähigkeiten sie haben. Vielleicht sind sie talentierte Programmierer, die davonkommen, indem sie einen sehr leichtgewichtigen Prozess verwenden, und der Versuch, sich zu beeilen, um mehr Verwaltungsstruktur hinzuzufügen, könnte mehr Probleme verursachen, als er lösen könnte.

Nachdem Sie einige Zeit damit verbracht haben, sich mit dem Projekt zu beschäftigen, sind Sie möglicherweise in einer viel besseren Position, um bessere Entscheidungen über die Art von Änderungen zu treffen, die dem Projekt zugute kommen könnten, anstatt sich zu beeilen und zu versuchen, Änderungen an der Struktur und dem Arbeitsablauf vorzunehmen wird fertig. Beginnen Sie dann mit sehr kleinen inkrementellen Änderungen, Schritt für Schritt.

Konzentrieren Sie sich auf der Kundenseite auf ständige Kommunikation und sehen Sie, ob sie mit der aktuellen Leistung zufrieden sind, die sie erhalten. Nochmals, wenn sie zufrieden sind, sehe ich keinen Grund, in Eile einzugreifen und radikale Änderungen am Gesamtprozess vorzunehmen. Wenn sie nicht glücklich sind, würde es darauf hinauslaufen, ein Anliegen nach dem anderen anzusprechen. Vermeiden Sie ganz einfach Big Bang-Änderungen auf beiden Seiten, wenn möglich.

Versuchen Sie zunächst, die Anforderungen auf oberster Ebene zu erfassen. Dann tun Sie, was die anderen Poster vorschlagen.

Beginnen Sie damit, den aktuellen Status des Projekts zu kennen:

• Fragen Sie das Team nach der Situation, insbesondere nach den aktuellen Problemen, die das Projekt gefährden könnten
• Erkundigen Sie sich bei den Stakeholdern, was geliefert werden soll und ob sie bereits gesehen haben, dass etwas funktioniert

Sobald Sie diese Informationen erhalten haben, müssen Sie die Probleme ansprechen, von denen Sie erfahren haben.