Projektmanagement@GJW

Wissensbaustein@GJW / Knowledge-Module@GJW

Hybrides Projektmanagement/Hybrid Project Management

DE

Projekt Kurz-Check

Warum:

Laufend für alle möglichen Projektbeteiligten verständlich über den aktuellen Stand aussagefähig sein.

Wie:

Regelmäßig und zusätzlich anlassbezogen die Leitfragen des Projekt-Checks nutzen.

Was:

  • Wie lautet der Arbeitstitel des Projektes?

 

Aus der Phase Definieren (das Why/Warum):

  • Welches Problem liegt dem Projekt zugrunde? … Beim Kunden (Topline-wirksam) oder in der eigenen Organisation (Bottomline-wirksam) … Welcher negative Geschäfts-Impact bei Nicht-Angehen tritt ein?
    Warum wird das Projekt durchgeführt? … Welcher Anteil des negative Geschäfts-Impacts wird gehoben => Geschäfts-Impact des Projektes?
    Wer sind die Ergebnis-Nutzenden?
    Welches Ergebnis erhalten die Ergebnis-Nutzenden (Deliverable – Was geht über den Tisch)?
    Was tun die Ergebnis-Nutzenden unmittelbar nach Erhalt des Ergebnisses (weitere Verwendung)?

 

Aus der Phase Planen (das How/Wie):

  • Was ist der Clou/der Kern/die Unternehmens-DNA des Projektes? … Welches Alleinstellungsmerkmal stellt sicher, dass der aufgeführte Geschäfts-Impact auch im Wettbewerb realisiert wird?

 

Aus der Phase Durchführen (das What/Was):

  • Was wurde bisher erreicht?
  • Was steht als nächstes an?
  • Welche Risiken/Überraschungen/Besonderheiten zeichnen aktuell sich ab?
  • Wie lauteten die Alternativen und Empfehlungen zur Entscheidung?

 

Aus der Phase Abschließen (die Lessons learned):

  • Was hat die Organisation bisher aus dem Projekt für die Zukunft gelernt? … Auf welche Art sind die fachlichen und organisatorischen Erkenntnisse des Projektes dauerhaft und für alle verfügbar (SPOT/SSOT) festgehalten?

EN

Project check light

Why:

Be able to provide information about the current status in a way that is understandable to all project participants on an ongoing basis.

How:

Use the key questions of the project check regularly and when appropriate.

What:

  • What is the working title of the project?

 

From the definition phase (the why):

  • What is the problem underlying the project? … With the customer (topline impact) or in your own organization (bottomline impact) … What negative business impact will occur if it is not addressed?
  • Why is the project being carried out? … What proportion of the negative business impact will be eliminated => business impact of the project?
  • Who are the users of the results?
  • What results do the users of the results receive (deliverable – what goes over the table)?
  • What do the users of the results do immediately after receiving the results (further use)?

 

From the planning phase (the how):

  • What is the highlight/the core/the company DNA of the project? … Which unique selling point ensures that the listed business impact is also realized in competition?

 

From the implementation phase (the what):

  • What has been achieved so far?
  • What is next?
  • What risks/surprises/special features are currently emerging?
  • What were the alternatives and recommendations for the decision?

 

From the completion phase (the lessons learned):

  • What has the organization learned from the project so far for the future? … How are the technical and organizational findings of the project recorded permanently and available to everyone (SPOT/SSOT)?

DE

Design-Score-Card

Warum: Gemeinsame Basis für die Entscheidung vereinbaren, ob der Projektliefergegenstand am Ende des Projektes ein Gut- oder ein Schlecht-Teil ist.

.

Wie: Im >Definieren< die erarbeiteten messbaren Kundenanforderungen/CTQ (Critical to Quality) verankern; im >Planen< zur Konzeptauswahl nutzen; im >Durchführen< und >Abschließen< zum Messen des Projekt-Erfolges nutzen.

.

Was: Woher wissen Sie am Ende des Projektes, ob Sie das Ziel erreicht haben?

Dafür benötigen Sie eine abgestimmte und messbare Vereinbarung darüber, was ein Gut- und was ein Schlecht-Teil bei der Bewertung des Liefergegenstandes darstellt. Diese Vereinbarung kann mit Hilfe des Werkzeuges Design-Score-Card festgehalten werden.

In der Design-Score-Card sind die messbaren Kundenanforderungen/CTQ (Critical to Quality) festgehalten. Achtung: Dies bezieht sich auf das Projektergebnis, den Kunden des Projektergebnissies und die weitere Verwendung des Projektergebnisses durch den Kunden. Dies ist nicht zu verwechseln mit der Verwendung eines Endproduktes durch Endnutzer im Rahmen einer Produktentwicklung.

Sollte die Organisation, die das Projekt durchführt, Rahmenbindungen setzen, die nicht aus den Kundenanforderungen heraus begründet sind, würden diese in Form von messbaren Randbedingungen/CTB (Critical to Business) festgehalten werden. Dies könnten Nutzen bestimmter Herstellprozesse, Verwendung bestimmter Materialien, Nutzen bestehender Vertriebsstrukturen etc. sein. Das festlegen von CTB birgt das Risiko den Innovationsgrad nicht voll auszuschöpfen und dem Wettbewerb ein Vorteil zu ermöglichen oder aus einer Aktualität heraus auf einen ungeeigneten Trend aufzuspringen.

EN

Design-Score-Card

Why: To establish a common basis for deciding whether the project deliverable at the end of the project is a good or bad part.

.

How: Anchor the developed measurable customer requirements/CTQ (Critical to Quality) during >Define<; use them for concept selection during >Plan<; utilize them for measuring project success during >Execute< and >Close<.

.

What: How do you know at the end of the project whether you’ve achieved the goal?

For this, you need a coordinated and measurable agreement on what constitutes a good or bad part when evaluating the deliverable. This agreement can be documented using the Design Score Card tool.

The Design Score Card records the measurable customer requirements/CTQs (Critical to Quality). Note: This refers to the project outcome, the customer of the project outcome, and the further use of the project outcome by the customer. This should not be confused with the use of an end product by end users within a product development context.

If the organization conducting the project imposes constraints that are not justified by customer requirements, these would be documented in the form of measurable constraints/CTBs (Critical to Business). These could include the benefits of certain manufacturing processes, the use of specific materials, or the utilization of existing distribution structures, etc.. Specifying CTBs carries the risk of not fully exploiting the level of innovation and giving the competition an advantage or jumping on an unsuitable trend out of urgency.

Geplante/Erforderliche Verbesserungen

AsldaflAdflk<fdlk<dfLKAnfdLKAdf_LAkfdlakdnf-lakdnfkdanf-akdf_d