U větších projektů doporučuji vytvořit Matici sledovatelnosti požadavků. Další informace najdete zde:

Matice sledovatelnosti požadavků v projektovém managementu (příklad + šablona)

Proces č. 2: Jak omezit požadavky a definovat rozsah

Zde je požadavek :

„Web pmbasics101.com by měl mít schopnost shromažďovat e-maily a na oplátku rozesílat dokumenty PDF.“

Co je zapotřebí k splnění tohoto požadavku?

1. Vyberte poskytovatele poštovních služeb.
2. Vytvořte si účet.
3. Navrhněte formulář pro shromažďování e-mailů.
4. Implementujte navržený formulář.
5. Nainstalujte plugin od poskytovatele poštovních služeb.
6. Nahrajte dokument PDF.
7. Aktivujte formulář.
8. Otestujte formulář.

Je to jen seznam požadovaných akcí. Kdybych to správně uvedl jako doručitelný a pracovní balíček, skončilo by to:

1. Email Opt – ve formuláři
   1.1 Zpráva o poskytovatelích poštovních služeb
   1.2 Schválený návrh formuláře
   1.3 Formulář pro přihlášení v testovacím prostředí
   1.4 Zpráva o zkoušce

Takže, jak vycházíte z požadavku jedné věty na skutečný rozsah práce?

A) Můžete najít někoho, kdo má relevantní zkušenosti nebo znalosti

Mohou to být zúčastněné strany, zákazníci nebo externí konzultanti, experti na předmět nebo jiné strany.

Takže vaším cílem je získat je od projektového týmu nebo se jen spojit a komunikovat. Možná již mají řešení.

Jinak můžete získat pokyny nebo radu. Jedná se o základní techniku, kterou budete široce používat.

B) Proveďte analýzu produktu

Je použitelná, když potřebujete vytvořit produkt, nikoli službu nebo výsledek.

Tato technika se zaměřuje na rozklad hodnoty produktu. Stejně jako to dělá WBS s rozsahem.

Dále musíte produkt analyzovat z ergonomického a funkčního hlediska; a poté rozhodovat o materiálech nebo procesech, které budou splňovat výkonnostní požadavky.

25 Příklady analýzy produktů

Celkově je vaším cílem definovat hmatatelné výsledky.

C) Použijte techniku generování alternativ

Tato technika funguje dobře, pokud máte odborné znalosti o povaze projektu.

Takže musíte najít nejlepší řešení pro splňují požadavky. Ve většině případů využijete brainstorming k získání alternativ.

Jaký je cíl?

Musíte jasně definovat, co je a co není součástí rozsahu projektu.

Proces č. 3: Správa rozsahu projektu pomocí softwaru PM

Určitě můžete sledovat rozsah projektu v jakékoli dostupné aplikaci. Například Google Drive, Evernote nebo MS Word.

Existují však vážné výhody v používání integrovaného softwaru pro správu projektů, aby bylo vše na jednom místě.

V ideálním případě byste musí být schopni propojit požadavky s výstupy projektu.

Potom od dodávky ke konkrétním úkolům s odhady, souvisejícími riziky a závadami.

Například mohu doporučit Paymo. Je to jedna z nejlepších aplikací pro osobní použití a pro malé projekty. Kromě toho má skvělé funkce pro sledování času a fakturaci.

Proces č. 4: Jak řídit rozsah projektu

Nestačí na začátku identifikovat 100% rozsahu projektu . Tato 100% se během životnosti projektu změní.

Takže potřebujete způsob, jak monitorovat, kontrolovat a provádět změny v rozsahu.

Léčba je dobře známá. Je to struktura rozložení práce.

No, také potřebujete jasný pracovní postup, abyste mohli provádět změny ve všech oblastech projektu, kdykoli se změní množství práce.

Je to však otázka integrovaného procesu správy změn.

V čem je tedy háček?

Potřebujete vysoce kvalitní WBS. Kromě toho potřebujete nerdy popsat rozsah projektu. Proto také potřebujete prohlášení o rozsahu projektu. Budeme o tom diskutovat níže.

Pokud jste na agilním projektu, je ještě důležitější jasně definovaný rozsah přírůstku nebo iterace. Nemyslete si, že agilní vám ušetří důkladné zdokumentování práce, kterou je třeba udělat. Udržujte svůj nevyřízený sprint a uživatelské příběhy čisté. Použijte jednoduché pravidlo: „Nováček by měl pochopit, co je třeba udělat z popisu uživatelského příběhu.“

Jak ověřit rozsah

Jednou za čas musíte získat formální podepsat, že produkt splňuje očekávání zúčastněných stran.

Je zásadní to dělat průběžně během celého projektu.I když vedete projekt řízený plánem, nemělo by vám nic bránit v poskytování přírůstků produktů ke kontrole.

Proč to potřebujete?

Nechcete získat všechny požadavky na změnu, všechny vady a „drobné změny projektu“ na konci.

Připravíte se o možnost skutečně začlenit změnu do projektu.

Čím blíže jste k uzavření projektu, tím méně času a zdrojů zbude. Kromě toho budou zúčastněné strany méně náchylné k vyjednávání změn rozsahu, harmonogramu nebo rozpočtu. Také vytvoří větší tlak na tým, aby získejte to, co potřebují.

Pouhé uvedení zřejmého:

Je velmi důležité mít od začátku jasně popsaný a schválený rozsah projektu.

Když dodávka nesplňuje očekávání, budou provedeny opravy.

Je vaší odpovědností prokázat, zda je oprava požadavkem na změnu, a proto by měla být správně integrována. Jinak se jedná o vadu a musíte to napravit. Někdy na vlastní náklady.

Jak ve skutečnosti ověřujete rozsah se zákazníky?

U libovolného projektu můžete použít ukázkovou schůzku podobnou Scrumu.

Jen připravit krátkou ukázku plnění. Vysvětlete aktuální stav projektu a jeho průběh. Poté upozorněte na známé vady a nedokončené součásti.

Také shromažďujte zpětnou vazbu od zákazníka. Později můžete poskytnout veškerou podpůrnou dokumentaci a zprávy požadované vašimi zásadami.

Sečteno a podtrženo:

Sbírat zpětnou vazbu od zúčastněných stran průběžně. Vyjednejte podmínky zavedení nových požadavků na změnu. Udržujte základní osnovu rozsahu projektu aktuální.

Získat moji šablonu pro správu rozsahu projektu

Nevynalézejte kolo! Může to být pro vás nákladné.

Stačí kliknout na tlačítko níže a získat moji šablonu fill-in-the-blanks. Dodává se s průvodcem zdroji všeho, co potřebujete o správě oboru vědět.

Proč celý rozsah Základní úroveň je pro váš projekt kritická?

Obvykle projekt začíná a my dostáváme požadavky v různých formách.

Například: e-maily, soubory PDF, schůzky, makety, hlášení o chybách, cokoli .

Samozřejmě nepřipravujeme projektovou chartu ani nic podobného. Špatný postup!

Ve většině případů nediskutujeme ani o obchodním případu projektu.

Obvykle vytváříme strukturu rozpisu práce.

Používá se však pouze interně a nikdy nepřichází zákazníkovi. Poté rozložíme práci na aktivity a odhadneme projekt. Používáme techniku odhadu zdola nahoru.

Nyní přichází první kontrola očekávání:

Představujeme odhady pro projekt.

Vidíte, zjevně existuje nedostatek transparentnosti zde. Zákazník neví, jakou práci jsme ve skutečnosti odhadli.

Pokud je odhad blízký očekávání zákazníka, nebude se zabývat podrobnostmi. Důvodem je, že je připraven už tolik peněz a času utratit. Nechce ztrácet svůj drahocenný čas.

Tady je pravda:

Mnoho organizací a projektových manažerů skrývá neefektivitu za takovými tichými dohodami.

Je to téma pro samostatný příspěvek, ale je hlavní příčinou mnoha vašich problémů.

Co se stane dál?

Zahájíme realizaci projektu! Dříve nebo později zákazník požádá o přidání dalšího díla.

Poté najdeme část neidentifikované práce. Později se objeví problémy s kvalitou. Hodně času sežerou.

Celkově předáme dodávku, abychom zjistili, že jsme udělali něco špatně.

A tehdy nás zákazník informuje, že on zapomněl jsem na něco a mělo by to být přidáno co nejdříve.

Věřte mi, narazíte na to více než jednou.

Definice základny rozsahu

”Základna rozsahu je schválená verze prohlášení o rozsahu, struktury rozložení práce (WBS) a souvisejícího slovníku WBS, které lze změnit pouze prostřednictvím formálního postupu kontroly změn a slouží jako základ pro srovnání. “ -PMBOK® Guide

Co je to prohlášení o rozsahu projektu?

Definice prohlášení o rozsahu projektu

Prohlášení o rozsahu projektu je popisný popis produktu a rozsahu projektu.

Používá se jako písemné potvrzení toho, co a jak bude váš projekt produkovat.

Jaký je klíč k hodnotnému prohlášení o rozsahu projektu?

Domnívám se, že musíte používat výrazy a jazyk, kterému rozumí každá zúčastněná strana. Tato základní část rozsahu projektu je hlavně pro zákazníka.

Dobře, co by mělo být zahrnuto?

Odůvodnění projektu

Je to krátký popis potřeby podnikání. Někdy stačí jedna věta. Zbytek by měl zůstat v Chartě projektu.

Rozsah produktu

Je to popis charakteristik, vlastností a funkčnosti produktu nebo služby, které budete vyrábět.

Nezapomeňte, že jste shromáždili požadavky od různých zúčastněných stran. Nepředpokládejte tedy, že každý z nich sleduje každý požadavek. Také není vždy jasné, kolik práce je zapotřebí k splnění požadavku.

Je to primární místo pro sladění očekávání klíčových zúčastněných stran.

Musíte ukázat množství a složitost práce potřebné ke splnění různých požadavků. Proto věnujte této části maximální úsilí.

Kritéria přijetí

Je nutné splnit podmínky, než budou přijaty výstupy projektu.

Můžete zahrnout přijatelná úroveň a počet vad také zde.

Výstupy

Je to popis všech výstupů, které váš projekt vyprodukuje.

Může zahrnovat produkt nebo služba, projektová dokumentace, návody k produktu, výukové materiály pro váš produkt atd.

Vyloučení projektu

Zde je třeba určit, co je mimo rozsah projektu.

Docela často chce část zúčastněných stran něco konkrétního. Druhá část zúčastněných stran nebo zákazník to nepodporuje.

Proto se jedná o konfliktní situaci. Jakmile bude konflikt vyřešen a bylo rozhodnuto něco odstranit z rozsahu projektu, vložte jej sem.

Buďte konkrétní a velmi jasní. Šetří čas do budoucna.

Za prvé, nebudete muset znovu tyto vyloučení projektů znovu prohlížet. Zúčastněné strany se mohou pokusit zahrnout je později během realizace projektu.

Pokud se však něco dramaticky nezmění, neměli byste ztrácet čas kontrolou vyloučení.

Zadruhé, pokud to není jasně uvedeno, někdo může stále očekávejte, že to dodáte. Neskrývejte falešná očekávání. Na konci bude snazší projekt předat.

Omezení

Zde by mělo být uvedeno cokoli, co vás omezuje v tom, abyste produkt mohli dodávat efektivně.

Předpoklady

Jedná se o nejistoty, které nelze v tuto chvíli vyjasnit.

Některé z nich musíte během plánování přijmout. V případě, že se předpoklad ukáže jako neplatný, budete mít právo projektový plán upravit.

Zákazník by měl schválit prohlášení o rozsahu projektu. Ve skutečnosti se jedná o formální a vzájemnou dohodu.

Rovněž uvádí, že jste odhodláni poskytovat popsané výsledky za definitivního předpokladu a s jasnými omezeními. Na druhou stranu zákazník souhlasí s přijetím zadaného výsledku.

To neznamená, že nemůžeme změnit rozsah projektu. Ne. To znamená, že pro provedení změny – musíme upravit dohodu.

Uspořádat rozsah projektu pomocí WBS

WBS je povinnou součástí základní linie rozsahu u všech projektů. Velký nebo malý. Agilní nebo řízený plánem.

Již v základech PM existuje kompletní průvodce strukturou rozpisu prací. Nebudu to zde opakovat.

Chci zdůraznit pouze jeden zásadní bod:

Dodávky popsané v prohlášení o rozsahu projektu by se měly dostat do WBS tak, jak jsou. Zajistěte konzistentnost výstupů v celém projektu.

Vložte vše, co víte, do slovníku WBS

Slovník WBS je dokument, který popisuje práci, kterou je třeba provést pro každý pracovní balíček.

Jako moderní PM bych řekl, že by měl být součástí systému sledování úkolů. Většina softwaru pro správu projektů vám umožňuje uchovávat tyto informace na jednom místě.

Proto bych vám nedoporučoval vytvořit samostatný dokument. Údržba slovníku WBS je hodně práce. Hledejte integrovaná řešení.

Můžete zahrnout jakékoli informace, které specifikují komponentu v WBS. Například slovník WBS může obsahovat:

• Popis práce
• Předpoklady a omezení
• Odpovědní lidé nebo organizace
• Milníky
• Související činnosti
• Požadované zdroje
• Odhady nákladů nebo rozpočet
• Kritéria přijetí
• Odkazy na další dokumentaci

Takže cokoli vyhovuje vašim potřebám a pomůže vám integrovat WBS do jiných procesů.

Závěr

„Námořník, který neví, kde je přístav, nefouká přímo vítr.“

Nemůžete vést projekt k úspěšnému výsledku, aniž byste věděli, co je třeba udělat.

Ještě jednou chci zdůraznit tento bod.

I když jste v agilním prostředí a rozsah není jasně definován pro celý projekt, stále musíte naplánovat způsob, jak definovat, spravovat, sledovat a měnit rozsah projektu.

Oba pro úroveň iterace a konečný výsledek projektu.

Doporučuji také přečíst:

• Vybraný článek: Jak se stát manažerem IT projektu bez zkušeností
• Další v série: Ultimate Guide on How to Create a Robust Work Breakdown Structure
• Předchozí v sérii: Matice sledovatelnosti požadavků v projektovém řízení (Ex dostatek + Šablona)