v jednej z komunikacii som objavil tento link:
http://spectrum.ieee.org/static/lessons-from-a-decade-of-it-failures
vyzera to na mega zdroj. urcite sa oplati precitat vsetkym, ktory na takom niecom robia. a poucit sa z toho cim skor 
rozoberaju tam presne niektore veci, ako velke projekty…
podla vas je aky najcastejsi dovod failnutia IT projektu?
zle nadefinovany “project scope” lepsie povedane “fail to manage project scope changes”; a samozrejme chybajuce a/alebo zle definovane “project sign-off/closure criteria”.
co som sa ja asi za 10 rokov vsimol u nas
Projekty failnu aj v zap. europe a predpokladam aj v statoch.
Zasadny problem u nas je to, ze su strasne vysoke fin. zdroje, a maju sa “nejako” do urciteho datumu minut.
To je zadanie. Potom klasika: Pride IT firma a vymysli projekt co by akoze urobila za x milionov. Nastavia sa servisne zmluvy a tym padom su vsetci zodpovedni happy…
Co sa tyka failov tak je to hlavne v ludskych zdrojoch zo strany dodavatela.
Suhlas, len by som doplnil: nemoznost ziskat data z inych zdrojov (aj ked sa vie, ze tam su).
Teda nemoznost integracie s uz existujucimi systemami. Na toto sa par rokov dozadu vobec nemyslelo.
Aky je terajsi stav neviem.
Presne … mame xy stotisic a je treba ich do konca roku minut … v podstate nikoho nezaujima ako … A peniaze nik nevrati … lebo o rok by mi znizili rozpocet … 
Ale pozor aj na zapade failnu projekty a je ich podla mna omnoho vac ako si myslime … Robil som v obrovskej nadnarodnej korporaci … videl som aj za hranice 
ja rozdiel vidim v tom, ze “FAIL” je v zahranici nejak definovany (napr. nenaplni sa business case) a ked sa to stane, tak sa na to niekto aj pozrie a napise, preco to padlo a je tam snaha to zmenit. U nas je FAIL az vtedy, ked je to brutalny fail.
S pokorou, na zaklade vlastnych skusenosti:
Dovod 1: Japonec (Dajako Sato) nevyriesi hmliste aspekty projektov. Zda sa mi ze na Slovensku ked manazer uvidi rozpocet niekolko milionov Eur tak ma pocit ze zato je jeho firma schopny postavit aj lietadlovu lod. Potom sa ukaze ze nie je schopny. Ukaze sa ze nema ani know-how ani ludske zdroje pre doriesenie funkcionalit ktore su mu od sameho zaciatku nejasne.
Dovod 2: Efekt zubnej pasty (prvy tyzden sa pouzije 75% a 25% ostane na dalsie 3 tyzdne). Na zaciatku projektov sa casto naverbuju do projektovych timov ludia ktori sa v problematike nevyznaju. Hovori sa ze ved sa naucia. Lenze v skutocnosti je vysledok ich prace nepouzitelny. Navyse prave v skorych fazach projektov sa vytvaraju strategicke dokumenty ako biznis analyzi ktore potom bud musia byt prerobene alebo vedu k mega-implementaciam a teda k IT projektom bez konca.
Dovod 3: Rizika su neprijemne tak si ich radsej nevsimame alebo ututlame. Casto vieme o casovanych bombach ale ignorujeme ich aby sme dostali zaplatene za milestone. Navyse pri dlhotrvajucich projektoch sa casto menia zodpovedne osoby a tak sa kostlivci nechaju nastupcovi.
Dovod 4: Projekty sa niekedy jednoducho nevydaria ani ked dodrzime vsetky zasady. Podla mna kazdi skuseny projektovy manazer alebo podnikatel ma za sebou niekolko neuspesnych projektov. Takze neuspech projektov by sa nemal apriori kriminalizovat.
Samozrejme ze tych dovodov je viac ale mne napadli tie. A to sa netyka len public projektov.
Suhlas. V tomto ja vidim velku vyhodu Proof of Concept, alebo Alpha, ked chceme podla Agile. V SR sa az na par vynimiek nerobia, ale v UK je to v publicu bezna prax. Zasada: “qualify hard, fail early”
Ja by som s tym suhlasil vsetkymi desiatimi ale neviem ako by sa dal robit “agile” project popri zakonoch o VO na Slovensku kedze agile predpoklada kontinualne prisposobenie obsahu podla narastu vedomosti o problematike ktorej sa venuje dany projekt. Slovenske zakony o verejnom obstaravani ale maju tendenciu robit z pociatocneho scope svate pismo a asi nie nahodou.
ale pokial sa nevydaria, tak treba vratit peniaze, aby zostalo na ine projekty, ktore sa vydaria. Ci?
Toto je asi nateraz najvacsi problem. Uradnik, ktori vystudoval FTVS alebo pedagogiku asi velmi fundovane nebude vediet ohodnotit projektovu dokumentaciu po odbornej alebo akejkolvekm inej stranke (ak neratame tie byrokraticke nezmysly, ktore im su diktovane zo Systemu riadenia, ci Prirucky pre ziadatela) stranke. Cize ak ho presvedci sikovny obchodnik/PM dodavatela a este ktomu dostane prikaz z hora, tak jediny kontrolny mechanizmus kvality(Quality) je neucinny. A ako xce resp. moze odkontrovat, ci nebodaj riadit cenu(Price) a harmonogram (Timescale).
A to len k Projektovemu riadeniu…
Presne k teme profesionalizacie statnej spravy v pblasti IT mame tuto temu: Profesionalizácia IT rolí na strane štátu
Ak chceme niečo zmeniť, tak ja by som tu videl veľký potenciál. Možnosť rozdeliť veľké projekty na malé časti, ktoré majú logický zmysel by veľmi pomohlo. Okrem iného by sa aj lahšie plánovali kapacity a menili prority. A ak zlyhá malý projekt, nie je až taký problém to priznať. Zlyhanie veľkého projektu nie je možné pripustiť. A to ani v komerčnej sfére. Skvelý príklad je Tatrabanka a použitie flash technológie.