Na čom stroskotávajú IT projekty v strednej firme

IT projekty v strednej firme zriedka stroskotávajú na technike. Stroskotávajú na nejasnom rozsahu, ktorý sa ako nejasný ukáže až počas realizácie, na chýbajúcom kontakte na strane klienta, na prestavbe za bežnej prevádzky bez záložného plánu, na preberacom konaní bez úplnej dokumentácie a na tom, že po ukončení projektu už nikto nie je jasne zodpovedný. Technika nakoniec vo väčšine prípadov funguje – projekt napriek tomu stroskotá, pretože týchto päť bodov nebolo vopred vyjasnených.

Nejasný rozsah

Najčastejším dôvodom, prečo sa IT projekt vymkne kontrole, je ponuka postavená na príliš hrubej predstave o skutočnej potrebe. „Nová sieť pre pobočku” znie jednoznačne, no nehovorí, či sa počíta s kamerovým systémom, či majú byť do siete pripojené výrobné zariadenia, alebo či je plánovaná druhá serverovňa ako záloha. Takéto medzery vyjdú najavo až počas realizácie – a vtedy vzniká otázka, či ide o dodatok, alebo o pôvodne dohodnutú súčasť plnenia. Nejasný rozsah je väčšinou vidieť už na samotnej ponuke: ak sa zmestí na jednu stranu bez toho, aby predtým prebehla obhliadka na mieste, spravidla chýba základ pre spoľahlivú kalkuláciu.

• Ponuku si nechať vypracovať až po obhliadke a inventarizácii na mieste, nie na základe stručného popisu
• Rozsah plnenia písomne stanoviť dostatočne konkrétne, aby mali obe strany rovnaké očakávanie
• Výslovne uviesť, čo nie je súčasťou projektu, nielen čo je zahrnuté

Chýbajúci kontakt na strane klienta

Projekt potrebuje na strane klienta niekoho, kto vie skutočne rozhodovať a je dostupný počas celej realizácie – nielen na začiatku a pri preberaní. Ak táto osoba chýba, alebo sa uprostred projektu vymení bez odovzdania, vznikajú oneskorenia pri veciach, ktoré by sa technicky vyriešili za pár minút: akú IP adresu má dostať nový server, či sa dá určitá oblasť cez víkend vypnúť, kto dá súhlas na zmenu vo firewalle. Problém spoznáte podľa toho, že otázky zostávajú dni bez odpovede, alebo na ne rôzne osoby odpovedajú protichodne.

• Určiť pevný kontakt so skutočnou rozhodovacou právomocou na celú dobu projektu
• Vopred vyjasniť zastupovanie počas dovolenky alebo choroby, aby sa projekt v tom čase nezastavil
• Dohodnúť krátke, pevné lehoty na rozhodnutia, aby boli oneskorenia viditeľné včas

Prestavba za bežnej prevádzky bez plánu B

Prestavby siete, firewallu alebo servera len zriedka prebiehajú v úplne zastavenej prevádzke – bežný chod väčšinou pokračuje aj počas realizácie. Ak sa takáto zmena zrealizuje bez definovanej cesty späť, pri probléme nikto nestojí pred voľbou medzi dvoma možnosťami, ale pred prevádzkou, ktorá stojí, kým sa problém nevyrieši. Týka sa to najmä zmien na centrálnych komponentoch ako firewall alebo hlavný switch, kde jediná chyba dokáže odrezať celú pobočku od komunikácie. Chýbajúci plán B sa väčšinou spozná až v kritickej chvíli – keď bola zmena naplánovaná, no nikto nevie povedať, ako sa v nasledujúcich desiatich minútach obnoví predchádzajúci stav.

• Kritické zmeny realizovať mimo hlavnej prevádzkovej doby, keď výpadok stojí najmenej
• Pred každou zmenou na centrálnom komponente konkrétne stanoviť cestu späť k predchádzajúcemu stavu, nielen plán dopredu
• Pri obzvlášť kritických systémoch predradiť testovaciu fázu s obmedzeným okruhom používateľov pred nasadením pre všetkých

Preberacie konanie bez dokumentácie

Projekt sa často považuje za ukončený už vtedy, keď technika funguje – dokumentácia sa doplní „až bude čas”, čo v praxi často znamená: nikdy. Preberacie konanie tak potvrdí funkčný stav, no nie to, že je tento stav zrozumiteľný aj pre niekoho iného než technika, ktorý ho realizoval. Problém sa väčšinou ukáže až o mesiace či roky neskôr, keď je potrebná zmena alebo má prevziať iný dodávateľ a nikto presne nevie, ako je systém postavený. Riziko sa dá spoznať už pri samotnom preberaní: je v tom momente k dispozícii úplná dokumentácia, alebo sa má „doplniť neskôr”?

• Úplnú dokumentáciu (plán siete, konfigurácie, prístupové údaje) požadovať ako súčasť preberacieho konania, nie ako dodatok
• Preberací protokol podpísať až vtedy, keď je dokumentácia skutočne k dispozícii a namátkovo overená
• Povinnosť dokumentácie zakotviť už v ponuke alebo zmluve, nie ju vyžadovať až na konci

Po ukončení nie je nikto zodpovedný

Po preberacom konaní sa projekt formálne končí – infraštruktúra však beží ďalej, mení sa, potrebuje aktualizácie a časom aj úpravy. Ak v tom momente nie je jasne určené, kto je v prípade pochybností zodpovedný, vzniká medzera medzi dvoma stavmi: projekt je hotový, no zmluva na priebežnú starostlivosť buď neexistuje, alebo je jej obsah nejasný. V praxi to často znamená, že pri ďalšej poruche treba najprv zistiť, koho vôbec zavolať – cenný čas, ktorý v kritickej chvíli chýba. Túto medzeru spoznáte, keď po ukončení projektu nikto nevie povedať, aké reakčné časy platia alebo kto je kontaktom pre bežnú prevádzku.

• Ešte pred ukončením projektu vyjasniť, či a v akej forme bude nasledovať priebežná starostlivosť
• Zodpovednosť za bežnú prevádzku písomne stanoviť, aj keď zostáva na strane klienta
• Uskutočniť odovzdávacie stretnutie, na ktorom sa konkrétne pomenuje interná zodpovednosť za údržbu, aktualizácie a poruchy

Čo skutočne robí IT projekt úspešným?

Úspešný IT projekt sa od stroskotaného zriedka líši lepšou technikou, ale lepším vyjasnením vopred: ponukou postavenou na skutočnej inventarizácii, pevným kontaktom na oboch stranách, definovanou cestou späť pre kritické zmeny, preberacím konaním, ktoré zahŕňa dokumentáciu, a jasnou odpoveďou na otázku, kto je zodpovedný po ukončení projektu. Kto tieto body vyjasní pred prvým krokom, zníži riziko stroskotania projektu výrazne viac než výberom konkrétneho výrobcu alebo technológie.