TOP Advokátní kancelář na českém a slovenském trhu

Datum: 03.10.2016

V létě roku 2012 vznikla v prostředí významné české advokátní kanceláře potřeba řešit aktuální nevyhovující stav implementace zcela nového informačního systému. Jeho výběr proběhl o cca jeden rok dříve a v červenci 2012 proběhlo úspěšné nasazení ekonomického modulu, modulu EDM pro správu dokumentů (který ale nakonec využíván nebyl, jak popíši níže) a částečně personalistiky. U dalších komponent se však projekt začal zpožďovat a vykazoval nezpochybnitelné znaky projektu v budoucnu neúspěšného (a to jak v oblastech financí, tak především v časovém rámci). Protože investice do systému Helios Green byla a je pro společnost nezanedbatelná, bylo potřeba situaci urychleně řešit.

K tomu, abychom se domluvili na spolupráci, pomohlo analytické myšlení při řešení vzniklých problémů a lidská komunikace mezi externími konzultanty a businessovou stranou, tedy samotnými právníky společně s jejich backofficem.

Nejprve identifikace a „druhá“ analýza…

Situace byla velmi odlišná např. od té v People Management Foru popsané na jiném místě. Žádná „zelená louka“ a stavba komponent zcela nových. Projekt byl v plném běhu, popsán harmonogramem a širokým spektrem analýz pro customizaci produktu pro potřeby společnosti. Bylo tedy potřeba především identifikovat kritická místa způsobující problémy, tato následně analyzovat (a doplnit tím prvotní dokumentaci) a uvést do praxe tak, aby se projekt navrátil do rozvržených termínů a sprintů v nich naplánovaných.

Na základě odhalení nedostatků zejména v modulech pro správu zakázek a CRM (což jsou pro firmu životně důležité oblasti) byl sestaven notně obměněný projektový tým, ve kterém nově figuroval pouze jeden hlavní zástupce businessu (zároveň projektový manažer a partner kanceláře) společně s mou osobou za systémovou oblast a hlavní konzultanti za tyto oblasti spolu s vedoucím projektu za stranu dodavatele. Připravili jsme krizový plán projektu a pustili se do práce na klíčových modulech.

Větší důraz na BRQ – požadavky na funkcionality

BRQ – požadavky businessu na funkcionality IT. Logická věc, zdá se. V projektu advokátní kanceláře však byly v mnoha ohledech zanedbány, což nevyhnutelně vedlo k rozporu mezi dodávaným produktem a očekáváním zákazníka. Rozdíl v přístupu různých konzultantů (pro různé oblasti systému) byl patrný i na výsledcích. Zcela chyběl zastřešující prvek – product owner a architekt celého řešení, kteří by udržovali jednotnost dodávek a koordinaci s klíčovými zákazníky. Zatímco ekonomický modul profesionálně mapován zkušeným konzultantem obstával v testech bez větších problémů, další moduly (personalistiky, zakázky, CRM a další méně významné) se dostávaly do skluzu a rozporu s realitou procesů. Velké množství personalizovaných úprav ruku v ruce s neexistující dokumentací těchto změn pak vedly k značně ztížené možnosti rozklíčovat problémové situace a uvést je do požadovaného stavu.

Jak situaci řešit?

Obsazení klíčových rolí. Existence krizového plánu. Efektivní zapojení klíčových uživatelů.

„Vyhlásíme krizový stav“ – věta známá spíše z aktuálních politických situací některých států fungovala i v projektu. Dodavatel zvolil zkušeného krizového manažera jako architekta řešení (a změn), já se ujal role majitele produktu vůči klientovi a společně jsme naplánovali následující 3-4 měsíce po jednotlivých sprintech (cca týdnech) tak, abychom postupně odbourávaly nedostatky seřazené do tzv. product backlogu, tedy jakési pyramidy problémů rozvrstvených podle priorit a dopadů na uživatele.

Obrázek č.1: Pyramida Product Backlogu v modulu zakázek a CRM / různé úrovně závažnosti problémů

Rozbor transformačních míst

Aneb „sice pozdě, ale dodavatel se začal ptát uživatelů, CO POTŘEBUJÍ a JAK JIM SYSTÉM MŮŽE POMOCI“

První dva sprinty jsme projekt v podstatě odstartovali znovu – zapojili jsme na pravidelných schůzkách a stínováním jejich činnosti klíčové uživatele. Na tomto základě vznikl set BRQ, které byly přiřazeny k existujícím problémům v product backlogu. Neomylně jsme tak dokázali spárovat existující (i potenciální) problémy a uživatele, kteří nám s jejich řešením měli být nápomocni. Prošli jsme s nimi jejich pracovní proces „as-is“ a v následujícím třetím sprintu jsme jim předložili návrhy refaktoringu (někdy větší, někdy méně významné změny v jejich procesech) tak, aby stáli u zrodu změn, pochopili je a případně nám je pomohli definovat lépe.

Všichni spolupracovali a vyzařovali spokojenost, kterou shrnuje následující citace jedné z uživatelek: „Oceňuji, že se nás někdo konečně zeptal, co od toho potřebujeme.“

Popsaný proces je jediná cesta, nepopsaný proces jakoby nebyl

Kapitola popisu a nastavení procesů je ve větším projektu stejně důležitá, jako v malém

Následovala fáze několika sprintů, kde jsme vyřešili prioritní body z product backlogu ruku v ruce s úpravou automatizace procesů v informačním systému. Tím, že většina problémů se vztahovala přímo či nepřímo k procesům, jsme mohli tyto fáze spojit a pracovat na nich současně. Hodně se pracovalo se zakázkami, které dokázaly sice plnit svůj účel, avšak s příliš mnoha ručními zásahy do procesu, který měl být v maximální míře automatizován. Druhotným problémem pro proces zakázek, avšak prvotním pro marketingové oddělení a backoffice pak byly problémy s CRM, které neplnilo svou funkci dostatečně a řešení správy firemních kontaktů, jakožto obrovského duševního vlastnictví společnosti, v podstatě nefungovalo.

Abych situaci dokázal lépe osvětlit, uvedu příklad procesu Zakázka – životní cyklus a na něj navázané druhotné procesy (vychází z obrázku č.1) – tedy na modulech Zakázka a CRM.

Situace As-Is, tedy jak byla implementována dodavatelem

Proces zakázky mohl začít celkem třemi událostmi:

Založením „Objednávky“ (většinou interní zakázky, např. spolupráce s Českou poštou či kurýrní společností), které jsou dále převedeny pod společnou „Kauzu“ s jednotlivými „Tasky“ (neboli podřízenými zakázkami) většinou pracujícími na každý kalendářní měsíc.
Založením „Obchodní příležitosti“ jakožto snahy o získání zakázky, která (v případě úspěšného jednání) je převedena na potenciální „Kauzu“, která je následně provedena celý životním cyklem (potenciální – aktivní – schválená pro fakturaci – fakturace – uzavřeno/ukončeno) s tím, že fakturované služby se ukládají na již zmiňované „Tasky“ (které jediné umožňují reálnou fakturaci) s vlastním životním cyklem, ovšem bez vnějších pravidel. (jinými slovy, některé týmy uzavíraly tasky po měsících, jiné po roce, jiné otevírali nový task pro každou novou fakturu, jiné pro každý jiný „podjob“ v dané kauze. Existovala i varianta, že byla vedena jedna KAUZA jako paralela ke KLIENTOVI a pro každou novou zakázku byl otevírán TASK)
Založením „Kauzy“ ve stavu pasivním. Následný proces pak pracoval stejně jako v bodě 2), ovšem v jiném stavovém cyklu u záznamů pořadače „Kauzy“.

Jak je vidět, práci s celým modulem zakázek ztěžovaly jednak technické nedostatky (2 různé stavové stromy pro pořadač Kauz, příliš mnoho kombinací stavových stromů u zakázek navazujících či nadřízených/podřízených, nejasnost vztahu mezi Obchodní příležitostí a Kauzou/Taskem – př. OP šla převést jak na Task, tak na Kauzu. Pod OP nešlo zakládat tasky a další problémy). Druhým problémem pak bylo nastavení procesu, který nebyl popsán a představen uživatelům a tak si „každý ukládal svá data jak se mu zachtělo“ a vznikala značně nejednotná databáze, která v konečném důsledku eskalovala v procesu marketingovém (neporovnatelná data pro zpětné evaluování), tak i ekonomickém (nemožnost jednotné fakturace, problémy se schvalováním způsobené rozdílností v evidenci poskytovaných služeb). Problémy se následně vracely do businessových týmů jako bumerang v podobě zpožděných faktur či nemožnosti měřit efektivitu vynaloženého času na jednotlivé klienty či segmenty.

Situace To-Be, tedy jak by měla fungovat

Zjednodušit, sjednotit, popsat a pro jistotu ještě jednou zjednodušit.

Tak by se dala shrnout hlavní motivace směrem k výše popsanému stavu. Rozhovory s dotčenými uživateli ukázaly, že se mnoho činností zbytečně dubluje, že je jednotlivých kroků příliš mnoho a že panuje značný rozpor v jednotě zapisování dat a v práci s nimi. Vlastním know-how zkombinovaným s rozhovory s uživateli jsme postavili budoucí stav tak, jak jej systém musí naplňovat.

Nevyhneme se rozdělení na interní a externí zakázky – recepční a asistentky společně s fakturantkami potřebují proces odlišný od standardních zakázek směrem ke klientům. K tomu byl ostatně systém i připravován.

Velké změny čekaly systém právě v zakázkách externích:

Pro interní zakázky bude stále zakládána „Objednávka“ s tím, že pod jednotlivými klienty budou založeny typové „Kauzy“ (nikoliv kauzy společné) – např. Poštovné, transport atd. s tím, že podřízené „Tasky“ budou kopírovat fakturační období, tedy měsíc. Zde se mnoho nezměnilo, byl „pouze“ upraven způsob evidování zakázek hlavních, tedy „Kauz“.
Jakákoliv externí zakázka měla nově vstupovat do jednotného procesu s jedním životním cyklem a zjednodušeným stavovým číselníkem tak, aby JEDEN proces pokryl všechny možnosti a tím byla zaručena konzistence dat. Zároveň musel být proces důkladně popsán a uveden jako „Pravidlo evidování zakázek“ tak, aby všechny týmy evidovaly svou práci jednotně, správně a úplně. Byly přidány či pozměněny důležité atributy pro marketingové i účetní oddělení a zároveň byl vytvořen vztah jejich propadu na podřízené zakázky. Byly vytvořeny nové třídy k evidování informací o zakázkách, které dosud nebylo možno zapisovat a byly připraveny i další funkcionality zapadající do požadavků (místy dokonce v rámci legislativní nutnosti) businessu.

Proces názorně ukážu na modelu doprovázeném popisky k jeho průběhu. Níže také příklad doplním o diagram tříd.

Obrázek č.2: proces zakázky tak, jak „by měl vypadat“ (To Be)

Kromě základního modelu procesu, natolik pozměněnému, že jde vlastně o model nový, jsme se museli zaměřit na další aspekty v modulu zakázka, které zabraňovaly hladkému fungování v praxi:

Dokumentace klíčových oblastí modulu a to dvojího rázu
- Technická dokumentace pro vývojáře, správce a další osoby s vazbou na IS
- Step-by-step dokumentace, návod, pro běžné uživatele u klíčových postupů
Úprava systému práv a dalších funkcí upravujících úroveň přístupu k datům
Úprava uživatelských rolí – týká se sice celého systému, ale v zakázkách šlo rovněž o důležitý faktor
Úprava modelu (a následné reality) tříd i s atributy a vztahy mezi nimi

Proces máme – teď jej pojďme uklidit

Společně s businessem jsme si definovali proces a BRQ. V tu chvíli víme, jak se má postupovat po celou dobu života zakázky a v čem konkrétně má systém uživatelům pomáhat, co je jeho cílem, jaké jsou jeho vstupy/výstupy i klíčoví uživatelé a databázová úložiště. V tuto chvíli tak bylo potřeba přistoupit k radikálnímu úklidu systému tak, aby splňoval požadavky, které jsme si definovali. Pojďme to vzít postupně po hlavních bodech (mnoho vedlejších bodů již nejsem schopen pojmout v relativně omezeném prostoru této praktické ukázky):

Dokumentace – aneb oceníme ji až v případě krize

Tvořit dokumentaci je čiré zlo.

To je fakt, který potvrdí většina lidí profesí, které se s touto činností více či méně často setkávají. Je potřeba ji psát průběžně (ne, po roce implementace už si NIKDO nevzpomene, jak přesně funguje každá funkce a co všechno obsahuje za atributy každý pořadač) a je potřeba ji aktualizovat při každé změně. Většinu času navíc tráví někde v hlubinách adresářové struktury (nebo vespod dokumentového cloudu systému DMS) či se na ni práší v nejzapadlejších poličkách kanceláře. Až jednoho dne přijde krize, změna, problém, příležitost…

… které vyžadují zásah do IS. Pokud máte to převeliké štěstí, že vám systém spravuje stále stejný (šikovný) člověk a/nebo na úpravy IS můžete (a chcete) najmout stejného dodavatele a ten k vám navíc pošle stejného konzultanta/programátora, který dělal původní implementaci a ten si navíc implementaci pamatuje, pak můžete tuto kapitolu vynechat. V ostatních 99% případů ovšem jeden nebo více zainteresovaných lidí nebude vědět, jak přesně je ta daná oblast nadefinována, jak přesně fungují vztahy, funkce atd. Co může nastat?

Nebudou to řešit, učiní požadované zásahy bez snahy o zachování závislostí a tím v mnoha případech jeden problém vyřeší a dva přidělají.
Budou to řešit a budou se snažit si pečlivě nastudovat danou oblast a veškeré dotčené závislosti – a to si buď přečtou v pečlivé dokumentaci, nebo to musí zjistit reverzně přímo v systému. Uhádnete, která možnost je časově (mnohem) náročnější?

Je dobré, kromě technické dokumentace (detailní popis tříd, vztahů, funkcionalit, funkcí, omezení a dalších faktorů ideálně s kvalitními modely), kterou ocení vývojář/programátor pracující na změnových požadavcích či nový správce před měsícem najatý, aby vám systém obsluhoval interně, je dobré myslet také na uživatele a připravit pro ně ste-by-step (mě se osvědčily i screenshoty s vyznačenými body 1…X) návod na „jejich“ činnosti tak, aby se je naučili dělat rychle, intuitivně a hlavně každý STEJNĚ (tam, kde to jde, samozřejmě).

Práva – vidím moc? Vidím málo? Vidím, to co potřebuji?

Nastavení systému práv, zvlášť pokud je složitější než dělení na dvě role admin-uživatel, je bolestí každého systému. Nastavte je příliš volná a budete čelit faktu, že, velmi zjednodušeně, „každý uvidí vše“. Nastavte je příliš přísná a často budete čelit požadavkům na jejich rozšíření. Nastavte je na konkrétní uživatele a časem ztratíte přehled, kdo co vlastně vidí a smí. Nastavte je na role a může se vám stát, že nepokryjete individuální potřeby.

Jak z toho tedy ven?

Základem je, dle mého názoru, práva přidávat a nikoliv ubírat. Což byla zároveň zásadní změna oproti stávajícímu nastavení práv v prostředí kanceláře.

Druhým základem je, opět – dle mých zkušeností, striktně NENASTAVOVAT práva na jméno, ale na role. Nebude to jednoduché, bude stát hodně úsilí vymyslet takový systém rolí, který pokryje (ať už jednotlivě, nebo i v kombinaci) potřeby každého uživatele systému na vstupy a výstupy, které ke své práci potřebuje vidět, ale výsledek bude stát za to.

Co jsme tedy změnili? Uvedu dva zjednodušené příklady:

Zjistili jsme, že systém práv byl volen metodou ubírání, jinými slovy, každá role dostala plná práva a ta jim byla ubírána. Vznikly dva konkrétní problémy:
- Mnoho rolí mělo práva do oblastí systému, kam vidět nepotřebuje, v mnoha případech ani nesmí a díky absenci dokumentace to bylo obtížně zjistitelné.
- Díky nepopsanému systému rolí a nedostatečnému vyškolení tehdejšího správce byly od počátku užívání v praxi používány práva na jméno. Po 1 roce provozu už prakticky nebylo možné dohledat, „kdo na co vidí“, což v kombinaci s dalšími restriktivními pravidly upravujícími možnosti práv činilo takřka nemožné identifikovat v rozumné době místo, které zamezuje uživateli A vidět objekt B, který zrovna vidět potřebuje.

Což plynule přechází v problém druhý:

Systém rolí byl zvolen nevhodně podle procesu/činnosti, nikoliv podle role / pozice uživatelů. A tedy se v systému objevovala role např. „Fakturace vydaná“ nebo „Kauza zadávání“ a „Kauza administrace“. Těchto rolí bylo cca 40 a k nim byli nějak (bohužel bez zdokumentování) přiřazeni uživatelé. Bez řádného popisu bylo velmi obtížné identifikovat, co je obsahem konkrétní role, každý uživatel navíc v průměru dosahoval zařazení do cca 10-16 rolí, což administraci nijak neulehčuje. Řešení?
- Udělat rolí méně a s jasnou funkcí: „HR“, „Advokát“, „Koncipient“, „Fakturtantka“ atd.

Jejich název jasně identifikuje její obsah a liniovou pozici. V případě kombinace rolí (např. recepční dočasně vypomáhá s evidencí dokladů HR, daný uživatel je tedy dočasně přiřazen kromě role „Recepční“ i do role „HR“ čímž získá potřebná oprávnění a následně je snadno dohledatelné, komu roli odebrat po skončení úkolu nad rámec běžných povinností) je pak snadné role přiřazovat a snadné role také následně odebírat – vše je transparentní a nevázané na konkrétní jména.

Třídy – diagram je tu pro realitu, nikoliv realita pro diagram

Každý, nebo tedy takřka každý, systém disponuje svou architekturou „ve standartu“. Včetně tříd a jiných objektů, které pak realita využívá při práci s ním. Velkou (a zároveň bohužel častou) chybou implementátorů ovšem bývá, a ponechme teď stranou, zda záměrně či z jiných důvodů – většinou časových, že „ohýbají“ realitu podle svých modelů namísto aby přizpůsobili model realitě. Samozřejmě – po důkladných analýzách, kde můžeme realitu podniku ovlivnit nějakými best-practices nebo svým know-how z obdobných projektů. Každopádně závěrem analýzy je proces tak, jak má fungovat. A to včetně upraveného diagramu tříd, který se projeví do reality.

Proces tak, jak jde celým svým životním cyklem, jste už viděli. Nyní se vám pokusím ukázat, jak vypadá zjednodušený entitní diagram (pouze důležité třídy, nikoliv každá, kterou modul zakázek obsahuje) s tím, že níže jsou popsány jednotlivé závislosti i s popisem, v jakém stavu byla realita (nikoli diagram, ten totiž fyzicky neexistoval) předtím, než jsme do procesu vstoupili.

Zjednodušený diagram tříd

Diagram tříd jako takový nebyl součástí dokumentace dodavatelů a jeho vytvoření tak bylo na našem interním týmu. Nově vzniklý diagram tříd a kardinality jejich vztahů zobrazuje pro budoucí správce či vývojáře změn cenné informace o funkčnosti celého systému – nebo v tomto případě modulu zakázek. Ještě mnoho závislostí není v tomto diagramu zanesených – reálně bylo nutné rozdělit realitu modulu na mnoho samostatných „bloků“ se vzájemnými závislostmi mezi sebou tak, aby vůbec jeden diagram byl schopný podchytit úplnou realitu a zároveň zůstal přehledný pro budoucí správce či vývojové týmy.

Jak je vidět, a je to i logické, stěžejní jsou třídy generované třídou „Zakázka“, která obsluhuje všechny své mutace, které dědí její vlastnosti a pro své účely si je modifikují. Pro zjednodušení jsem u jednotlivých tříd nespecifikoval atributy a ty doplnil jen u třídy Zakázka – všechny tyto atributy jsou dále děděny. Třídy typu zakázka kopírují proces zakázky tak, jak jsme viděli výše. V původní realitě fungovalo však tříd méně – kauza, task a objednávka. Třídy obchodní příležitost a marketingová akce sice v systému reálně byly, avšak nebyly nikterak využívány. My jsme je do procesu zahrnuli a to z podstatných důvodů vzhledem k požadavkům businessu:

Chceme sledovat úspěšnost našich potenciálních zakázek
Chceme vědět, kolik práce odvedli naši lidé na mandátu do doby, než je podepsána smlouva (náklady na akvizici)
Chceme znát rozpočet našich marketingových akcí, časovou vytíženost zaměstnanců a reálné výsledky
…a takto bych mohl pokračovat, pro ukázku si však vystačíme s těmito třemi požadavky.

Museli jsme tedy dotvořit obě zmíněné třídy tak, aby vyhovovaly potřebám a zároveň je zahrnout do workflow „života“ zakázky. Jak jsme se vypořádali s businessovými požadavky?

Každá potenciální zakázka vzniká jako obchodní příležitost pod kterou je přiřazen task (ve chvíli, kdy je třeba vykazovat). Na tento task mohou vykazující pracovníci evidovat svůj čas a typ činnosti tak, abychom byli schopni sledovat časovou náročnost práce na akvizici. Ve chvíli, kdy je tato aktivita neúspěšná, je obchodní příležitost ukončena a uložena, společně s evidovaným časem (interně ohodnoceným v modulu cenotvorby). Naproti tomu úspěšná zakázka je funkčně překlopena do kauz, ovšem s identifikátorem vzniku z obchodní příležitosti. To má dva důvody – redundance dat (neevidujeme tedy jednu zakázku jak pod OP, tak pod Kauzami) a efektivní zjištění % úspěšnosti potenciálních zakázek. Task s evidovaným časem je samozřejmě převeden pod nově vzniklou kauzu společně s obchodní příležitostí.
Kolik práce odvedli lidé na mandátu do doby podpisu smlouvy (=vzniku kauzy) je popsáno již v prvním odstavci.
Marketingové akce musely být využity, aby bylo vůbec možné tyto aktivity (mnohdy ne zcela levné) efektivně sledovat. Do doby, než jsme do procesu zahrnuli třídu MA, nebylo možno sledovat, kolik marketingové práce odvedli právníci na různých typech aktivit. Nebylo kde sledovat, jaký je rozpočet na marketingové akce a zda byl dodržen. Nebylo možné sledovat účel těchto aktivit a zda byl naplněn. A v neposlední řadě také nebylo možno zpětně dohledat – jaké akce tohoto typu se v minulosti konaly, co bylo jejich obsahem, kdo je koordinoval a kdo z klientů či potenciálních klientů na ně byl zván. To vše je nyní možné a aktivně se těchto možností využívá.

Poměrně specifickou a důležitou věcí pro firmu v právním odvětví jsou pak marketingové reference – tedy v podstatě evidence českých a anglických popisů transakcí s různým stupněm utajených informací (částka / měna / klient / protistrana) a následným zveřejňováním těchto informací na webu a jiných komunikačních kanálech a také v právních direktorářích a soutěžích o významná lokální i mezinárodní ocenění. To jsou publikace/ocenění v právním světě nesmírně důležitá, protože využívaná klienty při hledání vhodného partnera např. při vstupu na zahraniční trh či zajišťování významných investic. Tyto údaje nebyly v systému nikterak evidovány (což je s podivem, vzhledem k významnosti těchto informací pro kancelář) a zavedení této třídy tak bylo jednou ze stěžejních úprav modulu. Dnes lze evidovat reference pro různé druhy zakázek, lze u nich evidovat, kdy a pro jaký direktorář/ocenění byly použity, lze evidovat jejich změny i rozlišovat stupeň jejich utajení.

V zásadě je na příkladu vidět, že nelze pro klienta použít základní modul zakázek a předpokládat úspěch při nasazení takového procesu. Je nutné se opravdu bavit s klíčovými uživateli, zjistit jejich potřeby a v rámci možností systému nastavit proces tak, aby evidoval požadované informace a zároveň bylo uživatelsky příjemné tyto informace do systému zadávat a zpětně je v systému vyhledávat.

A jaký je závěr

Příklad nám ukazuje situaci, kdy ani zodpovědný výběr dodavatele a (na poměry podobně velikých společností) dostatečný finanční budget nezaručují (a to ani náznakem) úspěšný projekt. Naopak chybami a špatně nastaveným projektovým managementem se projekt zpožďuje / nedosahuje požadované kvality nebo se zdražuje. V horším, a bohužel i tomto, případě pak vše dohromady.

Aby se předešlo podobným situacím, osobně doporučuji několik základních bodů a jejich striktní dodržení v případě podobně velkých projektů:

Mějte svého interního architekta/analytika. Mějte ho v týmu nastálo jako interního zaměstnance, anebo jej poptejte za účelem projektu a spolupracujte s ním. Mějte člověka, který systémům rozumí a „v projektu bude kopat za vás“. Investice do jeho odměny po dobu projektu je zanedbatelná oproti rizikům, která s sebou nese jeho nepřítomnost.
Vždy přidejte čas věnovaný vstupním a technologickým analýzám oproti jakémukoliv odhadu. Je lepší chybám předcházet, než je napravovat. Je to i levnější. Drtivá většina odhadů na analýzy je podhodnocená – následky jsou logické – analýza je nedostatečná s tím, „že se to pak domyslí během implementace“. Nedomyslí se nic, nebude na to čas anebo po vás bude vyžadování schválení změny = další peníze navíc.

Udělejte si / nechte si udělat brutálně dobrou analýzu výchozího i cílového stavu. Jenom taková vám zajistí, že dostanete to, co si objednáváte.

Nevěřte větě „nic není problém, bude to umět všechno, co potřebujete“. Jistě jistě…za tuto částku, v tomto čase, ale pokud budete měnit zadání, change requesty naceníme sazbou 2000 Kč za hodinu práce (a to jsem ještě skromný vůči cenám mnoha firem). Pokud se bude stíhat a vy budete spokojeni s výstupy (asi 2% všech případů), pak je výše zmíněná věta pravdivá a vy můžete číst dále. Ve zbytku případů se projekt zpozdí, zdraží nebo zkomplikuje a výše zmíněná věta se změní na „to nebylo v zadání, to vám neuděláme jinak než novou zakázkou/změnovým projektem“. Co na tom, že je logické, aby vystavená faktura šla i vytisknout a vám se zdá logické, aby systém toto umožňoval. Nestíhá se, v zadání to není explicitně zmíněno, takže to tam prostě nebude, pokud nedoplatíte změnový požadavek.
Neakceptujte části projektu, které akceptovat podle vás nemáte (ale v tom by vám měl poradit člověk v prvním bodě) ani s příslibem, že se to dodělá ve druhé fázi (leda by šlo o písemně stvrzenou dohodu obou stran, pak je to asi jednou/dvakrát za projekt snesitelné). Nedodělá a bude se to s vám i táhnout po celou dobu projektu – analytici/konzultanti/vývojáři, ti všichni mají pevně daný režim na projekt a nepracují jenom pro vás, jakmile přeskočí z fáze nejvyššího scope do pozdějších fází, jejich angažovanost na vašem projektu se sníží a vás čeká nekonečné dohadování s projektovým manažerem dodavatele, aby vám uvolnil schopné lidi na dodělání podepsaných funkcionalit.
Poslední bod je možná nejdůležitější – člověka podle bodu 1 si vyberte zodpovědně. Svěřte mu řízení projektu a dodržení bodů 2-4. Vybrali jste-li dobře, věřte mu. Ví, co dělá.