Praha,

 Představení novinek týkajících se projektového undergroundu  Téma pro dnešní sezení a diskuzi: Akceptace v řízení projektů  Volná diskuze  Závěr

Projektový Underground Sdružení projektových managerů web:

PMBOK: Verify Scope – formalizing acceptance of project deliverables Navazuje na Perform Quality Control –To ověřuje korektnost, správnost –Mohou probíhat i paralelně Vstupy ve vztahu k rozsahu –Project scope statement, WBS, requirements documentation Nástrojem pouze inspekce Výstupem i změnový požadavek

Rozdělení do kategorií 1.Akceptační kritéria – definice 2.Zodpovědnosti v rámci akceptačního řízení 3.Zákazník nedodržuje domluvené termíny, rozsah a součinnost 4.Akceptace v návaznosti na finanční plnění

1.Akceptační kritéria – definice (1/5) Jaká kritéria nastavit pro akceptaci dokumentů (dokumentace, analýzy, cílová koncept, apod.)? V jakých „fázích“ projektu „co“ akceptovat a jakým způsobem? Jaká kritéria úspěšnosti nastavit pro pilotní provoz? Kolik kol (připomínky-zapracování) považujete za optimální pro akceptaci dokumentů (dokumentace, analýzy, cílová koncept, apod.)

1.Akceptační kritéria – definice (2/5) Je lepší stanovit akceptační kritéria předem (např. již v rámci nabídky nebo ve smlouvě) nebo je lepší počkat až na fázi implementace kdy je situace jasnější, ale zároveň může dojít k rozepřím se zákazníkem? PM nastoupil na již běžící projekt. Jak přinutit zákazníka na již běžícím projektu definovat pravidla pro akceptaci, která nebyla definována?

1.Akceptační kritéria – definice (3/5) Ideální stav je pokud lze konkrétní akceptační kritéria ve velmi raných stadiích projektu a nejlépe je spolu s popisem akceptačního procesu vložit jako přílohu ještě přímo do smlouvy se zákazníkem.. –Jak se ale postavit k situaci kdy to z principu projektu před zahájením nelze udělat? –Lze si představit projekty vývoje SW řízené agilními metodikami, kde konkrétní obrys dodávaného SW díla vznikne až po několika iteracích třeba v polovině projektu?

1.Akceptační kritéria – definice (4/5) Používáme 2 modely akceptačního řízení, které zjednodušeně jsou: 1/ Společně se zákazníkem procházíme dodávaný systém a ověřujeme, že jeho funkcionalita je v souladu se zadáním; 2/ Zákazník má dohodnutý počet dnů na to, aby si dodávaný systém vyzkoušel, a když nenajde a nenahlásí závady, je systém akceptován. Potom ještě občas dojde k "divoké akceptaci", kterou smlouva definuje takto: Zákazník se sice pořád brání z různých důvodů akceptovat, ale začne prokazatelně dodávaný systém používat. –Znáte ještě jiné způsoby jak provádět ?

1.Akceptační kritéria – definice (5/5) Jak na čtení detailních analýz (analytických zadání) zákazníkem? –interpretace detailních analýz (analytických zadání)? –schvalování velkého objemu, pro zákazníka málo srozumitelné, dokumentace? –prototyp? jak co nejpresneji definovat akceptacni behem zadani a objednani projektu v dobe, kdy presna specifikace reseni je stale "high level" a je soucasti dodavky projektu (plati napr. pro SI projekty) jak udrzet behem projektu akceptacni testy v planovanem case a obsahu (zejmena pokud se vyskytuje velke mnozstvi chyb) rozdeleni akceptace na podminecnou a finalni - vyhody a nevyhody

2. Zákazník nedodržuje domluvené termíny, rozsah a součinnost (1/4) Často se stává, že součinnost při akceptaci (připomínky, testování zákazníkem apod.) trvá déle než je naplánováno v harmonogramu. Jak donutit zákazníka, aby harmonogram dodržoval! (téměř vždy si to posune a nic se mu nestane) Jak zabránit odbíhání zákazníka od domluvených (např. smluvně) akceptačních scénářů - testovat se má A a během toho testu zákazníka napadne, že by chtěl otestovat i B, na které není akceptační scénář a z toho plyne opět prodlužování akceptace? Je správné nechat klienta v průběhu akceptace podle předem schválených akceptačních scénářů doplňovat ještě další body na úkor posunu harmonogramu?

2. Zákazník nedodržuje domluvené termíny, rozsah a součinnost (3/4) jak ostatní řeší situace, kdy odpovědný zástupce zákazníka odmítá akceptovat. A to buď zcela bez důvodu (strach ze zodpovědnosti) nebo argumentuje problémy zcela mimo projekt (o kterých se dříve nezmínil) – např. že teď to nejde, protože nemají peníze na uhrazení navazující fakturace, nebo jinak, podobně? Jak předcházet (až) při akceptaci situacím typu: tohle jsme nechtěli, tak jsme to nemysleli, předpokládali jsme, že to bude tak jak jsme zvyklí,.... Z pohledu dodavatele: Jak slušně/politicky uřídit zákazníka, který přidává nová a nova akceptační kriteria a oddaluje podepsaní akceptace (zpravidla dodavatel má ke konci projektu termínový skluz a nedobrou vyjednávací pozici).

2. Zákazník nedodržuje domluvené termíny, rozsah a součinnost (4/4) Jak motivovat zákazníka k detailnějším akceptačním testům? Jde mi zejména o relativně pozitivní situaci, kdy zákazník je ochoten akceptovat, ale o výsledek dodávky se nezajímá. Tzn. nechce věnovat čas na podrobnější akceptační testy. Nakolik je vhodné zákazníka k detailnější akceptaci "nutit". Jaká je zažitá zkušenost v předcházení a řešení „nedorozumění“ při akceptaci –představa zákazníka o tom, co si představuje, že má být dodáno, je mírně odlišná od toho, co bylo dodáno, přestože bylo korektně dokumentován postup projektu a měnící se představy zákazníka, které byly i zapracovávány (zákazník odmítl podepsat na začátku cílový koncept).

3. Zodpovědnosti v rámci akceptačního řízení (1/3) Jakou úlohu plní ve vztahu k zákazníkovi, zejména ve fázi akceptace, preciznost projektového manažera? Komu přísluší vypracování akceptačních testů? Jak přinutit zákazníka (klíčového uživatele), aby převzal zodpovědnost za úkon akceptace / výsledek. Jaké je pro vás ideální nastavení spolupráce (komunikace, rozdělení úkolů, reportování) s akceptačním týmem? Uznani priority a dulezitosti projektu vsemi zucastnenymi stranami.

3. Zodpovědnosti v rámci akceptačního řízení (2/3) Koho je vhodné si k akceptaci přizvat? V případě zakázkového SW je odběratelů větší množství a velmi často se akceptace provádí hlavně z pohledu splnění požadavku pro fakturaci, což není ideální. Metodika v tomto pomáhá, ale zajímají mne spíše praktické zkušenosti z ČR. Měla by akceptace být čistě záležitostí zákazníka (tzn. během vyhrazeného času testuje zákazník sám a reportuje chyby, dodavatel do testování nezasahuje) nebo je lepší aby se dodavatel akceptačních testů aktivně účastnil a poskytoval podporu zákazníkovi.

3. Zodpovědnosti v rámci akceptačního řízení (3/3) Jak a kdy nejpozději co nejlépe pochopit co zákazník od akceptace očekává, kdo bude ve skutečnosti akceptovat (uživatel; vedoucí pracovník; technické oddělení, které však není konečným uživatelem, ale pouze poskytuje podporu produktu na straně zákazníka)? Jaké jsou způsoby, postupy a reálné možnosti řízení těchto očekávání zákazníka (formální i neformální)? Jak by mělo vypadat ideální předání produktu k akceptaci (akceptačním testům) zákazníkem? Interní verifikace produktu na straně dodavatele, informace (výzva) zákazníkovi o blížící se akceptační fázi, další nezbytné kroky které je třeba udělat.?

4. Akceptace v návaznosti na finanční plnění (1/1) Jaké mají ostatní zkušenosti s akceptací před dokončením (např. ve státní správě potřebují utratit peníze před koncem roku) a následně s dokončení onoho zajíce v pytli. Jaké jsou zkušenosti s akceptací nenavázanou na platební milníky? A obráceně s fakturací nenavázanou na akceptaci