Popis produktu projektu - Project Product Description
Popis produktu projektu je speciální forma Popisu produktu, která definuje, co má projekt dodat, aby byl akceptován. Používá se na:
- Získání souhlasu od uživatele ohledně rozsahu projektu a požadavků
- Definování zákazníkova očekávání kvality
- Definování akceptačních kritérií, metod a odpovědností za projekt
Popis produktu pro produkty projektu je vytvořen v procesu Zahájení projektu jako součást úvodních aktivit a je detailizovaný během procesu Nastavení projektu, když se vytváří plán projektu. Podléhá formální proceduře kontroly změny a měl by být zkontrolován na hranicích etapy (během procesu Správa hranic etapy), aby se zjistilo, zda se žádají nějaké změny. Rovněž se používá v procesu Ukončení projektu jako součást ověření, že projekt dodal co se od něj očekávalo, a že se splnily akceptační kritéria.
Popis produktu projektu by měl pokrýt následující oblasti:
- Název
- Účel
- Složení
- Vyrobeno z:
- Vývojové dovednosti
- Zákazníkovy očekávání kvality
- Akceptační kritéria
- Projektové tolerance kvality
- Akceptační metody
- Akceptační odpovědnosti
Popis produktu projektu je odvozen z Mandátu projektu, diskusemi s Hlavním uživatelem a Výkonným ředitelem, možná prostřednictvím semináře a požadavky na návrh (pokud se nachází v prostředí dodavatel / odběratel).
Dokumenty PRINCE2® ke stažení PDF
Dokumenty PRINCE2® ke stažení WORD
Vytváření, aktualizace a použití
Popis produktu projektu vytváří Projektový manažer ve spolupráci s Hlavním uživatelem v procesu Zahájení projektu. Obsahuje Zákazníkovy očekávání kvality a akceptační kritéria. Definuje celkový (konečný) produkt, který má projekt dodat. Popis produktu projektu se používá při vytváření produktového rozpadu (technika produktově orientovaného plánování) k definování produktů. Popis produktu projektu může být aktualizován v případě, že Hlavní uživatel požaduje jeho změnu.
Project Product Description
The Project Product Description is a special form of Product Description that defines what the project must deliver in order to gain acceptance. It is used to:
- Gain agreement from the user on the project’s scope and requirements
- Define the customer’s quality expectations
- Define the acceptance criteria, method and responsibilities for the project.
The Product Description for the project product is created in the Starting up a Project process as part of the initial scoping activity, and is refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at stage boundaries (during Managing a Stage Boundary) to see if any changes are required. It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it, and that the acceptance criteria have been met.
The Project Product Description should cover the following topics.
- Title 4
- Purpose 4
- Composition 4
- Derivation 4
- Development Skills Required 4
- Customer’s Quality Expectations 5
- Acceptance Criteria 5
- Project Level Quality Tolerances 5
- Acceptance Method 5
- Acceptance Responsibilities 5
The Project Product Description is derived from the project mandate, discussions with the Senior User and Executive – possibly via scoping workshops and the request for proposal (if in a commercial customer/supplier environment).
A Product Description for the project product can take a number of formats, including: Document, presentation slides or mind map; or Entry in a project management tool.
The following quality criteria should be observed:
- The purpose is clear
- The composition defines the complete scope of the project
- The acceptance criteria form the complete list against which the project will be assessed
- The acceptance criteria address the requirements of all the key stakeholders (e.g. operations and maintenance)
- The Project Product Description defines how the users and the operational and maintenance organizations will assess the acceptability of the finished product(s):
- All criteria are measurable
- Each criterion is individually realistic
- The criteria are realistic and consistent as a set. For example, high quality, early delivery and low cost may not go together
- All criteria can be proven within the project life (e.g. the maximum throughput of a water pump), or by proxy measures that provide reasonable indicators as to whether acceptance criteria will be achieved post-project (e.g. a water pump that complies with design and manufacturing standards of reliability)
- The quality expectations have considered:
- The characteristics of the key quality requirements (e.g. fast/slow, large/small, national/global)
- The elements of the customer’s quality management system that should be used
- Any other standards that should be used
- The level of customer/staff satisfaction that should be achieved if surveyed.
Komentáře
Pro přidávání komentářů se musíte přihlásit.