Co je to logický rámec projektu? Podrobně se o tomto nástroji dočtete v nejedné publikaci, mimo jiné i v metodice IPMA. Dnes Vám zde nebudu popisovat příliš teorie, ale rád bych Vám ukázal, jak mi tento nástroj pomáhá v praxi řízení projektů.
Na začátek tedy něco málo z teorie.
Logický rámec (také logická rámcová matice – LRM) slouží jako pomůcka při stanovení základních parametrů projektu. Jde o součást metodiky návrhu a řízení projektu označované jako „Logical Framwork Approach (LFA)“. Celkově jde o nástroj, který uceleně řeší všechny etapy projektu od přípravy, přes návrh a realizaci až po vyhodnocení projektu (Zdroj: http://www.pmconsulting.cz/pm-wiki/logicky-ramec/).
Tato metodika vznikla již v 70. letech minulého století ve spolupráci firmy Principals Concepts Inc. – PCI a USAID, tedy United States Agency for International Development. Díky své univerzální koncepci se velmi rychle se rozšířila do mnoha odvětví nejprve v USA a následně do více než 35 zemí po celém světě. (Zdroj: http://www.pmconsulting.cz/pm-wiki/logicky-ramec/)
Jak logický rámec vypadá? Jde o tabulkový zápis rozkladu projektu do jednodušších celků, doplněný o akceptační kritéria každého z nich a podmínky, za kterých je možné jich dosáhnout. Zdroje (lidé i materiál, zboží, SW), se kterými projekt budu dodávat a náklady na tyto zdroje. Často se také do matice uvádí, co není součástí projektu.
| Přínosy | Objektivně ověřitelné ukazatele | Zdroje informací k ověření (způsob ověření) | Název projektu
Projektový manažer Datum |
| Cíl | Objektivně ověřitelné ukazatele | Zdroje informací k ověření (způsob ověření) | Předpoklady, za jakých Cíl skutečně přispěje a bude v souladu s Přínosy |
| Výstupy | Objektivně ověřitelné ukazatele | Zdroje informací k ověření (způsob ověření) | Předpoklady, za jakých Výstupy skutečně povedou k Cíli |
| Klíčové činnosti | Zdroje (peníze, lidé, …) | Časový rámec aktivit | Předpoklady, za jakých Klíčové činnosti skutečně povedou k Výstupům |
| Zde některé organizace uvádí, co NEBUDE v projektu řešeno | Případné předběžné podmínky | ||
Tabulka 1 – Obecná struktura Logického rámce projektu
Jak přesně s logickým rámcem projektu pracovat si můžete přečíst například v publikaci Projektový management podle IPMA, kde je celá problematika podrobně vysvětlena.
Jak mi v praxi logická rámcová matice pomáhá?
Logická rámcová matice (dále jen LRM) je velmi univerzální a jednoduchý nástroj pro řízení projektů. Osobně jej používám jak ve fází plánování, tak v dalších fázích projektu. Můj přístup je následující.
Ve fázi plánování sestavím základní strukturu LRM, to znamená, že dle požadavků, které mám od zákazníka projektu, stanovím jasný a měřitelný cíl, po dohodě se zákazníkem nastavím i očekávané přínosy. Navrhnu rozpad cíle do dodávek a sepíšu základní aktivity (tedy úkoly), které je třeba odpracovat a s kým, abych měl s projektovým týmem o čem diskutovat. Tato metoda se mi osvědčila hlavně proto, že nenechávám aktivitu pouze na projektovém týmu, ale povzbudím je hned na začátku tím, že něco je již hotovo. Ale jako projektový manažer nejsem schopen sám postavit celý věcný rozsah každého projektu, ani to není mým úkolem, proto se opravdu ani nesnažím LRM vymyslet sám – i když bych někdy mohl. Dokonce často úmyslně vynechám některé „dodávky“ nebo „aktivity“, abych podpořil diskusi týmu. Členové týmu mi potom sami doplňují dodávky, na které jsem „zapomněl“ a rozpadají je do aktivit, které je nutno odpracovat, aby vůbec dodávka vznikla. V rámci této diskuse již rovnou slýchám, čeho se projektový tým obává, tedy hrozby pro budoucí analýzu rizik. Tyto hrozby osobně přetavím do podmínek, za kterých jsme schopni projekt dodat. Ty zapisuji do 3. sloupce, a to i přesto, že to není úplně metodicky správně, protože v tomto sloupci by měly být pouze externí hrozby, které nemohu nijak ovlivnit. Nicméně v praxi se mi osvědčilo, že 3. sloupec v podstatě používám jako zjednodušený risk log.
Když mám tímto způsobem naplánovaný projekt s přiřazenými zdroji a náklady na ně, ptám se návodně týmu dál, abych dokázal vyplnit i 1. a 2. sloupec. To znamená, ověřitelné ukazatele, že byl úkol či dodávka nebo cíl splněn a dle čeho tak soudím. Používám aktivační dotazy. Jak mi dokážete, že je váš úkol splněn, tak, abych to pochopil, i když danou problematiku neznám? (to je dotaz na 1. sloupec) Proč mám věřit tomu, že dané měření je správné? (dotaz na 2. sloupec). Tímto způsobem vyplním ke každé dodávce i cíli měřitelné ukazatele a zdroje, na základě kterých tyto informace dodávám.
Uvedu příklad z praxe.
Otázka:
Jak mi dokážete, že jsme nakonfigurovali daný HW správně?
Odpověď:
Provedeme akceptační testy a doložíme, že zařízení funguje.
Otázka:
Proč mám věřit akceptačnímu testu, který jste provedli?
Odpověď:
Tento akceptační test byl proveden v souladu s ISO, požadavky zákazníka apod.
Otázka:
A kde to všechno naleznu?
Odpověď:
Existují akceptační scénáře, popsané například v příloze Zadávací dokumentace, nebo v normě, ISO.
Dále se ptám na hrozby.
Otázka:
Čeho se v rámci dodávky XY obáváte, co by se mohlo pokazit, nebo na čem je to závislé?
Odpověď:
V dané dodávce bývá problém s nestabilní kvalitou SW od výrobce.
Daný HW nemusí být plně kompatibilní se sítí zákazníka, i když je to v dokumentaci od výrobce napsané.
Existuje reálná možnost, že HW nedorazí v avizovaném termínu.
Bude nutná spolupráce s autoritou. Osvědčení, certifikace apod.
Tímto způsobem si udělám obrázek o tom, co všechno je třeba udělat, abych dodal všechny části projektu a následně tím splnil cíl. Také zjistím, co mi hrozí, na co se raději připravit předem a případně to i komunikovat se zákazníkem projektu. Kolik mne to bude nakonec stát nehledě na to, za kolik byl projekt prodán. Koho budu potřebovat do projektového týmu a co všechno musím objednat za zboží, nebo také podpůrné materiály a pomůcky pro členy týmu.
Po interní schůzce s projektovým týmem běžně s LRM odcházím k zákazníkovi projektu, kde mu na té stejné matici prezentuji realitu projektu. Opět formou dotazů.
Vážený zákazníku, pochopil jsem to tak, že to, proč to všechno děláme je, že potřebujete dosáhnout přínosu ve formě X. Počkám na souhlas.
Víte, že tyto přínosy nejsou v kompetenci projektu, který děláme, protože mimo dodání cíle našeho projektu musí nastat podmínky Y? Počkám na souhlas, případně vysvětluji.
Nyní k cíli. Je toto cíl, na kterém se stále shodneme? Dodat Z do 1.1 za peníze P? Počkám na souhlas, případně vysvětluji.
Nyní tedy k vysvětlení toho, jak cíle dosáhneme, co budeme potřebovat a za jakých podmínek můžeme cíl garantovat. Zde vysvětluji rozpad na dodávky, jak dokážeme, že jsme je splnili, kdy to budeme kontrolovat a jak.
Následně pouze rychle naznačím, že za dodávkami stojí celá řada úkolů, abych podpořil to, že projekt není jednoduchou záležitostí a ujistil zákazníka, že přesně víme, co všechno je třeba udělat, abychom společně uspěli.
Jako poslední věc shrnu, o čem jsme se bavili, a dodám, co není v rozsahu projektu řešeno, je to mimo scope.
Pokud je k tomu možnost, LRM si zákazníkem nechám podepsat.
Ve fázi realizace následně kontroluji jednotlivé úkoly, které mají přiřazeni konkrétní lidé a hlídám pracnost (a náklady), které na úkol byly odhadnuty, naplánovány.
Mám do celého projektu VHLED, vím, co se má stát, abych docílil jednotlivých dodávek a jak si ověřím a následně budu deklarovat, že byly splněny správně a v plném rozsahu. Dále monitoruji a řeším hrozby, případně rozpracované do rizik, které jsme zapsali v podmínkách.
Ve fázi ukončení a vyhodnocení projektu mám podklad pro akceptaci projektu jako celku, LRM použiji jako check list a součást akceptačního protokolu se zákazníkem projektu.
Interní vyhodnocení projektu provedu také na základě LRM, kdy mám prostor porovnat skutečné plnění, náklady, termíny s plánem pro jednotlivé celky i projekt celkově.
Článek připravil Jakub Vodička a byl publikován ve 3. čísle Zpravodaje 2018
Čas věnovaný těmto činnostem se bohatě vrátí zefektivněním komunikace s okolím.
