Zadání projektu

Projekt se vyznačuje nejistotou.

Neumíme specifikovat výstupy

Pokud děláme něco nestandardního, obvykle víme předem jenom to, že "všechno bude jinak". Toto je předběžný nástřel, jak by to možná šlo vyřešit. Předpoklad - zadavatel a realizátor (rozumí se spíše externí dodavatel, viz dále) jsou schopni se dohodnout, že:

  • Výsledky musí být předem sjednány (což je podstata tohoto návrhu, viz dále/později).
    Pokud lze hodnotu výstupu určit oceněním získaného užitku, částka představuje základ nákladového limitu (viz též projektový záměr).
  • Dosažené výsledky je nutno vyhodnotit/změřit a lze najít způsob, jak to dělat (nejlépe průběžně).
  • Dodavatel bude detailně evidovat provedené práce & nedělá žádné jiné práce než podle plánu prací. Plán prací je závazný.
  • Změna vlastností výstupů znamená změnu pracnosti / plánu práce. Pokud se na podobě či důsledcích změn nelze dohodnout, spolupráce končí a zadavatel uhradí dodavateli provedenou práci v dohodnutých sazbách. 
    Sazby jsou iniciálně vědomě natolik nízké, aby dodavatel měl výrazně větší zájem v projektu pokračovat, než jej opustit (tedy hledat dohodu). Pokud se s touto možností od začátku počítá, mělo by to vést k rozumným opatřením na obou stranách (např. sjednání podmínek předání rozpracovaných kroků, důsledné plánování a přebírání práce atd.).
  • Neočekávané změny situace (překážky) znamenají změnu plánu práce.
  • Změny plánu práce / vlastností výstupů ovlivňují jejich (nákladovou) hodnotu (cenu za provedení projektu).
  • Cena bude průběžně upravována a je potřeba se na ní shodnout. Nemá být prostým součtem nákladové hodnoty provedené práce (viz dále).
  • Čas jsou peníze a za zkrácení doby (nikoli množství práce) náleží dodavateli bonus dle dohody (v závislosti na tom, jaký podíl na zrychlení má kdo).
    Stanovení hodnoty času samostatně, je to extrémně důležitý princip, který většinou přezíravě ignorujeme.

Terminologie pro projekt & projektový záměr:

  • Výsledky... projevy provedených změn na provozním výkonu firmy nebo dílčích oblastí. Snadno měřitelné. Účel projektového záměru. Užitek.
  • Dopady... změny ve firmě a/nebo jejím okolí. Účinky provedených změn (použití výstupů). Těžko kvantiífikovatelné a měřitelné. Ale vyhodnotitelné.
  • Výstupy... co je vytvořeno projektem. Co bude použito pro dosažení žádoucích změn / dopadů a tím výsledků. 
  • Specifikace... přesná definice výstupů projektu.
  • Limity... omezení projektu ve spotřebě zdrojů, vycházející z ekonomiky záměru (tedy jeho předpokládaného užitku a pravděpodobnosti, viz ...).

Uvažujme následující varianty / míru ujasněnosti toho, co se bude dělat a co tím získáme.

Zadavatel má specifikaci a plán práce

  • Není to pravděpodobné, ale může se stát.
  • Hledá práci ve mzdě, umí si realizaci řídit sám.
  • Dodavatel/realizátor (pokud je to interní kapacita, měla by se chovat obdobně jako externí, samostatně) by si měl nastudovat zadání, identifikovat nejistoty a rizika a dle toho nabídnout cenu (je lhostejné, v jaké podobě - vždy bude muset fakturovat tolik, aby se mu to vyplatilo).
    • Když zadavatel trvá na hodinové sazbě, ale nemá přesné počty hodin (a přijatelná změnová & kompenzační pravidla), je dobré po smířlivém pokusu vysvětlit, že to tak nejde, co nejrychleji na tuto zakázku zapomenout.
    • Když jsou výstupy a/nebo plán prací nekorektní, je potřeba zkusit najít způsob, jak to upřesnit. Když to nejde, viz výše.
    • Plán prací musí integrovat do interního systému řízení kapacit a zajistit obousměrnou konsolidaci pro očekávané změny.

Prostě tento scénář je značně nepravděpodobný - pokud by skutečně existoval korektní plán práce, zjevně neplatí, že projekt realizuje primárně externí subjekt a celá spolupráce se točí kolem toho, jak lze domluvit způsob včasné rezervace externích kapacit (jelikož víme, že ve skutečnosti to bude jinak, než v plánu). Tady může inspirovat příběh o nátěrech z Kritického řetězu.

Zadavatel je schopen sjednat specifikaci

Aneb ví, co chce. Není potřeba se zabývat výsledky (užitkem získaným použitím výstupu projektu). Společně s dodavatelem, protože ten své doméně rozumí lépe, definuje závazné vlastnosti výstupu (produkt). Je mu jasný časový i nákladový limit. Jsou jasné akceptační testy. Není potřeba žádná jeho zásadní součinnost (když ano, viz dále).

Ideální stav. Podepíše se smlouva, dodavatel ve stanoveném termínu dodá požadované, všichni jsou šťastní jak blechy. Ale i v takovém případě je dobré, aby si zadavatel vyjednal přiměřený monitoring průběhu - aby se byl schopen připravit na případné selhání. Ve smlouvě musí být nastavena dost přísná pravidla a (likvidační) sankce při jejich nedodržování (pro obě strany).

Tohle by bylo pěkné a občas si myslíme, že to tak funguje. Dle zkušeností je to ještě méně pravděpodobné, než první scénář.

Zadavatel umí definovat, co potřebuje (výsledky/užitek)

Tady jsme blízko realitě (myšleno žádoucímu stavu - takto by to mohlo fungovat, bohužel je velmi obtížné - obvykle to vyžaduje kritickou analýzu současného stavu, rozbourání pár zkostnatělých "jistot" apod.) korektně formulovat, co přesně je potřeba, málokdo si dá tu práci.

  • Zadavatel přesně neví, co všechno se bude muset zajistit, aby potřebného užitku dosáhl, ale má jasno v tom, jaký užitek potřebuje.
  • Z logiky věci nebude žádoucí efekt (který potřebujeme pro stanovení nákladového limitu) jednoduše kvantifikovatelný. Ovšem úroveň plnění záměru (míru pokrytí potřeb) lze vyjádřit i jinak (konkrétní možnosti individuálně). Jde např.
    • Nový produkt.
    • Naimplementovaný nový IS.
    • Nová organizace obchodu.
  • Partneři by měli být schopni dohodnout se na relativním vyjádření - kolik zdrojů lze spotřebovat na jednotku získaného užitku. Odhad užitku průběžně zpřesňovat, tím korigovat nákladový i časový limit.

Zadavatel tuší, jaké má problémy

Jak je zřejmé, tohle ještě není hotové...