Transcript Příprava a otázky

Praha,
3.6.2010
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

 Co vše se událo od našeho posledního
setkání
– Nový design našich webových stránek, a
hlavně nové informace
– Dárek
– Místa k jednání
Projektový Underground
Sdružení projektových managerů
web: www.mypmi.eu
e-mail: [email protected]
• 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