Se știe că un procent semnificativ din inițiativele lansate pentru dezvoltarea și implementarea soluțiilor informaționale nu sunt implementate cu succes. Motivele pentru aceasta sunt diferite - multe publicații le analizează și derivă reguli, respectarea cărora reduce riscul de eșec. Autorii acestui articol consideră subiectul mai neconvențional - se concentrează pe consecințele proiectelor IT eșuate și modul în care participanții lor depășesc astfel de situații.

Dan Harris lucrează acum la Computer Sciences în calitate de șef al programului internațional United Technology, dar își amintește încă marele sentiment de pierdere care l-a adus să oprească un proiect în urmă cu 20 de ani. Harris a fost implicat atunci în dezvoltarea de software pentru localizatoare acustice controlate de sisteme de rachete. Software-ul pe care l-a creat s-a bazat pe modele matematice complexe și algoritmi inovatori. Dan a fost scufundat în munca sa, ceea ce i-a adus adevărată plăcere. Dar 1990 s-a dovedit a fi un an prost pentru industria militară. Războiul Rece s-a încheiat, iar reducerea amenințărilor înseamnă reducerea bugetelor și, ca rezultat, închiderea multor proiecte, inclusiv la cel la care lucra Harris.
"Am fost deprimat. Fără entuziasmul de a lucra la proiect, am simțit că am pierdut o parte din mine", a spus Harris. Deosebit de dureros a fost faptul că toată munca și efortul depus de el și de echipa sa au fost pur și simplu aruncate ca fiind complet inutile.
Suspendarea proiectului și starea industriei în ansamblu l-au forțat pe Harris să caute realizarea în afara industriei militare și a început să dezvolte software în scopuri comerciale.

Emoțiile contează
Desigur, este dificil să observăm cu pasiune cât timp proiectele tehnologice serioase sunt distruse pe nedrept sau cum soluțiile dezvoltate sunt implementate neterminate și este foarte puțin necesar pentru a elimina defectele care compromit munca creatorilor lor.
„Plăcerea muncii vine atunci când produsul tău funcționează, când vezi că utilizatorii îl folosesc. Și ce te-ai simți dacă ai lucra la un proiect timp de 19 luni, iar în ultimele 6 dintre ele săptămâna ta de lucru a fost de 80 de ore și știi că după 6 săptămâni începe proiectul și brusc este oprit? ", spune Ken Corles, directorul" Enterprise Application Development "la Accenture. Experiența sa extinsă include o situație similară.

Admiterea greșelilor
Când Sharon Gittle a condus un departament IT la o firmă de avocatură, a aprobat un upgrade la rețeaua locală. Soluția a inclus câteva tehnologii complet noi, administratorul de rețea a fost pasionat de ele și a susținut cu entuziasm proiectul. Cu toate acestea, echipamentul nu a funcționat - au existat eșecuri constante ale rețelei. "După o lună de încercări de stabilizare a noii rețele și după ce avocații au fost gata să arunce personalul IT pe fereastră, am decis să punem capăt acestui proiect", a spus Jittle. Se simțea de parcă ar fi trebuit să „se sinucidă cu propria sabie”. Ea a spus conducerii că departamentul IT a făcut o greșeală în alegerea unei tehnologii sub-testate pe care să o implementeze. Compania care a furnizat echipamentul a înlocuit-o cu una care nu utilizează tehnologii avansate. Acest lucru s-a întâmplat fără costuri suplimentare. Administratorul de rețea a fost retrogradat și ulterior a părăsit compania.

Deși atmosfera din departamentul IT în timpul proiectului a fost cumplită, după ce a fost oprit, lucrurile au revenit rapid la normal. Colaboratorii au fost mulțumiți că există o rețea care funcționează. Comportamentul deschis al lui Sharon Gittle a contribuit foarte mult la relaxarea tensiunii.

Metoda „desprinderea tencuielii adezive”
Corles al Aclesure este, de asemenea, un susținător al abordării directe de rezolvare a problemelor pe care Gitell o aplică. El crede că directorii IT vor face tot posibilul pentru angajații lor dacă vor scăpa rapid și direct de proiectele „moarte”. „Trage autocolantul - spune-le oamenilor direct cum stau lucrurile”, sfătuiește el. Potrivit lui Corles, nu ar trebui să mutați responsabilitatea în altă parte spunând ceva de genul „Nu aș opri proiectul, dar inginerul șef insistă”. Dacă faceți acest lucru, atunci nu vă considerați parte a echipei de management și pierdeți ocazia de a construi o relație de încredere cu echipa dumneavoastră.
Pe de altă parte, managerii trebuie să respecte sentimentele colegilor după ce un proiect eșuează. „S-ar putea să fiți copleșiți de indignare, pentru că cel puțin la început oamenii nu sunt capabili să gândească în mod obiectiv”, avertizează Jim Donson, președintele The Standish Group, compania care realizează ancheta anuală a proiectelor IT eșuate CHAOS.
Donson îi sfătuiește pe managerii IT să aștepte aproximativ o săptămână, apoi să discute cu angajații și să încerce să evalueze împreună cu ei de ce proiectul nu a mers conform planului. Pe de altă parte, această conversație nu trebuie întârziată prea mult.

În cele din urmă
CIO nu trebuie să uite că, din cauza nevoii de a învăța ceva nou, oamenii evoluează. Pentru colaboratorii care sunt supărați de proiectul eșuat, cel mai bun mijloc de recuperare este o nouă inițiativă interesantă și semnificativă. Managerii înțelepți ar trebui să le reamintească colegilor lor de muncă că vor exista și alte proiecte și că, chiar și din cele eșuate, pot fi învățate lecții valoroase. „Aceste proiecte vă vor învăța să vă adaptați, să faceți față frustrării, lipsa resurselor etc.”, a spus Corles. Eșecul proiectului este un eveniment posibil și deloc vesel, dar nu împiedică neapărat dezvoltarea profesională a specialistului IT.

Articolul original „Când fondatorul proiectelor IT, emoțiile se ridică” a fost publicat pe Computerworld.com.

În număr

eșuează

Înregistrați-vă și obțineți acces la cele mai noi știri și tendințe din lumea tehnologiei din țara noastră