Download as pdf or txt
Download as pdf or txt
You are on page 1of 26

Subscribe to DeepL Pro to translate larger documents.

Visit www.DeepL.com/pro for more information.

rezervace pracovní doby zaměstnanců spolu s veškerými cestovními výdaji


zaměstnanců, které přímo nebo nepřímo souvisejí s rizikovou akcí
zaměstnavatele. V případě "neabsorbovaných" nákladů, které vznikají bez
ohledu na objem práce Zhotovitele, by měly uchovávané záznamy zahrnovat
náklady na nájemné, sazby, vytápění, osvětlení, platy ředitelů, mzdy
pomocného personálu, příspěvky do penzijního fondu a odměny auditorům.
1.28 Pokud se zhotovitel hodlá dovolávat použití vzorce pro posouzení ušlého zisku
a neabsorbovaných režijních nákladů sídla, bude muset nejprve předložit
důkaz, že kvůli prodlení objednatele nemohl provést jiné práce, které měl k
dispozici. Tyto záznamy mohou zahrnovat obchodní plány zhotovitele před
zpožděním zadavatele, historii zadávání veřejných zakázek zhotovitelem a
záznamy o přijetí nebo odmítnutí nabídek v závislosti na dostupnosti zdrojů.
Důležité budou také zápisy z případných schůzek za účelem přezkoumání
budoucích příležitostí k zadávání zakázek a dostupnosti personálu. Zhotovitel
bude muset rovněž předložit záznamy, které podporují vstupy do použitého
vzorce, zejména účetnictví společnosti zhotovitele za období bezprostředně
předcházející a následující po zpoždění zadavatele, jakož i za období, kdy
došlo ke zpoždění zadavatele.
1.29 Předtím, než si účastníci projektu vymění informace o svých nákladech a než
se strany pokusí dohodnout na důsledcích zpoždění nebo narušení nákladů, je
možné, že bude třeba vzít v úvahu právní předpisy o hospodářské soutěži a
obchodní tajemství. V některých případech (např. u nároku na ušlý zisk) musí
žalující strana akceptovat určitou ztrátu důvěrnosti jako nezbytnou podmínku
pro vznik svého nároku. Strany by proto mohly zvážit, zda se ve smlouvě
nedohodnou na příslušných sazbách, spíše než aby požadovaly prokázání
skutečných nákladů nebo ztrát pro určité eventuality (příkladem může být
dohoda o sazbách pro zaměstnance, které budou účtovány v případě zpoždění
dokončení ze strany zaměstnavatele). To bude pravděpodobně výhodné jak pro
stranu uplatňující nárok, tak pro stranu platící; strana uplatňující nárok nemusí
předkládat důkaz o skutečných nákladech nebo ztrátě a strana platící má
prospěch z předem dohodnuté sazby.
1.30 Záznamy o nákladech jsou nezbytné pro stanovení důsledků nákladů na
zpoždění nebo narušení.
Korespondence a administrativní záznamy
1.31 Tato kategorie zahrnuje veškerou písemnou komunikaci mezi zadavatelem,
zhotovitelem, CA a třetími stranami, která se týká postupu prací, včetně
jakéhokoli zpoždění nebo narušení. Patří sem e-maily, dopisy, oznámení,
pokyny, podání, žádosti o informace a odpovědi, zápisy z jednání a reklamace.
1.32 Písemná sdělení by měla být jednoznačně číslována, obsahovat popisný
předmět, být datována a zasílána na dohodnutý distribuční seznam. Veškerá
důležitá ústní sdělení by měla být potvrzena písemně.
1.33 Ke komunikaci mezi stranami se často používají e-maily. E-mail je zejména
vhodným způsobem přenosu informací v nativním formátu (zejména tabulek,
programů a výkresů). Správa e-mailů je náročná a strany by se jí měly zabývat
již od počátku prací. Měl by být vypracován a zaveden protokol pro používání
SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 16
elektronické pošty a jejího

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 17


archivace každého projektu. Archivovat by se měly i e-maily týkající se prací,
které jsou interní záležitostí strany.
1.34 Protokol uznává, že i při sebelepším systému správy a archivace e-mailů se
mohou některé e-maily ztratit a důležitost jiných může být přehlédnuta. Aby se
snížil nepříznivý vliv těchto problémů, protokol doporučuje, aby byla důležitá
sdělení (jakékoli povahy) připravena ve formě dopisu, jedinečně očíslována a
pečlivě uchovávána. Případně by měly být klíčové e-maily uchovávány v
centralizované složce a mělo by jim být přiděleno jedinečné číslo
korespondence.
1.35 Strany by si měly být vědomy všech smluvních procesních požadavků na
postup a rozhodování o nárocích z prodlení nebo narušení a měly by je
dodržovat, aby nedošlo k poškození. Týká se to načasování podání jakýchkoli
oznámení nebo údajů o nároku nebo stanovení nároku, formátu těchto
dokumentů a toho, komu mají být tyto dokumenty předány (viz základní
zásada 3 v části B).
Smlouva a zadávací dokumentace
1.36 Stavební smlouvy se obvykle skládají z mnoha dokumentů, a proto je důležité
zajistit, aby neexistovaly žádné nejasnosti ohledně toho, které dokumenty jsou
součástí smlouvy, a aby obě strany měly k dispozici jejich úplné kopie (včetně
případných změn).
1.37 Zadávací dokumentace zahrnuje veškerou korespondenci mezi stranami
týkající se jednání o zakázce. Patří sem také:
(a) ze strany zadavatele: nabídky všech uchazečů, hodnocení nabídek a
výpočty zadavatele týkající se případných sazeb smluvních pokut a
(b) na straně dodavatele: záznamy prokazující sestavení nabídkové ceny (a
případné změny ceny) a předpoklady, z nichž nabídková cena vychází.
1.38 Zadávací dokumentace může být relevantní pro prokázání přiměřenosti
nárokovaných nákladů v obdobích ovlivněných zpožděním nebo narušením
nebo pro vymahatelnost ustanovení o smluvních pokutách. Zadávací
dokumentace však není relevantní pro výklad smlouvy, pokud není začleněna
do smlouvy.
Program
1.39 Forma a software programu by měly být uvedeny v zadávací dokumentaci a ve
smlouvě. Měl by být specifikován komerčně dostupný software (spíše než
specializovaný interní software) a ve většině případů by měl být program
založen na metodě kritické cesty (nebo CPM).
1.40 Zhotovitel by měl co nejdříve v průběhu prací předložit a příslušný orgán by
měl přijmout program, který ukazuje, jakým způsobem a v jakém pořadí
plánuje zhotovitel práce provádět, a který se stane přijatým programem. Ten
by se měl zabývat klíčovými fázemi prací, zejména projektováním,

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 18


schválení, zadávání veřejných zakázek nebo výrobu,
instalace, výstavbu, uvedení do provozu a převzetí (podle
potřeby).
1.41 Většina standardních formulářů smlouvy obsahuje nedostatečné požadavky na
vytvoření přijatého programu a/nebo aktualizovaných programů. Protokol
doporučuje, aby strany dosáhly jasné a zdokumentované dohody o
požadavcích na program navržený zhotovitelem, aby mohl být akceptován
příslušným orgánem (a následně tvořit Akceptovaný program), a o způsobu,
jakým má být aktualizován (což jsou Aktualizované programy). Dohoda by
měla zahrnovat následující záležitosti a měla by být zdokumentována ve
smlouvě.
Forma programu navrhovaného zhotovitelem
1.42 Program navržený zhotovitelem by měl být obecně připraven jako síť
kritických cest pomocí komerčně dostupného programového softwaru CPM.
Složitost programu by měla být úměrná projektu. Zhotovitel i certifikační
orgán by měli mít k dispozici kopii programovacího softwaru.
1.43 Aby byl program navržený zhotovitelem vhodný k použití jako nástroj pro
sledování postupu prací a posuzování nároků na zpoždění a narušení, měl by
být řádně připraven tak, aby v případě, že dojde ke zpoždění nebo narušení,
mohl přesně předvídat jeho účinky. Navrhovaný program zhotovitele by měl
být příslušnému orgánu poskytnut v původní elektronické podobě (nikoli
pouze ve formátu PDF). Pomocí softwaru by měl zhotovitel na navrhovaném
programu identifikovat:
(a) kritické cesty;
(b) všechny příslušné činnosti a klíčová rozhraní a
(c) informace, které Zhotovitel od Zadavatele nebo CA oprávněně
požaduje, kdy jsou tyto informace požadovány, a všechny činnosti a
omezení Zadavatele nebo CA (např. schvalování/revize a služby nebo
materiály dodávané Zadavatelem). To by mělo být provedeno
logickým propojením s činnostmi Zhotovitele (a nikoli prostřednictvím
pevných dat).
1.44 Program předložený zhotovitelem při zajišťování zakázky by měl tvořit základ
navrhovaného programu zhotovitele. Podrobné návrhy, jak by měl být
navrhovaný program zhotovitele připraven, jsou uvedeny níže.
Podrobnosti v rámci navrhovaného programu
1.45 Navrhovaný program zhotovitele (a jeho případné revize) by měl být připraven
dostatečně podrobně s využitím logických vazeb (tj. každá činnost je
propojena s předchozí i následnou činností nebo milníkem), aby bylo možné
zajistit řádný výhled do budoucna a co nejpřesněji předvídat vliv zpoždění a
narušení.
1.46 V závislosti na složitosti prací může být vhodné stanovit ve smlouvě
maximální dobu trvání činnosti v programu navrženém zhotovitelem. Jako
vodítko lze uvést, že žádná činnost nebo prodleva (kromě souhrnné činnosti)
SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 19
by neměla přesáhnout 28 dní. Pokud je to možné, neměla by činnost zahrnovat
více než jedno řemeslo nebo operaci. Pokud se však jedná o "průběžnou vlnu

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 20


programování (tj. pokud jsou činnosti podrobně popsány pro následujících 6
až 18 měsíců projektu a zbývající činnosti jsou uvedeny na souhrnné úrovni),
není nutné omezení činností na 28 dní pro pozdější souhrnné činnosti. Místo
toho by se měl použít zdravý rozum a do programu začlenit přiměřené
souhrnné činnosti, které jsou pak podrobně popsány, jak se blíží doba jejich
provedení.
1.47 Činnosti by měly být propojeny vhodnými logickými vazbami, jako jsou
vazby od konce k začátku, od začátku k začátku a od konce k cíli. Tyto logické
vazby mohou demonstrovat:
(a) kritická cesta s omezením pořadí, která vychází z nezbytného pořadí
výstavby (např. střecha nemůže být postavena dříve, než jsou postaveny
základy a stěny); (b) kritická cesta s omezením zdrojů, která bere v úvahu
omezení zdrojů (např. v projektu potrubí, kde existuje mnoho pracovních
ploch, které by mohly postupovat souběžně); nebo (c) přednostní pořadí, kde
není ovlivněno žádné omezení. Lze zavést zpoždění pro nepracovní období
(např. vytvrzování betonu), ale lepší přehlednost a pochopení je zajištěno,
pokud jsou tyto záležitosti zobrazeny jako samostatné činnosti (definice
logických vazeb a zpoždění viz příloha A). Činnosti, které mají být prováděny
s využitím přesčasů a/nebo dalších směn, by měly být identifikovány a
vysvětleny v popisu programu. Měly by být vloženy všechny nezbytné logické
vazby. Je třeba se vyvarovat nadměrného počtu vedoucích a opožděných
činností. V případě použití by měl zhotovitel v popisu programu uvést
vysvětlení, proč byly použity určité náskoky a prodlevy. Je třeba se vyhnout
ručně aplikovaným omezením, jako jsou pevná data "musí začít" nebo "musí
skončit", "nulový pohyb" a další programovací techniky, které mohou mít za
následek, že program nebude moci dynamicky reagovat na změny (nebo,
pokud je to nevyhnutelné, by měly být řádně vysvětleny v popisu programu).
1.48 U hlavních činností by měly být uvedeny (nebo jinak vysvětleny v popisu
programu) klíčové zdroje, jako jsou pracovní síly, zaměstnanci (včetně těch,
které se týkají projektování, je-li to relevantní), řemeslníci, hlavní položky
zařízení, vyhrazené zdroje, hlavní materiály a pracovní sazby.
1.49 Pokud se práce řídí výrobou (výstupy), měly by být vytvořeny a využívány
doplňkové nástroje, jako jsou harmonogramy bilancí, diagramy časové polohy
a S-křivky, aby bylo možné pochopit pokrok činností uvedených v
aktualizovaných programech.
Interakce s výkazy metod
1.50 Aby byl plně pochopen, měl by být navrhovaný program zhotovitele čten ve
spojení s metodickými prohlášeními zhotovitele, která podrobně popisují, jak
zhotovitel hodlá práce provádět, klíčová rozhraní a zdroje, které hodlá použít
(což mohou být zdroje jeho subdodavatelů). Protokol doporučuje, aby smlouva
vyžadovala, aby zhotovitel takové metodické prohlášení předložil, a aby
navrhovaný program zhotovitele a metodické prohlášení byly plně propojeny.
1.51 Zhotovitel by měl rovněž vypracovat popis programu, který popíše, jak
navrhovaný program odráží metodické prohlášení.

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 21


Lhůta pro předložení návrhu programu k přijetí
1.52 Doporučuje se, aby si strany ve smlouvě sjednaly pevnou lhůtu pro předložení
navrhovaného programu zhotovitelem k přijetí. Mělo by se jednat o
přiměřenou dobu po zadání zakázky nebo po datu zahájení, podle toho, co
nastane dříve. U projektů s dlouhou dobou trvání a v závislosti na okolnostech
může být vhodné, aby zhotovitel krátce po zadání zakázky předložil počáteční
návrh programu, který podrobně zobrazuje pouze první tři měsíce prací, a
následně předložil návrh programu pro celé práce. Viz také odstavec 1.46 výše
týkající se průběžného programování.
1.53 Navrhovaný program by neměl zahrnovat žádné změny nebo zpoždění, k nimž
došlo od data zahájení zakázky. Jakékoli takové změny nebo zpoždění po
zahájení zakázky by měly být řešeny v souladu s postupem EOT v pokynech k
základní zásadě 5 v části B po přijetí navrhovaného programu.
Mechanismus pro získání souhlasu příslušného orgánu s navrhovaným programem
1.54 Zhotovitel (nikoli ÚOHS) kontroluje způsob a pořadí prací (a na této
schopnosti zakládá svou nabídkovou cenu). Pokud tedy zhotovitel dodrží
smlouvu a všechny platné právní předpisy, může práce provádět způsobem,
který považuje za vhodný. Ustanovení smlouvy o přijetí programu navrženého
zhotovitelem by měla tuto skutečnost odrážet s výhradou případných omezení
zadavatele uvedených ve smlouvě.
1.55 Aby se předešlo nejistotě, měla by smlouva obsahovat formulaci, že pokud CA
neodpoví zhotoviteli na navrhovaný program ve stanovené lhůtě, považuje se
tento program za přijatý a stává se "přijatým programem". Strany by měly na
začátku zvážit, zda do smlouvy zahrnout ustanovení, které bude zhotovitele
motivovat k předložení navrhovaného programu, který je v souladu se
smluvními požadavky (například zadržení části smluvní částky do doby
předložení vyhovujícího programu). V opačném případě, pokud zhotovitel
nesplní své smluvní povinnosti týkající se programu, může příslušný orgán
zvážit uplatnění ustanovení smlouvy o řešení obecných nedostatků ze strany
zhotovitele. V této situaci by měl příslušný orgán rovněž (v rámci možností)
udržovat a aktualizovat program se skutečným pokrokem na základě vlastních
poznatků.
1.56 Protokol považuje odsouhlasení přijatého programu za velmi důležité jak pro
řízení postupu prací, tak pro posouzení případných žádostí o povolení k
provozu. Neshody ohledně toho, co představuje přijatý program, by měly být
vyřešeny ihned a neměly by pokračovat v průběhu prací. Neakceptovaný
program navržený zhotovitelem nebo jeho aktualizace se může stát zdrojem
sporů. V souladu s tím by měl příslušný orgán upřesnit, jaké smluvní
požadavky nejsou splněny, než určí, že navržený program nebo aktualizace
jsou nedostatečné.
1.57 Akceptace ze strany CA představuje potvrzení, že akceptovaný program
představuje rozumné, realistické a dosažitelné znázornění pořadí a časového
harmonogramu provádění prací. Akceptace neznamená změnu

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 22


program navržený zhotovitelem do zadávací dokumentace, nebo nařídit, aby
práce byly provedeny přesně tak, jak je uvedeno v přijatém programu.
Neznamená to ani záruku CA vůči zhotoviteli nebo zadavateli, že
akceptovaného programu lze dosáhnout.
Požadavky na aktualizaci a uložení přijatého/aktualizovaného programu
1.58 Smlouva by měla vyžadovat, aby byl přijatý program aktualizován o skutečný
pokrok pomocí dohodnutého programového softwaru CPM v intervalech ne
delších než jeden měsíc (nebo v dohodnutých častějších intervalech u složitých
projektů). Zhotovitel by měl zadávat skutečný pokrok do Akceptovaného
programu tak, jak postupuje při provádění prací, a vytvářet tak Aktualizovaný
program, který je pak v dohodnutém intervalu aktualizován o další pokrok při
vytváření následujícího Aktualizovaného programu atd. Skutečný pokrok by
měl být zaznamenáván prostřednictvím skutečných dat zahájení a skutečných
dat ukončení činností spolu s procentem dokončení aktuálně nedokončených
činností a rozsahem zbývající doby trvání činností. Kromě toho by měl
zhotovitel do každého aktualizovaného programu zahrnout všechny nové nebo
upravené činnosti, logiku a posloupnosti. V aktualizovaných programech by
měla být uvedena veškerá období, kdy je činnost pozastavena. Strany by měly
na začátku projektu zvážit stanovení pravidel pro měření pokroku, aby byla
zajištěna jednotnost chápání.
1.59 Aktualizované programy by měly být archivovány jako samostatné
elektronické soubory a uložené verze by měly být elektronicky zkopírovány do
CA (opět v nativním formátu, nikoli ve formátu PDF) spolu se zprávou
popisující revize provedené v délce trvání činností nebo logice ve srovnání s
přijatým programem (nebo předchozím aktualizovaným programem) a důvody
revizí. Účelem ukládání Aktualizovaných programů je poskytnout současný
záznam o revizích zamýšlených pracovních postupů a činností zhotovitele.
Žádná verze žádného programu by neměla být přepisována - všechny verze je
třeba ukládat samostatně.
1.60 Aktualizované programy ukazují skutečný pokrok oproti plánovanému
pokroku a (jak je vysvětleno níže) slouží k určení případných nároků na EOT.
Pokud příslušný orgán nesouhlasí s pokrokem, kterého podle zhotovitele
dosáhl, měl by to oznámit zhotoviteli a příslušný orgán a zhotovitel by se měli
pokusit dosáhnout dohody. Pokud se nedohodnou, měl by mít názor
příslušného orgánu přednost (pokud a dokud nebude přezkoumán a nahrazen v
rámci postupů řešení sporů podle smlouvy) a názor příslušného orgánu na
pokrok by se měl odrazit v aktualizovaných programech. Stanovisko
zhotovitele k neshodným oblastem by mělo být zaznamenáno a předloženo
spolu s aktualizovanými programy.
1.61 Zhotovitel může čas od času změnit svůj plán provádění zbývajících prací.
Pokud je použito programování v klouzavé vlně, není následné upřesnění
pozdějších souhrnných činností revizí plánu zhotovitele.
1.62 Konkrétně by se měl zhotovitel pokusit přiměřeně revidovat svou plánovanou
logiku, posloupnost a dobu trvání činností pro zbývající část prací, kdykoli
dojde nebo může dojít ke zpoždění dokončení nebo k odchylkám zhotovitele,
aby bylo zajištěno dosažení smluvního termínu dokončení. Smlouva by měla
obsahovat
SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 23
ustanovení umožňující příslušnému orgánu požadovat, aby zhotovitel za těchto
okolností předložil návrh revidovaného programu. Tyto revize by měly být
provedeny v posledním aktualizovaném programu (nebo v přijatém programu,
pokud aktualizovaný program dosud nebyl vypracován).
1.63 Zhotovitel by měl oznámit CA veškeré navrhované revize a poskytnout
elektronickou kopii navrhovaného revidovaného programu spolu s jakoukoli
následnou revizí prohlášení o metodách zhotovitele a popisem programu, který
odráží navrhovaný revidovaný program. Příslušný orgán by měl navrhovaný
revidovaný program přezkoumat a případně přijmout. Jakmile je revidovaný
program přijat příslušným orgánem, nahrazuje předchozí přijatý program jako
nástroj pro sledování skutečného pokroku.
1.64 Přijetí takového návrhu revidovaného programu ze strany CA neznamená
přijetí nebo prominutí zpoždění Zhotovitele a požadavek, aby Zhotovitel
navrhl opatření k odstranění zpoždění, není pokynem nebo domnělým
pokynem k urychlení prací na náklady Objednatele. Akceptací se pouze
potvrzuje, že revidovaný program přiměřeně odráží současnou situaci a
současný záměr Zhotovitele provést zbývající část prací.

2. Účel EOT
Výhodou EOT pro zhotovitele je zbavení zhotovitele odpovědnosti za škody
způsobené zpožděním (obvykle LD) za jakékoli období před prodlouženým
termínem dokončení zakázky a umožnění přeprogramování prací na dokončení.
Výhodou EOT pro zadavatele je, že stanoví nový termín dokončení zakázky,
zabrání tomu, aby se doba pro dokončení prací stala "volnou", a umožní
koordinaci / plánování vlastních činností.
2.1 Často se mylně soudí, že nárok na prodloužení doby trvání pracovního poměru
s sebou automaticky nese nárok na náhradu nákladů na prodloužení doby
trvání pracovního poměru. Hlavním důsledkem prodloužení platnosti smlouvy
o dílo je, že zhotovitel je zbaven odpovědnosti za smluvní pokuty po dobu
prodloužení a může své práce přeprogramovat až do dokončení. Jeho nárok na
náhradu škody je obvykle třeba hledat v jiných ustanoveních smlouvy nebo v
zákoně. Výhodou prodloužení smlouvy o dílo pro zadavatele je, že stanoví
nový termín dokončení zakázky, zabrání tomu, aby se doba pro dokončení
prací stala "volnou", a umožní mu koordinovat/plánovat vlastní činnosti, např.
školení provozních zaměstnanců.
2.2 Pokud budou dodržovány osvědčené postupy, které jsou propagovány v
pokynech k základní zásadě 1, pokud jde o vedení záznamů a přípravu,
přijímání a aktualizaci programů, pak se sníží prostor pro věcné neshody
ohledně nároku na EOT.

3. Smluvní procesní požadavky


Strany a certifikační orgán by měly dodržovat smluvní procesní požadavky
týkající se oznámení, údajů, odůvodnění a posouzení v souvislosti s událostmi
zpoždění.

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 24


3.1 Většina standardních smluvních formulářů, ne-li všechny, obsahuje povinnost
zhotovitele oznámit příslušnému orgánu, jakmile nastane riziková událost
zaměstnavatele, která podle zhotovitele opravňuje k EOT. Některé vyžadují
oznámení o výskytu rizikové události zadavatele bez ohledu na to, zda může
ovlivnit termín dokončení zakázky (tj. druhá z těchto událostí se v protokolu
označuje jako zpoždění dokončení ze strany zadavatele), a některé vyžadují
oznámení všech událostí, které nepříznivě ovlivňují postup prací bez ohledu na
odpovědnost nebo důsledky. V některých standardních formulářích jsou tato
oznámení vyjádřena jako odkládací podmínky (tj. předběžné podmínky)
vzniku nároku.
3.2 Zhotovitel by měl dodržovat smluvní procesní požadavky týkající se
oznámení, údajů a odůvodnění v souvislosti s případy prodlení. Bez ohledu na
to, co je uvedeno ve smlouvě, by však měl zhotovitel co nejdříve oznámit ÚO
všechny případy zpoždění zadavatele. Příslušný orgán by měl rovněž co
nejdříve informovat zhotovitele o všech zpožděních zadavatele, o kterých ví.
3.3 To umožňuje účastníkům projektu zvážit vhodná opatření ke zmírnění dopadu
zpoždění.

4. Nečekejte, až se projeví dopady zpoždění (současná analýza).


Strany by se měly v co největší míře snažit vypořádat s časovým dopadem
rizikových událostí zaměstnavatele v průběhu prací (jak z hlediska EOT, tak z
hlediska kompenzace). Žádosti o EOT by měly být podávány a vyřizovány co
nejblíže časovému okamžiku vzniku události zpoždění, která je důvodem žádosti.
Nedoporučuje se používat při posuzování EOT přístup "počkej a uvidíš". Pokud
zhotovitel splnil své smluvní povinnosti týkající se událostí zpoždění a žádostí o
EOT, neměl by být zhotovitel poškozen v případném sporu se zadavatelem v
důsledku toho, že CA neposoudil žádosti o EOT. Příslušný orgán by měl nárok
na EOT posoudit v přiměřené lhůtě po předložení žádosti o EOT zhotovitelem.
Zhotovitel bude mít potenciálně nárok na EOT pouze u těch událostí nebo příčin
zpoždění, u nichž Zadavatel převzal riziko a odpovědnost (v Protokolu nazvané
rizikové události Zadavatele), které mají dopad na kritickou cestu.
4.1 Každá žádost o EOT by měla být posouzena co nejdříve, v každém případě
však nejpozději do jednoho měsíce od obdržení žádosti příslušným orgánem.
Nedoporučuje se při posuzování EOT vyčkávat a čekat. To umožňuje, aby
účastníci projektu zvážili vhodná zmírňující opatření a omezili tak dopad
zpoždění. Zadavateli a zhotoviteli to také poskytuje jasnou představu o datu
dokončení zakázky, aby mohli pochopit svá rizika a povinnosti a jednat
odpovídajícím způsobem.
Současná analýza zpoždění
4.2 Tento oddíl stanoví doporučený postup, který je třeba dodržovat, aby bylo
možné v průběhu projektu účinně a přesně vyřizovat žádosti o EOT.
Předpokládá, že smluvní strany dodržují doporučené osvědčené postupy
týkající se programů a záznamů uvedené v pokynech.

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 25


k základní zásadě 1 v části B. Není záměrem, aby tyto pokyny byly začleněny
do smlouvy.
4.3 Zhotovitel by měl zpravidla předložit dílčí síť (někdy nazývanou "fragment"),
která ukazuje skutečný nebo předpokládaný vliv rizikové události zadavatele a
její vazbu na aktualizovaný program. Tato dílčí síť se vloží do toho
Aktualizovaného programu, který Zhotovitel předložil co nejblíže k datu
vzniku Rizikové události Zadavatele. Další pokyny k podobě dílčí sítě jsou
uvedeny v odstavci 4.10 níže. Měly by k ní být rovněž přiloženy takové
dokumenty a záznamy, které jsou nezbytné k prokázání principiálního nároku
na EOT. Pouhé konstatování, že došlo k rizikovým událostem zaměstnavatele,
a uplatnění nároku na celé zpoždění zjevné v době událostí není řádným
prokázáním nároku.
4.4 Předtím, než učiní cokoli dalšího, by měl příslušný orgán posoudit, zda je
reklamovaná událost nebo příčina zpoždění skutečně událostí, za kterou
zaměstnavatel převzal riziko a odpovědnost (tj. zda se jedná o rizikovou
událost zaměstnavatele). Zhotovitel bude mít potenciálně nárok na EOT pouze
u těch událostí nebo příčin, které jsou ve smlouvě uvedeny jako časové riziko
Zadavatele a které mají dopad na kritickou cestu. Tyto události se v různých
standardních formách smlouvy liší a při jejich čtení je třeba postupovat
opatrně. Pokud příslušný orgán dojde k závěru, že událost nebo příčina
zpoždění není rizikovou událostí zadavatele, měl by to oznámit zhotoviteli.
Aniž je tím dotčeno, může se příslušný orgán vyjádřit k dalším aspektům
podání zhotovitele. Při udělení nebo zamítnutí EOT by měl příslušný orgán
poskytnout dostatek informací, aby zhotovitel mohl pochopit důvody
rozhodnutí příslušného orgánu.
4.5 Pokud není předložena žádost, která by byla v souladu s tímto oddílem, měl by
příslušný orgán (pokud smlouva nestanoví jinak) sám určit případný EOT na
základě informací, které má k dispozici. Vzhledem k tomu, že je obtížné, ne-li
nemožné, vzít EOT zpět, jakmile byl jednou udělen, lze důvodně očekávat, že
v případě, kdy ÚO není předložena informace, na jejímž základě by mohl
rozhodnout, ÚO udělí pouze minimální EOT, které lze v daném okamžiku
odůvodnit.
4.6 Pokud zhotovitel s rozhodnutím příslušného orgánu nesouhlasí, měl by o tom
neprodleně informovat příslušný orgán. Neshody v záležitostech EOT by
neměly být ponechány k řešení na konci projektu. Pokud nelze rychle
dosáhnout dohody, měla by kterákoli ze stran podniknout kroky k tomu, aby
byl spor nebo rozdíl vyřešen v souladu s ustanoveními o řešení sporů ve
smlouvě.
4.7 Protokol doporučuje, aby nejnovější aktualizovaný program (nebo, pokud
žádný neexistuje, přijatý program) byl hlavním nástrojem, kterým se příslušný
orgán řídí při posuzování žádosti o povolení EOT. EOT by měl být udělen v
rozsahu, v jakém se předpokládá, že riziková událost zadavatele zabrání
dokončení prací do tehdy platného termínu dokončení zakázky.
4.8 Orientační výši EOT získáte pomocí Aktualizovaného programu. Je třeba
provést následující kroky:
(a) program by měl být plně aktualizován (pokud jde o pokrok a dopad
SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 26
všech zpoždění, ke kterým došlo do tohoto d a t a , ať už se jedná o
zpoždění, která se vyskytla v průběhu programu).

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 27


Zpoždění Zadavatele nebo Zhotovitele) do okamžiku bezprostředně před
vznikem Rizikové události Zadavatele;
(b) Program by pak měl být upraven tak, aby odrážel přiměřené, realistické
a dosažitelné plány Zhotovitele na odstranění všech vzniklých
zpoždění, včetně jakýchkoli změn v logice Aktualizovaného programu
navržených za tímto účelem (s výhradou přezkumu a přijetí CA, jak je
stanoveno v odstavci 1.63 Části B);
(c) dílčí síť, která představuje rizikovou událost zaměstnavatele, by pak
měla být zanesena do programu; a
(d) je třeba vzít na vědomí dopad na termíny dokončení zakázky.
4.9 Před stanovením vlivu rizikové události zadavatele na aktualizovaný program
by měla být jakákoli zjevně nepřiměřená nebo nerealistická logika, omezení
nebo doba trvání opravena dohodou, v opačném případě by měl mít přednost
názor CA, pokud a dokud nebude zvrácen podle ustanovení o řešení sporů ve
smlouvě.
4.10 Výše uvedenou dílčí síť by měl zhotovitel připravit stejným způsobem a za
použití stejného softwaru jako přijatý program. Měla by zahrnovat činnosti a
doby trvání vyplývající z rizikové události Zadavatele. Například dílčí síť pro
změnu by měla obsahovat pokyn k této změně, činnosti potřebné k provedení
této změny a její vazbu na činnosti v Aktualizovaném programu. V případě
porušení smlouvy by dílčí síť představovala důsledky tohoto porušení.
Zhotovitel by měl dílčí síť předložit příslušnému orgánu k odsouhlasení.
Příslušný orgán by měl dílčí síť posoudit a v případě souhlasu by měla být
dílčí síť vložena do aktualizovaného programu zhotovitele. Jakýkoli nesouhlas
s dílčí sítí by měl být vyřešen rychle a (stejně jako všechny otázky týkající se
zpoždění) by neměl být ponechán až na dobu po dokončení.
4.11 Posouzení dopadu zpoždění (ať už zpoždění zhotovitele nebo zadavatele) by
mělo být na úrovni odpovídající úrovni podrobnosti obsažené v
aktualizovaném programu a mělo by zohledňovat rozsah a složitost
analyzovaných prací a zpoždění.
4.12 Metodika popsaná v této části je známá jako "analýza časového dopadu".
Tato metodika vyžaduje logicky provázaný výchozí program (což by obvykle
byl přijatý program), aktualizované programy (což by obvykle byly
aktualizované programy) nebo informace o pokroku, s nimiž se aktualizuje
výchozí program, a výběr událostí zpoždění, které se mají modelovat. Pokud
se strany neřídily pokyny k hlavní zásadě 1 v části B, takže neexistuje žádný
Akceptovaný program a/nebo Aktualizované programy, povede to
pravděpodobně k většímu počtu sporů týkajících se současného posuzování
žádostí o EOT.
4.13 Jak je uvedeno v pokynech k základní zásadě 10 v části B, pokud se rizikové
události zadavatele a rizikové události zhotovitele vyskytují postupně, ale mají
souběžné účinky, měla by analýza zpoždění určit, zda dochází k souběžnému
zpoždění, a pokud ano, zda je za období tohoto souběhu splatný EOT. V této
situaci

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 28


jakékoli zpoždění Zhotovitele by nemělo snížit částku EOT, která Zhotoviteli
náleží v důsledku zpoždění Zadavatele. Analýzy by měly být prováděny pro
každou událost zvlášť a striktně v pořadí, v jakém vznikly.
4.14 Ačkoli by aktualizovaný program měl být hlavním nástrojem, kterým se
příslušný orgán řídí při určování EOT, měl by být použit ve spojení se
současnými důkazy, aby bylo zajištěno, že výsledný EOT je přiměřený a
odpovídá skutkovým okolnostem. Bude také nutné, aby strany při tomto
procesu použily zdravý rozum a zkušenosti, aby bylo zajištěno, že budou
zohledněny všechny relevantní faktory a že budou řádně zvládnuty případné
anomální výsledky, které vyplynou z analýzy zpoždění. Nad těmito úvahami
musí být jakýkoli výsledný EOT v souladu se smluvními požadavky týkajícími
se nároku.
4.15 Pokud zhotovitel splnil své smluvní povinnosti týkající se událostí zpoždění a
žádostí o EOT, neměl by být poškozen v případném sporu se zadavatelem v
důsledku toho, že CA neposoudil žádosti o EOT v přiměřené lhůtě po jejich
podání.

5. Postup pro udělení EOT


V souladu s požadavky smlouvy by měl být EOT udělen v rozsahu, v jakém lze
důvodně předpokládat, že riziková událost zadavatele zabrání dokončení prací v
tehdy platném smluvním termínu. Obecně se jedná o případy, kdy riziková
událost zadavatele ovlivňuje kritickou cestu prací, a tím prodlužuje termín
dokončení zakázky. Toto posouzení by mělo být založeno na odpovídající analýze
zpoždění, jejíž závěry musí být z hlediska zdravého rozumu správné. Cílem
postupu EOT je zjištění příslušného smluvního nároku na EOT; analýza by
neměla vycházet z úvahy, zda zhotovitel potřebuje EOT, aby nebyl odpovědný za
smluvní pokuty.
5.1 Pokud ÚO neurčí nárok na EOT vyplývající z rizikové události zadavatele v
době, kdy je EOT skutečně splatný, hrozí nebezpečí, že mechanismus EOT
selže a zhotovitel bude povinen dokončit práce pouze v přiměřené lhůtě s
ohledem na práva a povinnosti stran vyplývající ze smlouvy (s nejistotou,
která z toho vyplývá). Z tohoto důvodu by měly smlouvy o dílo obsahovat
ustanovení, která by opravňovala příslušný orgán z vlastního podnětu stanovit
EOT, a to i v případě, že zhotovitel o něj nepožádal nebo požádal s
nedostatečnými informacemi.
5.2 Správně vypracovaná doložka o prodloužení platnosti smlouvy bude
obsahovat obecnou formulaci, která umožní prodloužení platnosti smlouvy v
souvislosti s preventivním jednáním (nebo opomenutím) nebo porušením
smlouvy ze strany zadavatele. Taková formulace je nutná, protože anglické
soudy rozhodly, že formulace jako "jakékoliv jiné zvláštní okolnosti" se
nevztahuje na porušení ze strany Zadavatele. Taková doložka EOT by měla
rovněž vysvětlovat důsledky nedodržení jakýchkoli procesních požadavků ze
strany Zhotovitele při žádosti o EOT.
5.3 Obecně platí, že EOT by měl být udělen v rozsahu, v jakém se předpokládá, že
riziková událost zadavatele znemožní dokončení prací do doby, kdy bude v
daném okamžiku platit

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 29


datum dokončení smlouvy. Tento proces vyžaduje zvážení, zda riziková
událost zadavatele ovlivňuje kritickou cestu, a tím prodlužuje termín
dokončení zakázky (viz pokyny k základní zásadě 8 v části B).

6. Vliv zpoždění
Pro udělení EOT není nutné, aby riziková událost zadavatele již začala
ovlivňovat postup zhotovitele při provádění prací nebo aby účinky rizikové
události zadavatele již skončily.
6.1 Jak je vysvětleno v pokynech k základní zásadě 4 v části B, nedoporučuje se
praxe některých certifikačních orgánů, které před vyřízením žádosti
zhotovitele o EOT vyčkávají, jaký plný dopad bude mít riziková událost
zadavatele na práce. Pokud má Zhotovitel nárok na EOT, měl by jej obdržet a
CA by neměl čekat na to, zda Zhotovitel EOT skutečně potřebuje, aby nebyl
odpovědný za smluvní pokuty.

7. Postupná revize EOT


Pokud nelze v době počátečního posouzení příslušným orgánem s jistotou
předvídat plný účinek rizikové události zaměstnavatele, měl by příslušný orgán
udělit EOT pro tehdy předvídatelný účinek. Příslušný orgán by měl EOT
posuzovat v intervalech podle toho, jak se vyvíjí skutečný dopad rizikové události
zadavatele, a v případě potřeby EOT zvýšit (nikoli však snížit, pokud to výslovně
neumožňují smluvní podmínky).
7.1 Příslušné orgány by měly mít na paměti, že je přípustné řešit EOT postupně.
Doporučený postup protokolu pro posuzování EOT v průběhu projektu je
uveden v pokynech k hlavní zásadě 4 v části B.
7.2 Příslušný orgán by však neměl používat postupný přístup, aby "vyčkával" na
výsledek rizikové události zaměstnavatele, protože by to bylo v rozporu se
základní zásadou 4. Příslušný orgán by měl spíše udělit EOT pro tehdy
předvídatelný účinek rizikové události zaměstnavatele. To pak zhotoviteli
umožní přeprogramovat práce až do jejich dokončení.

8. Float ve vztahu k času


Hodnoty "floatu" v programu ukazují relativní kritičnost činností a obecně platí,
že pokud je "float" vyčerpán, ovlivní to datum dokončení. Pokud není ve
smlouvě výslovně stanoveno jinak, měl by být v případě, že v době rizikové
události zadavatele zbývá v programu celkový "float", EOT udělen pouze v
rozsahu, v jakém se předpokládá, že zpoždění zadavatele sníží celkový "float" na
kritické cestě ovlivněné zpožděním zadavatele do dokončení pod nulu (tj. pokud
se předpokládá, že zpoždění zadavatele prodlouží kritickou cestu do dokončení).
8.1 Float je doba, o kterou lze činnost nebo skupinu činností časově posunout, aniž
by došlo ke zpoždění dokončení. Činnosti s nejmenším pohybem jsou obecně
považovány za činnosti na kritické cestě prací. Příloha A vysvětluje různé typy
floatu. Dotyčné datum může být úsekovým datem dokončení, celkovým datem
dokončení prací nebo průběžným milníkem.

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 30


"Vlastnictví" plováku vyvolává zvláštní spory ve sporech o nárok na EOT.
Zhotovitel může tvrdit, že je "vlastníkem" plovoucí části, protože si při
plánování způsobu provedení prací ponechal dodatečnou nebo plovoucí část,
aby si zajistil určitou flexibilitu pro případ, že nebude schopen provést práce
tak rychle, jak plánoval. Pokud tedy dojde k jakémukoli zpoždění postupu
zhotovitele, za které zhotovitel není odpovědný, může tvrdit, že má nárok na
EOT, i když zpoždění postupu nebude mít za následek nedodržení termínu
dokončení zakázky, ale pouze narušení jeho plovoucího času. Na druhé straně
může zadavatel obvykle tvrdit, že zhotovitel nemá nárok na EOT, pokud
zpoždění postupu prací nebude mít za následek nedodržení termínu dokončení
zakázky. Takže (Zadavatel může říci), že projekt je vlastníkem floatu.
8.2 Strany by měly zajistit, aby tato otázka byla řešena v jejich smlouvách. Výraz
"float" se ve standardních smluvních podmínkách objevuje zřídka, pokud
vůbec. Pokud je znění ustanovení o EOT ve smlouvě takové, že EOT má být
poskytnuto pouze v případě, že zpoždění zadavatele zpozdí dokončení po
termínu dokončení zakázky, pak je pravděpodobným důsledkem tohoto znění,
že před vznikem nároku na EOT musí být vyčerpána celková rezerva. Pokud
je ustanovení o EOT formulováno tak, že EOT je splatné vždy, když zpoždění
zadavatele způsobí, že plánovaný termín dokončení zhotovitele je pozdější,
než by byl, kdyby k tomuto zpoždění nedošlo, pak v případě zpoždění
zadavatele nebude pravděpodobně k dispozici celková rezerva ve prospěch
zadavatele. Některé smluvní podmínky neuvádějí, zda zpoždění Zadavatele
musí ovlivnit datum dokončení zakázky nebo pouze plánované datum
dokončení Zhotovitele před splatností EOT.
8.3 Je důležité, aby si strany při uzavírání smlouvy uvědomily praktické dopady
výše popsaných permutací. U smluv, kde zpoždění zadavatele musí ovlivnit
termín dokončení zakázky, pokud dojde ke zpoždění zadavatele jako prvnímu
a vyčerpá celou celkovou rezervu, může se zhotovitel ocitnout v prodlení a
platit smluvní pokuty v důsledku následného zpoždění zhotovitele, které by
nebylo kritické, kdyby nedošlo ke zpoždění zadavatele jako prvnímu. U smluv,
kde zpoždění Zadavatele musí ovlivnit pouze plánované datum dokončení
Zhotovitele, má Zhotovitel potenciální nárok na EOT pokaždé, když Zadavatel
nebo CA zpozdí některou ze svých činností, bez ohledu na jejich kritičnost pro
dodržení data dokončení zakázky. V rámci typu smlouvy, která mlčí nebo je
nejednoznačná, pokud jde o float, existuje nejistota a je pravděpodobné, že
budou následovat spory.
8.4 Mnoho smluvních podmínek obsahuje ustanovení, které umožňuje konečný
přezkum jakéhokoli uděleného nebo neuděleného EOT a odráží to, co je
vnímáno jako spravedlivé nebo přiměřené. Spoléhání se na to, co CA vnímá
jako spravedlivé nebo přiměřené, však není vždy dobrým receptem na jistotu.
Pokud jsou EOT udělovány zpětně, je možné samostatně přezkoumat dopad
různých typů zpoždění a rozhodnout o nároku na EOT, opět na základě
spravedlnosti nebo přiměřenosti. Velmi důležitou zásadou tohoto protokolu
však je, že žádosti o EOT by měly být podávány a vyřizovány co nejblíže
časové události zpoždění, která je vyvolala, a nedoporučuje se přístup "počkej
a uvidíš" (viz pokyny k základní zásadě 4 v části B).

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 31


8.5 Základní zásada č. 8 (a 9) stanoví postoj protokolu k "floatu" v případech, kdy
strany ve smlouvě jasně nestanovily, jakým způsobem by měl být "float"
řešen. To je v souladu se současným soudním názorem, podle něhož musí být
zpoždění zaměstnavatele kritické (pro dodržení termínu dokončení zakázky),
aby vznikla povinnost zaplatit EOT. To má za následek, že float není časem k
výlučnému použití nebo ve prospěch zadavatele nebo zhotovitele (pokud
neexistuje výslovné ustanovení ve smlouvě).
8.6 Z tohoto přístupu vyplývá, že zhotovitel nemá nárok na EOT jen proto, že
riziková událost objednatele brání zhotoviteli dokončit práce dříve, než je
datum dokončení podle smlouvy, nebo proto, že zpoždění objednatele v
postupu prací zbavuje zhotovitele práva na určitou činnost (pokud to není
výslovně stanoveno ve smlouvě).
8.7 Pokud chce zhotovitel zohlednit možnost zpoždění zhotovitele (někdy
označované jako "časová rezerva na riziko"), měl by do doby trvání činností
ve svém programu zahrnout takovou dodatečnou dobu, která je podle
zhotovitele nezbytná k zohlednění rizika takového zpoždění těchto činností.
Případně může tyto příplatky označit jako samostatné činnosti v programu
nazvané "Nepředvídané události pro ...". [např. zemní práce]". Obojí je zcela
přijatelná a obezřetná plánovací praxe.
8.8 Pokud programovací software využívá kalendáře s více pracovními dny, je
třeba se při určování kritické cesty spoléhat na plovoucí hodnoty a kombinovat
je s dalšími opatřeními.

9. Identifikace plováku
Identifikace povodní je značně usnadněna tam, kde existuje řádně připravený a
pravidelně aktualizovaný program, tzv. přijaté/aktualizované programy.
9.1 Doporučení pro přípravu přijatých/aktualizovaných programů jsou uvedena
jako součást pokynů k hlavní zásadě 1 v části B.

10. Souběžné zpoždění - vliv na nárok na EOT


Skutečné souběžné zpoždění je výskyt dvou nebo více událostí zpoždění současně,
z nichž jedna je rizikovou událostí zadavatele a druhá rizikovou událostí
zhotovitele a jejichž účinky se projeví ve stejnou dobu. Aby se jednalo o souběžné
zpoždění, musí být každá z rizikových událostí zadavatele a zhotovitele
skutečnou příčinou zpoždění dokončení (tj. obě zpoždění musí ovlivnit kritickou
cestu). Pokud dojde ke zpoždění dokončení zhotovitele nebo má tento zpoždění
vliv současně se zpožděním dokončení zadavatele, nemělo by souběžné zpoždění
zhotovitele snižovat případné splatné EOT.
10.1 Souběžné prodlení je spornou otázkou, a to jednak proto, že existují rozdílné
názory na správný přístup k řešení souběžného prodlení při analýze nároku na
EOT, jednak proto, že existují rozdíly ohledně samotného významu
souběžného prodlení.
10.2 Protokol proto poskytuje vodítko, aby bylo možné rozpoznat a dohodnutým
způsobem vyřešit otázky souběhu jako součást celkového zpoždění.

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 32


analýzu. Tyto pokyny jsou kompromisem, který zohledňuje různé konkurenční
argumenty, ale představuje to, co protokol považuje za nejvhodnější řešení.
Význam souběžného zpoždění
10.3 Skutečné souběžné zpoždění je výskyt dvou nebo více událostí zpoždění
současně, z nichž jedna je rizikovou událostí zadavatele a druhá rizikovou
událostí zhotovitele a jejichž účinky se projeví ve stejnou dobu. Skutečné
souběžné zpoždění se vyskytuje zřídka. Momentem, kdy může nastat, je datum
zahájení prací (například když Zadavatel neumožní přístup na staveniště, ale
Zhotovitel nemá mobilizované zdroje k provádění jakýchkoli prací), ale může
nastat kdykoli.
10.4 Naproti tomu častější použití termínu "souběžné zpoždění" se týká situace, kdy
dvě nebo více zpoždění vzniknou v různých časech, ale jejich účinky se
projeví ve stejnou dobu.
10.5 V obou případech se souběžné zpoždění nestává problémem, pokud každá z
rizikových událostí zadavatele a zhotovitele nevede nebo nepovede ke
zpoždění dokončení. Aby tedy mohlo dojít k souběžnému zpoždění, musí být
každá z Rizikových událostí zadavatele a Rizikových událostí zhotovitele
skutečnou příčinou zpoždění dokončení (nikoli pouze vedlejší příčinou
zpoždění dokončení).
10.6 Tato otázka má praktické i právní důsledky. Z praktického hlediska je analýza
účinků událostí zpoždění jednodušší, pokud se zohlední pouze ty události,
které povedou ke zpoždění dokončení (namísto zohlednění všech událostí v
programu), takže udělení EOT se řídí výsledkem analýzy kritické cesty.
Protokol doporučuje tento přístup v průběhu projektu, aby bylo možné včas
požádat o EOT a posoudit jej.
10.7 Z právního hlediska existují dva protichůdné názory na to, zda je zpoždění
zadavatele skutečnou příčinou zpoždění dokončení, pokud k němu dojde po
začátku zpoždění zhotovitele, ale pokračuje souběžně se zpožděním
zhotovitele. To lze ilustrovat následujícím příkladem: Riziková událost
zhotovitele bude mít za následek pětitýdenní Zpoždění zhotovitele do
dokončení, čímž se termín dokončení zakázky posune z 21. ledna na 25. února.
Nezávisle na tom a o několik týdnů později je jménem zadavatele zadána
změna, která by při neexistenci předchozího zpoždění zhotovitele měla za
následek zpoždění zadavatele do dokončení od 1. února do 14. února.
10.8 Podle jednoho názoru jsou obě události účinnými příčinami zpoždění
dokončení pro dvoutýdenní období od 1. do 14. února, protože každá z nich by
způsobila zpoždění dokončení, pokud by neexistovala druhá (přičemž
následné zpoždění od 15. února do 25. února bylo způsobeno pouze rizikovou
událostí zhotovitele). Tento názor může být podpořen staršími případy
anglického odvolacího soudu (nepochybně předcházejícími analýze kritické
cesty), které stanoví, že pokud je nedokončení prací částečně způsobeno
zaviněním zadavatele i zhotovitele, smluvní pokuta se neplatí. V situaci, jako
je příklad popsaný v odstavci 10.7 výše, lze argumentovat tím, že jak

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 33


Riziková událost zadavatele a Riziková událost zhotovitele jsou částečně
příčinou zpoždění dokončení.
10.9 Na druhou stranu zpoždění objednatele nebude mít za následek pozdější
dokončení prací, než by tomu bylo v opačném případě, protože práce se již
měly opozdit o delší dobu z důvodu zpoždění zhotovitele s dokončením.
Jedinou účinnou příčinou zpoždění dokončení je tedy riziková událost
zhotovitele. Toto je konzistentní postoj, který byl zaujat v nedávných
rozhodnutích anglických soudů nižšího stupně.
10.10 Protokol doporučuje druhý z těchto dvou názorů, tj. že pokud se posuzuje
žádost o EOT týkající se situace uvedené v odstavci 10.7 výše, měla by být
riziková událost zadavatele považována za událost, která nezpůsobuje
zpoždění dokončení (a proto nedochází k souběhu). Souběžné zpoždění vzniká
pouze v případě, kdy je prokázáno, že riziková událost zadavatele způsobila
Zpoždění dokončení nebo, jinými slovy, způsobila kritické zpoždění (tj. je na
nejdelší cestě) k dokončení. Protokol upozorňuje, že toto doporučení by
muselo být znovu zváženo, pokud by odvolací soud zaujal k této otázce jiný
přístup.
10.11 Při zvažování, zda existuje souběžné zpoždění, protokol doporučuje k analýze
zpoždění přistupovat podle zdravého rozumu. Protokol zejména uznává, že
analýza zpoždění je zřídka přesná na den (nebo dokonce na několik dní).
Použití zdravého rozumu vyžaduje, aby se při vyvozování závěru o souběhu
zohlednila míra nepřesnosti.
Řešení souběžného zpoždění
10.12 Pokud bylo zjištěno souběžné zpoždění, měl by mít zhotovitel nárok na EOT
za zpoždění objednatele s dokončením, které se řeší v souladu se základní
zásadou 5. Zpoždění Zhotovitele by nemělo snížit částku EOT, která
Zhotoviteli náleží v důsledku zpoždění Zadavatele.
10.13 Zadavatel by si měl být vědom toho, že pokud zadá pokyn k provedení změny
po datu dokončení zakázky, kdy nedokončení do data dokončení zakázky bylo
způsobeno prodlením zhotovitele, může zadavatel ztratit nárok na smluvní
pokutu, pokud zhotovitel následně urychlí vymáhání prodlení zhotovitele s
dokončením na vlastní náklady, což vede k tomu, že se změna (riziková
událost zadavatele) stane skutečnou příčinou prodlení s dokončením.
10.14 Zpoždění Objednatele s dokončením nezbavuje Zhotovitele odpovědnosti za
všechna jeho prodlení předtím, než k tomuto zpoždění Objednatele s
dokončením došlo. Dopad zpoždění zadavatele by měl být posouzen podle
popisu v základní zásadě č. 5 a případné zjištěné dlužné EOT by měly být
jednoduše přičteny k datu dokončení zakázky.
10.15 Přístup protokolu k řešení souběžného zpoždění má za cíl poskytnout
smluvním stranám jasnost a jistotu ohledně nároku na EOT.
10.16 Postoj protokolu k souběžnému prodlení je ovlivněn "zásadou prevence"
anglického práva, podle níž zadavatel nemůže využít nesplnění podmínky
(např. dokončení prací k určitému datu), jejímuž splnění zadavatel bránil.
Přístup Protokolu k řešení souběžného zpoždění (jakmile je stanoveno)

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 34


zabraňuje sporům o to, zda zpoždění zadavatele působící současně se
zpožděním zhotovitele skutečně nějakým způsobem brání postupu zhotovitele.

11. Časová analýza vzdálená od události zpoždění


Pokud je žádost o EOT posuzována po dokončení prací nebo výrazně po vzniku
rizikové události zadavatele, nemusí být již vhodná prospektivní analýza
zpoždění uvedená v pokynech k základní zásadě 4.
11.1 Tento oddíl se zabývá posuzováním žádostí o EOT po dokončení prací nebo
výrazně po vzniku události zpoždění nebo jejího dopadu. Za těchto okolností
již nemusí být výhledová analýza zpoždění uvedená v pokynech k hlavní
zásadě 4 v části B relevantní nebo vhodná.
11.2 Bez ohledu na to, která metoda analýzy zpoždění je použita, je prvořadým
cílem zajistit, aby závěry vyvozené z této analýzy byly správné z hlediska
zdravého rozumu. To je zvláště důležité v případech, kdy existuje značné
riziko, že zbývající projekce trvání, logické vazby, kalendáře a omezení v
rámci základního programu (nejlépe přijatého/aktualizovaného programu)
mohou vést k anomálním výsledkům.
11.3 Volba metody analýzy zpoždění, která má být použita, by měla být určena na
základě následujících kritérií:
(a) příslušné smluvní podmínky;
(b) povahu příčinných událostí;
(c) povaha projektu;
(d) zajistit přiměřený přístup, hodnotu projektu nebo sporu;
(e) čas, který je k dispozici;
(f) povahu, rozsah a kvalitu dostupných záznamů;
(g) povahu, rozsah a kvalitu dostupných informací o programu a
(h) fórum, na kterém se hodnocení provádí.
Různé metody analýzy zpoždění
11.4 Existuje šest běžně používaných metod analýzy zpoždění, které jsou
podrobněji popsány níže. Obecné vysvětlení:
(a) Některé metody začínají identifikací a popisem události (příčiny) a
následně se snaží zjistit její dopad (následek) - jedná se o analýzy typu
příčina a následek. Jiné metody začínají identifikací kritického
zpoždění (následek) a následně se snaží zjistit, co mohlo toto zpoždění
způsobit - jedná se o analýzy typu následek a příčina. Pokud je žádost o
EOT posuzována po dokončení prací nebo výrazně po účinku rizikové
události zadavatele, pak se účinek

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 35


a metody příčin jsou obecně považovány za forenzně spolehlivější,
protože berou v úvahu všechny možné příčiny vzniklého zpoždění.
(Naproti tomu v případě, že se jedná o samostatnou rizikovou událost
zaměstnavatele a žádost o EOT se podává současně, se obvykle
používají metody příčiny a následku, protože v opačném případě by
příslušný orgán musel "čekat a čekat" (což se nedoporučuje). To je
jeden z klíčových důvodů, proč se pro souběžnou analýzu zpoždění
doporučuje metoda analýzy časových dopadů, jak je vysvětleno v
pokynech k hlavní zásadě 4).
(b) Analýza zpoždění obvykle vyžaduje identifikaci kritické cesty
(kritických cest) k datu dokončení, protože zpoždění, která ovlivňují
datum dokončení, se z definice musí nacházet na kritické cestě. Často
je kritická cesta posloupností nebo řetězcem činností v rámci
zbývajících prací. V některých projektech však může kritická cesta,
která určuje nebo určuje datum dokončení, probíhat prostřednictvím
souboru souvisejících pracovních činností (například když je
dokončení určováno rychlostí svařování potrubí v rámci celého díla).
(c) Analýza kritické cesty se neomezuje pouze na analýzu prováděnou
pomocí specializovaného programovacího softwaru. Ačkoli takový
software může být účinným analytickým nástrojem, kritickou cestu k
dokončení lze v některých případech spolehlivěji stanovit na základě
praktické analýzy příslušných skutečností nebo analýzy údajů o výrobě
a/nebo zdrojích.
(d) Kritičnost se určuje jedním ze tří různých způsobů. Čistě prospektivní
hodnocení kritické cesty vychází pouze z perspektivy zřejmé na
začátku projektu a nebere v úvahu dosažený pokrok. Současné
hodnocení kritické cesty vychází z perspektivy, která se v průběhu
prací vyvíjí, a zohledňuje vliv, který má na předpokládanou kritičnost
jak historický pokrok, tak změny ve strategii budoucího provádění
prací. Retrospektivní hodnocení kritické cesty vychází z perspektivy,
která je zřejmá na konci projektu (nebo v určitém časovém období).
(e) Dopad zpoždění se určuje jedním ze dvou různých způsobů.
Výhledová analýza zpoždění určuje pravděpodobný dopad historického
postupu nebo událostí zpoždění na termín dokončení. Závěry
výhledové analýzy zpoždění nemusí odpovídat programu podle
skutečného stavu, protože skutečný výkon zhotovitele mohl být
ovlivněn účinky pokusů o urychlení, změnu pořadí nebo přesun zdrojů
ve snaze vyhnout se odpovědnosti za smluvní pokuty nebo v důsledku
jiných rizikových událostí zadavatele a zhotovitele. Retrospektivní
analýza zpoždění identifikuje skutečný dopad událostí zpoždění na
identifikovanou skutečnou nebo postavenou kritickou cestu.
(f) Jak bylo uvedeno výše, protokol rozlišuje mezi určením kritické cesty
a určením dopadu zpoždění. Například jak v analýze dopadu na čas,
tak v analýze časového úseku

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 36


metody analýzy oken (které jsou vysvětleny níže), se kritická cesta
určuje na základě současného stavu. V první metodě je však dopad
zpoždění stanoven na prospektivním základě, což je modelovaný
přírůstkový dopad události zpoždění na budoucí a zbývající program
prací od data konkrétní analýzy časového dopadu. Naopak u druhé
metody se dopad zpoždění určuje retrospektivně, tj. jako historický
dopad zpoždění na kritickou cestu v časovém úseku do data konkrétní
analýzy.
11.5 V následující tabulce je uveden přehled níže popsaných metod:

Metoda Typ Stanovení Stanovení


Vyžaduje
analýzy analýzy kritické dopadu
cesty zpoždění
Analýza Příčina Perspektivně Perspektivně • Logicky provázaný
dopadů podle a základní program.
plánu následek • Výběr událostí
zpoždění, které se
mají modelovat.
Analýza Příčina Současně Perspektivně • Logicky provázaný
časového a základní program.
dopadu následek • Aktualizovat programy
nebo informace o
pokroku, na jejichž
základě lze aktualizovat
výchozí program.
• Výběr událostí
zpoždění, které se
mají modelovat.
Analýza Důslede Současně Retrospektivně • Logicky provázaný
časového ka základní program.
řezu oken příčina • Aktualizovat programy
nebo informace o
pokroku, na jejichž
základě lze aktualizovat
výchozí program.
Okna podle Důslede Současně Retrospektivně • Základní program.
plánu versus ka • Údaje o stavu konstrukce.
okna ve příčina
stavu, v
jakém byla
postavena
Analýza
Retrospektiva Důslede Retrospektivně Retrospektivně • Základní program.
Analýza ka • Program As-built.
nejdelší příčina
cesty
Analýza Příčina Retrospektivně Retrospektivně • Logicky propojený
zhroucených a program as-built.
budov následek • Výběr událostí
zpoždění, které se
mají modelovat.

11.6 Některé z těchto metod vyžadují základní program. Pokud strany postupovaly
podle pokynů k základní zásadě 1 v části B, budou to přijaté/aktualizované
programy. Pokud strany nepostupovaly podle pokynů k hlavní zásadě 1 v části
B a při provádění analýzy zpoždění byla přijata jedna z těchto metod, mohlo
SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 37
by to vést k většímu prostoru pro neshody ohledně posouzení zpoždění.
(a) Metoda analýzy s dopadem podle plánu zahrnuje zavedení dílčích sítí
událostí se zpožděním do logicky provázaného základního programu a
jeho

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 38


přepočet pomocí programového softwaru CPM s cílem určit výhledový
dopad těchto událostí na předpokládané termíny dokončení zakázky
uvedené v základním programu. Před zahájením analýzy musí analytik
potvrdit, že posloupnosti a doby trvání prací uvedené v programu jsou
přiměřené, realistické a dosažitelné a v rámci softwaru řádně logicky
propojené, aby se vypořádal s rizikem, že základní program obsahuje
zásadní nedostatky, které nelze odstranit. Obecně se má za to, že jde o
nejjednodušší a nejlevnější formu analýzy zpoždění, která má však
podstatná omezení, především proto, že nezohledňuje skutečný postup
a změny původního plánovaného záměru. Výsledkem této metody
analýzy je závěr o pravděpodobném vlivu modelovaných událostí
zpoždění na základní program. Za omezených okolností lze tuto
analýzu považovat za dostatečnou pro posouzení nároku na EOT. K
takovým okolnostem patří případy, kdy je ovlivněná plánovaná metoda
diktována podmínkami smlouvy a/nebo kdy zvažované události
zpoždění nastanou hned na začátku prací.
(b) Analýza časového dopadu zahrnuje zavedení dílčích sítí událostí
zpoždění do logicky provázaného základního programu a přepočet
tohoto aktualizovaného programu pomocí programovacího softwaru
CPM s cílem určit výhledový dopad události zpoždění na
předpokládané termíny dokončení. Výchozím programem pro každou
analýzu může být buď současný program, nebo současný
aktualizovaný výchozí program (tj. aktualizovaný program), přičemž
rozdíl spočívá v tom, že revidovaný současný program může mít
logické změny / změny činností / zdrojů oproti původnímu výchozímu
programu. V obou případech musí analytik ověřit, zda historické
součásti základního programu odrážejí skutečný postup prací a zda
jsou jeho budoucí posloupnosti a doby trvání prací přiměřené,
realistické a dosažitelné a zda jsou v rámci softwaru správně logicky
propojeny. Je třeba vzít v úvahu zmírnění a zrychlení, která již byla
začleněna do aktualizovaného základního programu, protože mohou
zakrýt nebo zkreslit předpokládaný dopad událostí zpoždění. Počet
modelovaných událostí zpoždění má významný vliv na složitost a
náklady na nasazení této metody. Výsledkem této metody analýzy je
závěr o pravděpodobném zpoždění modelovaných událostí zpoždění na
programu/kritické cestě, který nejvíce odráží současnou situaci v době
vzniku událostí zpoždění. Tato metoda obvykle nezachycuje případné
skutečné zpoždění způsobené událostmi zpoždění, protože se
nezohledňuje následný postup projektu. Tato metoda je rovněž popsána
v pokynech k hlavní zásadě 4 v souvislosti se současným posouzením
žádosti o povolení k provozu.

(c) Metoda analýzy časových úseků je první ze dvou metod analýzy


"oken". Tato metoda vyžaduje, aby analytik ověřil (nebo vytvořil)
spolehlivou řadu současně aktualizovaných výchozích programů nebo
revidovaných současných programů, které odrážejí přesný stav prací v
různých časových okamžicích (což jsou časové úseky) v průběhu prací.
Prostřednictvím tohoto procesu se postup prací

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 39


rozdělené na časové úseky. Časové úseky se obvykle provádějí v
měsíčních intervalech. Série programů časových řezů odhaluje
současnou nebo skutečnou kritickou cestu v každém období časového
řezu v průběhu prací a stav kritického zpoždění na konci každého
časového řezu, což analytikovi umožňuje vyvodit závěr o rozsahu
skutečného kritického zpoždění vzniklého v rámci každého okna. Poté
analytik prozkoumá záznamy o projektu, aby zjistil, jaké události
mohly způsobit zjištěné kritické zpoždění v každém období časového
úseku. Pro každý program časového úseku musí analytik ověřit, zda
historické složky odrážejí skutečný postup prací a zda jsou jeho
budoucí posloupnosti a doby trvání prací přiměřené, realistické a
dosažitelné a zda jsou v rámci softwaru řádně logicky propojeny.
(d) Metoda analýzy oken podle plánu a podle stavu je druhou z metod
analýzy oken. Na rozdíl od analýzy časových úseků je méně závislá na
programovém softwaru a obvykle se používá v případě, že existují
obavy o platnost nebo přiměřenost výchozího programu a/nebo
současně aktualizovaných programů a/nebo v případě, že existuje příliš
málo současně aktualizovaných programů. Při této metodě je doba
trvání prací rozdělena do oken. Tato okna jsou ohraničena
revidovanými souběžnými programy, souběžně aktualizovanými
programy, milníky nebo významnými událostmi. Analytik určí
současnou nebo aktuální kritickou cestu v každém okně na základě
analýzy dostupných skutečností zdravým rozumem a v praxi. Protože
tento úkol není v podstatě závislý na programovém softwaru, je
důležité, aby analytik uvedl důvody a zdůvodnění, na jejichž základě
byla kritičnost určena. Výskyt a rozsah kritického zpoždění v každém
okně se pak určí porovnáním klíčových dat na současné nebo skutečné
kritické cestě s odpovídajícími plánovanými daty ve výchozím
programu. Poté analytik prozkoumá záznamy o projektu, aby zjistil,
jaké události zpoždění mohly způsobit zjištěné kritické zpoždění.
Vzniklé kritické zpoždění a dosažené zmírnění nebo urychlení v
každém okně se kumuluje, aby bylo možné identifikovat kritické
zpoždění po celou dobu trvání prací.

(e) Metoda retrospektivní analýzy nejdelší cesty zahrnuje stanovení


retrospektivní kritické cesty podle stavu (která by neměla být
zaměňována se současnou nebo skutečnou kritickou cestou určenou ve
výše uvedených metodách oken). Při této metodě musí analytik nejprve
ověřit nebo vypracovat podrobný program as-built. Po jeho dokončení
pak analytik sleduje nejdelší souvislou cestu zpětně od skutečného data
dokončení, aby určil kritickou cestu podle stavu. Výskyt a rozsah
kritického zpoždění se pak určuje porovnáním klíčových termínů na
kritické cestě podle plánu s odpovídajícími plánovanými termíny ve
výchozím programu. Poté analytik prozkoumá záznamy o projektu, aby
zjistil, jaké události mohly způsobit zjištěné kritické zpoždění.
Omezením této metody je její omezenější schopnost rozpoznat a
zohlednit změny kritické cesty v průběhu prací.

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 40


(f) Metoda analýzy zhroucení podle stavu (nebo "ale pro") zahrnuje
extrakci událostí zpoždění z programu podle stavu, aby bylo možné
stanovit hypotézu, co by se mohlo stát, kdyby k událostem zpoždění
nedošlo. Tato metoda nevyžaduje výchozí program. Tato metoda
vyžaduje podrobný logicky provázaný program as-built. Je vzácné, že
by takový program na projektu existoval, a proto se obvykle vyžaduje,
aby analytik zavedl logiku do ověřeného programu as-built. To může
být časově náročné a složité. Po dokončení se identifikují dílčí sítě pro
události zpoždění v rámci programu as- built a tyto sítě se "sbalí" nebo
extrahují, aby se určil čistý dopad událostí zpoždění. Tato metoda se
někdy provádí v oknech s využitím průběžných nebo současných
programů, které obsahují podrobné a komplexní údaje o stavu
rozestavěnosti. Omezení této metody spočívá v tom, že měří pouze
přírůstkové zpoždění vůči kritické cestě, protože datum dokončení se
nezhroutí dále než k nejbližší blízké kritické cestě.
11.7 Mezi další metody, které lze za určitých okolností přiměřeně použít po zvážení
kritérií uvedených v odstavci 11.3 výše, patří: retrospektivní analýza
plánovaného stavu ve srovnání se stavem (tj. ne v oknech), analýza časového
řetězení, analýza bilanční linie, analýza křivky zdrojů a analýza získané
hodnoty.
11.8 Aby se předešlo sporům o metodiku nebo aby se tyto spory alespoň
minimalizovaly, doporučuje se, aby se strany pokusily dohodnout na vhodné
metodě analýzy zpoždění dříve, než se každá z nich pustí do významné práce
na analýze zpoždění po události. Nekonzultování metodiky analýzy zpoždění s
druhou stranou je záležitost, kterou by podle protokolu mohl rozhodce, soudce
nebo rozhodce zohlednit při přiznávání a rozdělování nahraditelných nákladů
sporu.

12. Souvislost mezi EOT a kompenzacemi


Nárok na EOT neznamená automaticky nárok na odškodnění (a naopak).
12.1 Ve stavebnictví panuje mylná představa, že pokud má zhotovitel nárok na
EOT, má automaticky nárok i na kompenzaci za dodatečný čas, který
potřeboval k dokončení zakázky.
12.2 Podle běžných standardních smluvních formulářů je zhotovitel téměř vždy
povinen uplatnit svůj nárok na prodloužení smlouvy podle jednoho ustanovení
smlouvy a svůj nárok na náhradu za toto prodloužení podle jiného ustanovení.
Kromě toho některé druhy zpoždění, které jsou na riziko zadavatele, pokud jde
o dobu dokončení, nezakládají nárok na náhradu za prodloužení; nejčastějším
příkladem je zpoždění v důsledku nepříznivých povětrnostních podmínek.
Někdy se jim zavádějícím způsobem říká "neutrální události"; ve skutečnosti
jsou neutrální pouze v tom smyslu, že jedna strana nese časové riziko a druhá
strana nese riziko nákladů. Protokol je nazývá "nekompenzovatelné rizikové
události zaměstnavatele". Neexistuje tedy absolutní vazba

SCL Delay and Disruption Protocol 2nd Edition: Únor 2017 41

You might also like