7 factori pentru eșecul garantat

Nu apreciați angajații, nu subestimați complexitatea și nu vă bazați pe mituri. Dacă acești factori și alți factori sunt luați în considerare, proiectul dumneavoastră este garantat să eșueze.

Știi că? Timp de săptămâni și luni, managerul de proiect raportează despre proiectul său. Desigur, clasicele lămpi de stare nu trebuie să lipsească. Și asta este constant pe verde: totul ok. Dar într-o zi semaforul se schimbă brusc în roșu! În consecință, începe un proces de prelucrare foarte neplăcut pentru cei responsabili. De cele mai multe ori prima întrebare se aplică vinovatului, a doua cauzelor, iar apoi una este dedicată doar posibilelor soluții.

Mai jos sunt 7 factori tipici care aproape garantează eșecul.

Factorul 1: ignora factorul uman

În mulți ani ca dezvoltator, manager de proiect, coach și manager de criză, am constatat că tensiunile interpersonale sunt cel mai mare obstacol în implementarea proiectelor IT. În schimb, chimia dintre angajați este corectă și există un climat deschis, tolerant la greșeli, pot fi găsite soluții pentru toate dificultățile – chiar și în situații critice.

Este în natura omului să evite conflictele. Și așa este firesc dacă oamenii (de exemplu, managerul de proiect) ignoră complet sau privesc în altă parte pentru prea mult timp. Dar conflictele de obicei nu se dizolvă de la sine. Cercetarea este necesară, ca moderație și măcar perspectiva asupra schimbării sau soluției.

Uneori lucrurile mici au un impact mare, cum ar fi un nou loc de muncă pentru un angajat. Cu toate acestea, sunt adesea necesare cheltuieli mai mari, cum ar fi reorganizarea echipelor, pentru a aduce din nou pace în proiect. Cu toate acestea, cea mai proastă alternativă este ignorarea factorului uman.

Factorul 2: Gândește prea mare sau fă prea mic

Unele companii preiau un proiect. Ei subestimează complexitatea, riscurile și efortul imens de personal și material. Este – indiferent de costuri – organizația mea chiar capabilă să gestioneze un proiect cu 100 de angajați? Avem suficiente locuri de muncă, săli de ședințe, capacitate de rețea, server de dezvoltare etc.?

Este compania capabilă să îndeplinească cerințele unei echipe mari de dezvoltare agilă pentru o pistă de dezvoltare și testare, inclusiv integrare/livrare continuă? Prevăzut astfel de întrebări, cazul de afaceri ar fi trebuit să fie calculat în mod realist. Am văzut de mai multe ori că a devenit clar cu puțin timp înainte de începerea unui proiect gigantic că sistemul rezultat de fapt nu era necesar, deoarece nu se încadra în modelul de afaceri al companiei. Din păcate, nimeni nu observase asta înainte.

Un alt tipar de recunoscut: un protagonist dorește absolut să realizeze un SW, de exemplu din motive de prestigiu sau pentru a utiliza angajați, și calculează costurile ca fiind neglijabile. Dacă managerul de proiect ulterior nu este suficient de puternic pentru a prezenta discrepanța în contextul organelor de decizie, acest lucru creează un potențial de criză ridicat.

Factorul 3: bazați-vă 100% pe estimări și planificare

Un mit larg răspândit este fiabilitatea estimărilor și a planificării. Conceptul de proiect este definit de unicitatea acestuia. Poate că au existat deja proiecte similare, dar, în principiu, o companie intră pe un teritoriu nou cu fiecare proiect. Aceasta înseamnă că estimările pot fi doar la fel de bune ca experiențele creatorilor și abilitățile lor de adaptare la proiectul curent.

Cu toate acestea, planurile nu pot include niciodată evenimente spontane, schimbări în ceea ce privește cerințele, tehnologiile sau intrarea unor riscuri neașteptate. În cele din urmă, estimările și planurile bazate pe ele nu sunt altceva decât un pariu pe viitor! Acceptarea acestui fapt este un prim pas înainte. Disciplina, curajul și sistemul ajută la prevenirea sau ameliorarea posibilelor crize.

Factorul 4: Triunghiul magic PM a fost ignorat în mod constant

Studii de informatică, semestrul I, managementul proiectului primului curs: „Triunghiul magic PM“ . Persoana interesată de sarcinile de conducere este introdusă în legile acestui triunghi foarte devreme. Acestea spun că modificarea unuia dintre cei trei parametri duce inevitabil la consecințele a cel puțin unuia dintre ceilalți parametri.

Cu toate acestea, aceste legi sunt prea fericite să le ignore în practică. După cum sa menționat deja în contextul estimării și planificării, un proiect este oarecum unic și probabilitatea unor influențe neplanificate este excepțional de mare. De aceea, mai devreme sau mai târziu este necesar pentru aproape fiecare proiect ca responsabilii să reacționeze la aceste influențe. Cu toate acestea, dacă toți parametrii sunt fixați, adică clientul continuă să ceară respectarea timpului, bugetului și conținutului, eșecul este doar o chestiune de timp.

Factorul 5: Documentarea tuturor

Liber după Franz Beckenbauer: „Numim asta un clasic!” Deși din ce în ce mai multe companii se bazează pe proceduri agile (în mare parte scrum), se găsesc în continuare organizații și proiecte, care acordă documentației extinse o importanță mai mare decât software-ului care urmează să fie creat. Acesta este un risc ridicat, mai ales în proiectele mari. Adesea, o vânătoare a consultanților și experților din departamente pe mii de pagini a funcționat adesea luni sau chiar ani, care vor fi ulterior traduse de o altă echipă din SW.

Cu cât documentația este mai extinsă, cu atât timpul de realizare este mai lung și cu atât este mai puțin probabil ca SW-ul să corespundă cerințelor reale ale utilizatorilor. Reacțiile la schimbările de pe piață nu sunt posibile sau numai posibile cu mare efort și concesii temporale. Un document oferă o bază pe baza căreia produsul poate fi îndepărtat. Din păcate, ceea ce este scris nu este neapărat clar și rezultatul este gândit diferit decât se credea inițial. De câte ori am auzit propoziția de la personalul departamentului și utilizatorii finali: „Oh, mi-am imaginat-o foarte diferit!” .

Factorul 6: Doar nu există o organizare echilibrată a proiectului

O echipă de 20 de dezvoltatori și un contact tehnic? Nu este nevoie de cunoștințe de specialitate pentru a recunoaște că acest construct va eșua mai devreme sau mai târziu. La începutul unui proiect, fie că este o cascadă sau agil, acesta poate funcționa în continuare, deoarece dezvoltatorii sunt ocupați cu cadrele sau cu configurarea mediilor. Dar foarte curând angajații vor pune întrebări – au nevoie de sprijin profesional intensiv.

Un singur expert în subiect nu poate rezista niciodată acestei presiuni temporale și emoționale și necesită sprijin, atât din punct de vedere al personalului, cât și prin procesul de implementare. Cu toate acestea, este o idee foarte proastă să contracarăm blocajul personalului prin restricția comunicării.

De asemenea, o idee populară și foarte frontală la scara erorilor tipice de management: un angajat colectează întrebările dezvoltatorilor, le discută cu persoana de contact tehnică și returnează răspunsurile. În acest fel, creezi un blocaj prin excelență, declanșezi o rată de eroare extrem de ridicată și întârzi semnificativ dezvoltarea.

Factorul 7: Încinge broasca încet

Știi povestea asta? Daca pui o broasca intr-o cratita cu apa si o incalzesti continuu pana la fiert, broasca nu incearca sa scape. Dacă îl arunci direct în apă fierbinte, sare imediat.

Una dintre cele mai importante cunoștințe despre mine în ultimii ani este că angajații proiectelor IT expiră odată cu creșterea duratei orbirii. Procesele odată stabilite sunt probabil puse la îndoială în retrospective, dar rareori sunt cu adevărat drastice. Capacitatea oamenilor de a reacționa la schimbări dispare proporțional cu durata unui proiect.

Prin urmare, iluminarea sporadă (Controale de sănătate) este recomandată de proiecte (uriașe) ale unui consultant extern, neimplicat anterior, pentru a descoperi căile leak out, potențial nețintite. Cel mai târziu după recunoașterea unei crize în plină desfășurare, este aproape imposibil să creăm o redresare numai cu personalul existent.

Deci poate fi posibil

Erorile tipice de management descrise sunt doar o mică selecție a listei mele personale de succese a tiparelor de comportament, care împiedică sau chiar împiedică finalizarea cu succes a proiectelor de dezvoltare SW. De la distanță, ar putea apărea impresia că este ușor să recunoașteți problemele și să le corectați în primele etape ale proiectelor. Dar condițiile-cadru presupuse imobile și orbirea menționată fac adesea dificilă luarea deciziilor corecte. Statisticile Grupului Standish spuse la început demonstrează acest lucru an de an.

Dacă un proiect este în dificultate, se recomandă insistent ca un manager de criză extern să poată analiza și acționa obiectiv, lipsit de sensibilități și fără balastul istoricului proiectului. Singura participare a unui expert care ascultă oamenii în proiect poate provoca deja efecte pozitive. Selectarea măsurilor potrivite reușește și transformarea și, în final, răsturnarea.