Toți sunt profesioniști, toată lumea vrea ca proiectul să reușească, dar undeva dinamica nu funcționează. Costul ăsta invizibil – timp pierdut în fricțiuni, decizii amânate, implementări refăcute – poate adăuga 40-60% la durata proiectului și 30-50% la buget. Nu din cauza competenței tehnice, ci din cauza dinamicii umane care nu a fost pusă la punct de la început.
Pentru IMM-uri (50-200 angajați) unde de obicei ai 1-3 persoane IT care se ocupă de tot, dinamica asta e și mai critică – nu ai bufferul unei echipe mari care să absoarbă fricțiunile, fiecare persoană contează enorm.
Acest ghid îți arată exact cum să previi complet problema, cu framework operațional pe care îl poți aplica de la următorul proiect.
Anatomia conflictului: de ce apare rezistența
Înainte să vorbim despre soluții, trebuie să înțelegem de ce apare problema. Nu e capriciu și nici sabotaj intenționat, e o dinamică umană predictibilă când interesele și temerile nu sunt adresate explicit.
Când anunți că vine consultant extern, în capul IT-istului pornesc imediat câteva scenarii posibile, toate cu potențial de a-i afecta poziția sau liniștea: o să fiu judecat pentru ce nu am rezolvat? O să rămân cu responsabilitatea pentru sisteme pe care nu le înțeleg complet? Cineva va asculta ce știu eu despre realitățile de aici?
Tu ca director aduci consultant pentru că ai nevoie de expertiză specializată pe care nu o ai intern, sau pentru că vrei o perspectivă obiectivă din afară. Intențiile tale sunt bune și logice. Problema e că dacă nu comunici explicit motivația asta și nu clarifici rolurile de la început, IT-istul completează singur golurile cu propriile temeri.
Câteva situații se repetă des când dinamica nu e pusă la punct de la început: decizia se anunță fără context detaliat, IT-istul interpretează asta ca semn că ceva nu a funcționat bine, devine rezervat, îngreunează accesul la informații. Sau consultantul vine cu atitudine superioară, minimalizează contribuția IT-istului, IT-istul se retrage.
Framework complet pentru director
Acum partea practică: ce faci concret pentru a preveni toate problemele de mai sus. Framework-ul are 6 faze distincte, fiecare cu pași specifici și un outcome măsurabil.
Faza 0: Pregătirea terenului (înainte să aduci consultantul)
Majoritatea directorilor sar peste faza asta și de aici pornesc toate problemele. Nu anunți decizia luată, ci ai o conversație onestă cu IT-istul despre ce observi, ce crezi că ar ajuta și ce rol ar avea un consultant extern.
Conversația specifică sună cam așa: “Am observat că ne luptăm cu conformarea NIS2 de câteva luni, documentația e complexă și schimbă des. Mă gândesc să aduc un consultant specializat pe NIS2 care să ne ghideze prin proces și să ne ajute să punem sistemele la punct. Vreau să știu de la tine – ce crezi că ar ajuta cel mai mult? Unde simți că ai nevoie de suport? Ce te-ar face să te simți confortabil cu un consultant extern?”
Ce e important în conversația asta: întrebi, nu anunți. Asculți răspunsul. Poate IT-istul îți spune că ar avea nevoie mai degrabă de training decât de consultant, sau că problema e lipsa de timp nu lipsa de cunoștințe. Poate are dreptate și economisești bani. Poate nu are dreptate dar măcar a fost ascultat și va fi mult mai deschis la ideea de consultant pentru că și-a exprimat părerile.
Așteptări clare de la început înseamnă să spui explicit ce vrei să se întâmple și ce nu vrei să se întâmple. “Vreau să fim conformi NIS2 și să avem sistemele documentate corect, nu vreau să schimb echipa internă sau să evaluez performanța cuiva. Consultantul vine să completeze expertiza ta în zona asta specifică, tu rămâi owner pe infrastructura zilnică.”
Matricea responsabilităților
Zona gri ucide colaborarea. Fiecare trebuie să știe exact ce face, ce decide și unde are ownership. Matricea se pune pe hârtie și se distribuie tuturor înainte de prima întâlnire.
IT Intern
- Menține infrastructura existentă zilnic
- Implementează modificările aprobate
- Oferă context operațional și knowledge despre sisteme
- Testează soluțiile propuse în mediul real
- Oferă feedback despre ce funcționează și ce nu
- Prioritizarea task-urilor zilnice operaționale
- Implementarea specifică tehnică (ce tool/metodă folosește)
- Modificări minore care nu afectează arhitectura generală
- Stabilitatea operațională zilnică
- Relația cu utilizatorii interni
- Knowledge despre procese și limitări specifice companiei
Consultant
- Evaluează situația curentă și identifică gaps
- Propune soluții bazate pe best practices și experiență
- Documentează procesele și recomandările
- Transferă cunoștințe către echipa internă
- Suportă implementarea în fazele complexe
- Recomandări tehnice pentru arhitectură și soluții
- Propuneri de procese și politici
- Timeline-uri și prioritizare la nivel de proiect
- Calitatea recomandărilor și documentației
- Transferul efectiv de cunoștințe către echipa internă
- Respectarea timeline-ului proiectului
Director
- Clarificarea obiectivelor de business și priorităților
- Alocare buget și resurse
- Arbitraj final în dezacorduri majore
- Protejarea colaborării și medierea când e nevoie
- Buget și scope proiect
- Alegerea consultantului (cu input de la IT intern)
- Aprobarea recomandărilor majore care afectează business
- Rezultatul final business al proiectului
- Relația dintre IT intern și consultant
- Alocarea corectă a resurselor
Zona gri eliminată:
- Cine decide când ceva nu e clar? Consultantul propune, IT-istul oferă feedback despre fezabilitate, directorul decide final dacă e un dezacord major.
- Cine răspunde când vine întrebare tehnică de la utilizator în timpul proiectului? IT-istul rămâne first point of contact, consultantul e backup dacă e necesar.
- Cine implementează efectiv? Depinde de complexitate – consultantul face setup-ul inițial pentru lucruri noi și complexe, IT-istul preia apoi mentenanța, ambii lucrează împreună la implementare.
Procesul de onboarding (pași 1-7)
Pasul 1: Conversația de pregătire cu IT-istul (înainte să vină consultantul)
Ai avut-o în Faza 0, acum o reiei pentru a confirma înțelegerea și a clarifica orice nelămuriri care au apărut între timp. Întrebi explicit: “Mai ai întrebări despre de ce facem asta sau ce rol ai tu vs ce rol are consultantul?”
Pasul 2: Alegerea consultantului împreună cu IT-istul
- IT-istul participă la cel puțin o întâlnire cu consultantul potențial
- Pune întrebări tehnice, verifică dacă tonul și atitudinea sunt potrivite
- Nu trebuie să aibă veto total, dar votul lui contează
- Dacă IT-istul semnalează red flags clare despre atitudinea consultantului, asculți
Pasul 3: Prima întâlnire (director + IT-ist + consultant)
- Cine participă: toți trei
- Agenda: director explică contextul și obiectivele, prezintă matricea responsabilităților, întreabă pe fiecare ce așteptări are și ce îi trebuie pentru a reuși
- Outcome: toată lumea înțelege clar ce face fiecare, consultantul și IT-istul schimbă contacte directe și programează prima lor discuție tehnică fără director în ședință
Pasul 4: Prima săptămână – knowledge transfer de la IT la consultant
Consultantul petrece timp cu IT-istul învățând despre sisteme, procese, limitări, istorie. Consultantul pune întrebări, nu judecă. IT-istul oferă informații, nu se apără. Dacă vezi că IT-istul e defensiv sau consultantul e condescendent, oprești și reiei conversația despre așteptări și respect.
Pasul 5: Primul proiect pilot (2-3 săptămâni)
Nu începi cu implementarea completă, începi cu un proiect mic și delimitat unde consultantul și IT-istul lucrează împreună la ceva concret. Scopul nu e doar să livrezi rezultatul tehnic, ci să testezi dacă colaborarea funcționează. Dacă merge bine, scalezi. Dacă nu merge, ai timp să repari dinamica înainte să investești masiv.
Pasul 6: Review după 30 zile (director + IT-ist + consultant)
- Agenda: ce a mers bine, ce nu a mers, ce trebuie ajustat în proces sau comunicare
- Fiecare spune deschis, fără acuzații
- Director facilitează conversația și ia acțiune pe ce trebuie schimbat
- Dacă nu faci review-ul ăsta, problemele mici devin mari fără să îți dai seama
Pasul 7: Cadență stabilită de colaborare
După primele 30 zile stabiliți cadența constantă:
- Întâlniri săptămânale consultant-IT pentru sincronizare tehnică
- Întâlniri bi-săptămânale toți trei pentru status și decizii
- Acces direct între consultant și IT fără să trebuiască să treacă totul prin director
Protocoale de comunicare operaționale
Cine raportează cui și când: Consultantul raportează progres tehnic către IT-ist săptămânal și către director bi-săptămânal. IT-istul raportează directorului despre cum merge colaborarea și dacă are îngrijorări. Directorul nu ocolește IT-istul pentru informații tehnice (îl întreabă mai întâi pe IT-ist).
Cum se iau deciziile tehnice vs business: Decizii tehnice (ce tool folosim, cum implementăm ceva) se iau între consultant și IT-ist, cu consultantul propunând și IT-istul validând fezabilitatea. Directorul e informat despre decizie, nu ia decizia. Deciziile de business (buget, prioritizare macro, schimbări de scope) le ia directorul cu input de la ambii.
Cum se gestionează dezacordurile: Dezacord tehnic între consultant și IT-ist? Consultantul și IT-istul discută mai întâi direct, fiecare prezintă argumentele, încearcă să ajungă la consens. Dacă nu ajung la consens în 2 zile, escaladează la director cu ambele perspective prezentate clar. Directorul ascultă ambele părți, pune întrebări, decide final sau cere a treia opinie dacă e necesar.
Red flags și intervenții
Trebuie să recunoști rapid când ceva nu merge și să intervii înainte să se degradeze complet.
Red flags consultant:
- Tonul condescendent constant față de IT-ist (“așa se face la corporații mari, nu la voi”)
- Ocolește IT-istul și vine direct la tine pentru orice
- Minimalizează contribuțiile IT-istului (“nu prea știe despre asta”)
- Pune vina pe IT-ist când ceva nu merge (“nu am primit informațiile necesare la timp”)
- Nu documentează sau explică deciziile tehnice
Intervenție: Conversație directă cu consultantul despre așteptări și respect, dacă nu se schimbă comportamentul în 2 săptămâni, termini contractul. Nu are sens să plătești pe cineva care deteriorează dinamica echipei tale.
Red flags IT-ist:
- Răspunsuri extrem de scurte la întrebări
- Întârzieri constante la livrarea informațiilor solicitate
- “Uită” să menționeze lucruri importante
- Critică constantă fără alternative constructive
- “Am încercat dar nu merge” fără explicații detaliate de ce
Intervenție: Conversație privată cu IT-istul despre ce îl deranjează cu adevărat, poate are temeri legitime pe care nu le-a exprimat. Reasigurare despre poziția lui și clarificare despre scopul consultantului. Dacă rezistența continuă, escaladare – fie IT-istul are informații pe care nu le împărtășește și trebuie să le scoți la iveală, fie problema e de atitudine și trebuie adresată direct.
Scenarii dificile și soluții
Teoria e una, realitatea aduce situații care nu respectă planul. Iată cum gestionezi cele mai comune scenarii dificile.
Scenariul 1: IT-istul e deja defensiv când anunți
Ai sărit peste Faza 0 sau conversația nu a fost suficient de clară, IT-istul și-a dat seama că vine consultantul și e deja închis la comunicare înainte să înceapă oficial.
Diagnostic: IT-istul a auzit ceva vag, și-a imaginat cel mai rău scenariu, s-a poziționat defensiv. Nu poți merge înainte fără să repari asta mai întâi.
Soluție: Dai 2 pași înapoi și ai conversația care ar fi trebuit să aibă loc de la început. Conversație privată cu IT-istul, recunoști că ai comunicat incomplet, explici exact de ce ai luat decizia, ce așteptări ai și ce rol are el. Nu te aperi și nu minimalizezi îngrijorările lui, le asculți și le adresezi explicit. “Văd că ești rezervat de când am menționat consultantul. Vreau să înțeleg ce te îngrijorează și să clarific intențiile pe care le am.” Apoi asculți. Poate IT-istul îți spune că se simte evaluat, poate că e îngrijorat că o să fie dat afară, poate că a mai avut experiențe proaste cu consultanți. Oricare ar fi, adresezi fiecare îngrijorare explicit și pui pe hârtie matricea responsabilităților.
Scenariul 2: Consultantul vine cu o atitudine superioară
Consultantul ales nu se potrivește dinamicii tale sau și-a schimbat atitudinea după ce a semnat contractul. Tonul e condescendent, minimalizează contribuțiile IT-istului, vrea să implementeze soluții enterprise fără să înțeleagă contextul vostru.
Diagnostic: Consultantul nu înțelege că rolul lui e să construiască capacitate internă, nu să impresioneze. Sau înțelege dar nu îi pasă.
Soluție: Conversație directă cu consultantul în prima săptămână când observi pattern-ul. “Am observat că în discuțiile cu IT-istul tonul tău e X. Așteptarea mea e ca tu să lucrezi împreună cu echipa internă, nu în locul ei. IT-istul cunoaște realitățile operaționale de aici mai bine decât tine, tu vii cu expertiză specializată. Trebuie să funcționați ca echipă.” Dacă comportamentul se repetă, o a doua conversație în care spui clar că dacă nu se schimbă atitudinea, termini contractul. Dacă se repetă a treia oară, termini contractul. Nu are sens să plătești pe cineva care deteriorează cultura echipei tale.
Metrici de succes pentru colaborare
Cum știi că colaborarea funcționează? Nu după cât de politicoși sunt în ședințe, ci după comportamente concrete:
- IT-istul pune întrebări consultantului din curiozitate, nu din obligație
- Consultantul cere input de la IT-ist înainte să facă recomandări
- Informația circulă rapid între ei fără bottleneck-uri
- Apar discuții tehnice productive unde ambii contribuie
Timeline realist: Primele 2 săptămâni sunt de acomodare, colaborarea e încă formală. Săptămâna 3-4 – prima colaborare fluidă. Luna 2 – relație stabilită, mai puțină nevoie de mediere. Luna 3+ – colaborare autonomă.
Dacă după luna 1 nu vezi semne de colaborare productivă, problema nu se va rezolva singură, trebuie intervenție.
Long-term: Tranziția de la dependență la autonomie
Consultantul nu trebuie să devină permanent, scopul e să construiască capacitate internă pe care apoi echipa ta să o mențină singură.
De la început discuți cu consultantul că scopul e transfer de cunoștințe, nu dependență. În contract pui explicit că trebuie să documenteze tot și să predea IT-istului.
Timeline-ul tranziției:
- Primele 2 luni: consultantul implementează cu IT-istul învățând
- Lunile 3-4: IT-istul implementează cu consultantul ghidând
- Lunile 5-6: IT-istul lucrează autonom, consultantul verifică
După 6-9 luni treci de la consultant full-time la on-call. În ultimele 2 luni de contract: predare completă către IT-ist – documentație, knowledge transfer, review sisteme. Consultantul rămâne disponibil pentru urgențe 3-6 luni după terminarea proiectului, la tarif on-call.
Concluzie
Colaborarea productivă IT intern – consultant extern nu e ceva ce se întâmplă de la sine, chiar dacă oamenii sunt profesioniști. E rezultatul direct al modului în care tu ca director pui bazele de la prima zi – claritate completă despre roluri și așteptări, respect pentru cunoștințele echipei interne, procese clare de comunicare și escaladare, intervenție rapidă când apar semnale că ceva nu merge.
Diferența dintre investiție valoroasă în consultanță și bani aruncați nu e cât de bun e consultantul din punct de vedere tehnic. E cât de bine funcționează ca echipă cu oamenii tăi. Și asta începe și se termină cu modul în care tu facilitezi colaborarea.