Există o diferență esențială între delegare și însărcinare. În cazul celei dintâi vom defini Input, expected Output și vom pune la dispoziție mijloacele necesare (resurse și responsabilitate). Cea de a doua este o simplă cerință, enunțată ca atare. O condiție esențială şi care trebuie să stea la baza delegării este încrederea. De aceea trebuie să urmărim în permanenţă crearea şi menţinerea încrederii în relaţiile de lucru la orice nivel. Într-un mediu de lucru în care suspiciunea predomină, delegarea devine aproape imposibilă.

Să luăm ca exemplu o întârziere apărută într-un proiect, care trebuie comunicată clientului, cu care trebuie în același timp agreat un nou deadline. Aceasta înseamnă că: trebuie să facem clientul să înțeleagă și să accepte motivele întârzierii și să accepte noul deadline. O delegare corectă a acestei activități presupune:

• Descrierea premizelor (motivele și urmările întârzierii, relațiile cu clientul etc.),
• Descrierea rezultatului așteptat și a orizontului de timp aflat la dispoziție (clientul înțelege motivele amânării și este de acord cu noul deadline, fiind informat asupra urmărilor acestei decizii- toate acestea în următoarele 2 săptămâni),
• Predarea deciziei și controlului asupra:
• Canalului și conținutului comunicării,
• Structurii comunicării (pași, persoane implicate),
• Controlul asupra resurselor materiale și personale necesare îndeplinirii tuturor activităților.

Nici chiar o activitate de complexitate medie nu poate fi condusă/managerizată fără a delega în mod corect părți ale acesteia. În cazul activităților complexe, lipsa delegării sau delegarea incorectă duce inevitabil la haos. De obicei, dificultăţile în actul delegării sunt un indicator sigur al unor probleme de încredere. Ale Manager-ului în colegii săi sau în sine (cele două feluri de neîncredere sunt interconectate). Putem spune că aceste dificultăţi, atunci când apar, reprezintă un dezechilibru important în funcţionarea echipei care, neadresate au evident tendinţa de a creşte.

De aceea cred că cea mai bună idee în acest caz este prevenţia, cu ajutorul uneltei numite … încredere.

Dar ce înseamnă mai exact comunicarea și atitudinea pozitivă în Management?

Pe scurt, în Management comunicarea pozitivă înseamnă transmiterea verbală și afectivă a încrederii, siguranței dar și disponibilității spre argumentare constructivă și compromis.

Mai întâi de toate este însă datoria omului civilizat faţă de alt om civilizat de a nu-i transfera energia sa negativă, frustrarea, nemulţumirea, teama. Este un nivel mai înalt de bun simţ care ne învaţă să păstrăm aceste energii negative pentru noi, din respect pentru ceilalţi.

Este de asemenea un semn de respect de sine, căci la baza calităţii comunicării nu stă doar educaţia, ci mai ales o anumită atitudine, de învingător sau dimpotrivă, de învins vizavi de viaţă, muncă, noi înşine sau ceilalţi. Dacă simţim încredere în noi şi în ceilalţi, dacă suntem mândri de ceea ce am făcut şi încrezători în rezultatele viitoare, dacă ne simţim acceptaţi şi apreciaţi pentru ceea ce facem, atunci munca noastră este un adevărat succes profesional şi chiar personal. Şi asta se vede, indiferent ce am comunica, limbajul nonverbal va spune aceste lucruri despre noi.

Dincolo de aspectele legate de atitudine, este important să înţelegem că trebuie să privim comunicarea ca pe un mijloc de a ne atinge obiectivele, ceea ce înseamnă că nu putem lăsa comunicarea la voia întâmplării, nu putem să o lăsăm ne-controlată, ne-direcţionată. Dacă nu controlăm noi comunicarea o va face partenerul nostru. În Management nu prea există comunicare liberă, unul din parteneri controlează mereu comunicarea, bi- sau multilaterală. Ca Manageri am fost cu toţii puşi în poziţia de a modera o discuţie, o întâlnire, o prezentare. În poziţia de moderator suntem obligaţi să controlăm comunicarea. Putem folosi această poziție ori de câte ori vrem să controlăm comunicarea.

Un aspect sensibil este acela al sincerității / falsității. O atitudine falsă este imediat percepută de interlocutori, iar comunicarea își pierde credibilitatea. Dacă, dintr-un motiv sau altul nu putem menține atitudinea tonică, este cert preferabil să întrerupem comunicarea, să facem o pauză de regăsire, în loc să ne lăsăm cuprinși de negativitate, deci de slăbiciune.

Pentru a putea conduce și convinge, motiva și inspira, negocia, vinde, împinge și învinge un leader trebuie să aibă exercițiul comunicării pozitive și al atitudinii tonice, trebuie în orice situație să inspire mai mult decât să reacționeze. Iar un Manager, orice Manager trebuie să fie un leader.

Un manager nu este neapărat un conducător, iar un conducător nu este automat un manager. « Conducerea » se concentrează pe a face ceea ce trebuie făcut, deci pe efectivitate. « Managementul » se concentrează pe a face cum trebuie, deci pe eficiență. Amândouă aceste roluri trebuie să coexiste și să se completeze. Conducerea și Managementul se răsfrâng în mod complet diferit în Project Management, iar un proiect are nevoie în derularea lui uneori de o doza mai mare de conducere, alteori de o doza mai mare de management – dar întotdeauna în prezența celeilalte componente complementare.
Cu toate că în mod instinctiv oricine simte deosebirea dintre cele două roluri, am încercat să găsesc o definiție palpabilă a lor. Catalogarea făcută de John P. Kotter mi se pare cea mai nimerită (o traduc pe scurt, originalul găsindu-se în link-ul anterior): Managementul este componenta organizațională care face ca sistemele alcătuite din oameni și tehnologii să funcționeze bine zi de zi, săptămână de săptămână, an de an. Conducerea este componenta organizațională care creează sistemele care sunt administrate de manageri, adaptându-le astfel încât să profite de oportunități și să evite riscuri.

Cum se aplică aceasta în Project Management? Ce este Management și ce este Conducere în Project Management? Autorul Gunter Dueck grupează activitățile din cadrul unui unei companii în diverse nivele suprapuse, despărțind munca operativă de munca de (re)organizare. Interpolând aceasta în Project Management, am obține patru nivele:

Nivelul operativ: Rezultatul muncii efectuate la acest nivel reprezintă împlinirea scope-ului proiectului – aici se creează, aici se lucrează efectiv. Aici se execută fiecare componentă a WBS-ului (Work Breakdown Structure), căutând să nu se depășească timpul și bugetul alocat. Este simplu, dar nu e deloc banal – rezultatul muncii la acest nivel reprezintă valoarea pe care o creează proiectul, pentru acest rezultat (și doar pentru el) se investește în proiect, iar doar acest rezultat îl interesează de fapt pe contractorul proiectului.

Nivelul de management: Planificarea, organizarea, controlul, coordonarea și verificarea muncii operative sunt activități care aparțin nivelului de management. Pe acest nivel se pune accent pe eficientizarea muncii efective. A considera sarcinile Project Managerului încheiate la acest nivel ar reprezenta o greșeală.

Nivelul sistemic: Cele două nivele anterioare însumează munca în interiorul proiectului. Creerea, adaptarea sau modificarea proiectului în sine nu se regăsește pe nici unul dintre aceste nivele, în ele se folosește un sistem deja existent. Ca urmare, nivelul superior celui de Management trebuie să se ocupe cu modelarea proiectului. De exemplu, inițializarea unui proiect reprezintă cumulul activităților de creere a unui nou sistem-proiect – definirea structurii proiectului, a interacțiunilor cu stakeholder-ii, a proceselor folosite, a nivelului de formalism, stabilirea echipelor, etc., toate acestea definesc ramele în interiorul cărora se dezvoltă proiectul. Munca pe nivelul sistemic are o pondere mai mare la inițializarea și la încheierea proiectului, însă va exista permanent pe toată durata proiectului, dat fiind necesitatea modificării și perfecționării continue a structurii proiectului.

Nivelul de conducere: munca pe nivelul sistemic este necesară pentru a implementa viziunea celui mai bun sistem posibil pentru proiectul actual, în circumstanțele date. Definirea viziunii, precum și organizarea muncii sistemice se întâmplă la un nivel superior. Cuvântul cheie poate fi „îmbunătățire continuă”  – a sistemului, a proceselor – „continuous improvement”. Această activitate își are locul pe nivelul de conducere, care dă liniile directoare modificării sistemului-proiect spre a îndeplini dezideratul propus: un proiect care se adaptează, astfel încât să profite de oportunități și să evite riscuri.

Foarte des în proiecte se simte prezența în exces a laturii de management, de organizare și administrare riguroasă, ignorând importanța părții de conducere a proiectului. Pentru orice Project Manager componenta de conducere, de orientare, rămâne esențială. De multe ori, în proiect se pornește la lucru, fără a « pierde timpul » cu gânduri referitoare la structură, plan sau proces, Project Managerul fiind chiar implicat direct în munca efectivă și operativă. Una dintre caracteristicile acestei situații este ignorarea procesului de îmbunătățire continuă, care urmărește perfecționarea structurii proiectului. În aceste cazuri, un pas în afara sferei muncii efective, în afara nivelului administrativ, este impetuos necesar, pentru a permite PM-ului o privire de perspectivă asupra proiectului său.

Incheierea proiectului cade, deloc surprinzător, în răspunderea Project Managerului. A termina un proiect nu este considerată ca fiind o activitate plăcută. Unul dintre motive, stă de fapt în însăși funcția activității menționate – asta și gata, proiectul s-a terminat. Este ceva definitiv, existența proiectului este încheiată. De multe ori, până și găsirea punctului propice pentru o terminare sistematică a proiectului este greu de găsit: de exemplu, beneficiarii își mai permit o marjă de timp pentru a vedea cum se comportă în realitate rezultatul proiectului. Membrii echipei, pe de altă parte, sunt foarte probabil deja preluați de organizatia unui alt proiect, unde posibil ca deja a început munca – așa că la ce bun să mai pierzi timpul cu proiectul acela vechi, pe care l-am terminat deja?!

Cu toate acestea, când punctul de încheiere a fost atins, o terminare sistematică a proiectului aduce multe avantaje. Câteva dintre aceste avantaje sunt deja destul de bine cunoscute – unul dintre cele mai evidente fiind asigurarea unui cadru formal sigur pentru proiect, în momentul în care oficial acest proiect a fost încheiat. Alt aspect extrem de important este experiența acumultată de-a lungul proiectului. Dacă aceste cunoștințe, adunate de echipă de-a lungul proiectului, nu sunt făcute public în cadrul organizației proiectului, atunci pot fi considerate ca fiind practic pe jumătate pierdute, ele rămânând doar la dispoziția fostilor membrii ai echipei proiectului. Împărtășirea și arhivarea de „Lessons Learned” este extrem de importantă, ele găsindu-și loc chiar în „Manual intern de Project Management” – vezi Adoptarea Project Management-ului în companii mici și mijlocii. Un alt aspect important este modificarea nivelului motivațional al echipei, care va fi crescut în mod dramatic, în momentul în care successul unui proiect (în cazul în care acesta există) este facut public în cadrul organizației proiectului, iar membrii echipei proiectului încheiat sunt nominalizați în vreun fel. Pentru proiectul încheiat această explozie motivațională nu mai are nici o importanță, dar la nivelul organizației efectul este extrem de benefic. Responsabil pentru acest „marketing” intern este din nou Proiect Managerul, ca instanță coordinatoare. Project Managerul trebuie să se asigure, că succesul proiectului său este cunoscut, făcând prin aceasta un serviciu tuturor: în primul rând lui insuși, apoi echipei cu care a lucrat (și cu care poate va mai lucra în viitor) precum și organizatiei proiectului, vazută ca un tot unitar. În unele cazuri, chiar și beneficiarii ajung să privească rezultatele unui proiect într-o lumină mai prielnică, în momentul în care foștii membrii ai echipei vorbesc despre participarea lor in proiect cu mândrie!

Ce activități sunt uzuale în faza de încheiere a unui proiect:

1: Faza formală (administrativă) de încheiere a proiectului

• încheierea financiară a proiectului – finalizarea calculului de cheltuieli – precum și compararea acestuia cu bugetul planificat
• predarea formală spre beneficiar a rezultatelor proiectului – cuvântul formal este subliniat, pentru a-i scoate în evidență importanța. Doar o predare formală dă proiectului cadrul oficial sau chiar juridic necesar, în care să se poata încheia. Predarea trebuie să fie însoțită (în cazul în care se aplică) de rezultatele testelor de asigurare a calității, teste care au fost discutate și aprobate în prealabil de către beneficiar. În acest punct se eliberează și Project Managerul, din nou în mod formal, de responsabilitatea proiectului.
• organizația aferentă proiectului se dizolvă, iar Project Managerul evaluează performanța membrilor echipei
• infrastructura tehnică folosită în proiect se descompune

2: transferul de cunostinte

• Efectuarea unei prezentări de final, cu participarea reprezentanților organizatiei proiectului și ai beneficiarului – acest fel de prezentare este și un foarte bun instrument de marketing, de altfel.
• Crearea unui sumar al proiectului, care să folosească ca referința viitoarelor proiecte – conținând, de exemplu: tema proiectului, tehnica folosită, beneficiar, metode, cine a fost responsabil, cine a participat și în ce formă, care au fost costurile, etc.
• Încheierea documentației proiectului, inclusiv documentarea Lessons Learned
• Evaluarea reciprocă a membrilor echipei – un bun moment pentru a da, respectiv a primi, un extrem de important feedback.
• Creerea unui raport despre proiect, în care un punct important îl are analiza din punct de vedere economic a proiectului, referitoare la costuri și timp, analiza exactității  planificărilor și a estimărilor, precum și inspecția calitatății datelor măsurate și adunate pe parcursul proiectului.

Prin încheierea unui proiect se creează spațiul necesar evolutiei unui nou proiect.  Terminarea controlată este din păcate în multe cazuri sacrificată în favoarea unor noi și la prima vedere mult mai importante aspecte, care fac parte din proiectele viitoare, ingnorând faptul că cunostințele și experiența acumulată în proiectul terminat va fii benefică pentru viitor – investiția este întotdeauna răsplătită.

Intrebari	Documente necesare
Cine suntem?	Analiza Stakeholder-ilor, Analiza mediului proiectului, Organigrama proiectului, incluzând echipa, conducerea, eventuali subcocntractori sau furnizori și organizarea clientului
Ce dorim?	Analiza beneficiilor, a obiectivelor și a livrabilelor
Cum ajungem acolo?	Fazele și Milestone-urile, Matricea de comunicare
Cât ne costă?	Primele estimări cu privire la buget
Riscuri previzibile din aceasta fază	O primă analiză de risc, pornind chiar de la Analiza Stakeholder-ilor

Pentru a putea răspunde acestor întrebări trebuie să punem la dispoziția participanților, cu ceva timp înainte (de la câteva zile la câteva săptămâni) documentele menționate, într-o calitate suficientă pentru a răspunde întrebărilor din coloana stângă.

Dincolo de obiectivele formale enumerate, un Kick-Off nu poate avea succes dacă nu-și atinge scopul de motivare. Pe lângă informarea cu privire la punctele enunțate, un Kick-Off de succes va reuși să impulsioneze și să inspire, atât stakeholder-ii cât și echipa, obținând atât o motivație puternică pentru atingerea obiectivelor proiectului, cât și acceptanță pentru planul prezentat.

Într-adevăr sună totul mult mai simplu decât este. De ce? Iată câteva motive pentru care organizarea unui Kick-Off de succes este o întreprindere destul de dificilă:

• Alegerea momentului potrivit pentru organizarea Kick-Off-ului este dificilă. Dacă este organizat prea devreme, nu vom avea destule informații despre organizare, plan, riscuri pentru a putea defini proiectul într-o măsură capabilă să ofere stakeholder-ilor siguranța necesară. Pe de altă parte, dacă întârziem prea mult, se va crea o stare de tensiune, atât în rândul stakeholder-ilor, cât și al echipei, datorată în primul rând nesiguranței, a lipsei de informare și comunicare. Am făcut din păcate adesea experiența faptului că fereastra de timp de oportunitate maximă pentru organizarea unui Kick-Off este destul de restrânsă. O altă greșeală frecventă este anunțarea și programarea Kick-Off Meeting-ului de la începutul proiectului, din faza din în care nu avem habar de dificultățile pe care le vom întâmpina în planificarea și organizarea proiectului. Rezultatul poate fi dezastruos, dacă nu putem să prezentăm rezultatele enumerate mai sus, iar participanții anunțați cu mult timp înainte vor fi dezamăgiți. Atunci ședința noastră menite să unească și să motiveze participanții la proiect va rămâne la stadiul informativ.
• Alegerea participanților trebuie de asemenea făcută cu grijă. Așteptările participanților sunt de cele mai multe ori în mod esențial diferite, iar acest lucru va trebui avut în vedere. Regula aici este ca fiecare categorie de stakeholder-i să fie reprezentată în mod adecvat, adică de persoane care au capacitatea de decizie necesară, dar și timpul pentru a se implica în proiect.
• Elementul surpriză. Într-adevăr, adunând la un loc un număr de oameni care nu se cunosc, sau poate se cunosc într-un mod negativ, ale căror informații despre proiect sunt vagi și poate deformate, care sunt afectați în mod foarte diferit de rezultatele proiectului și în consecință au interese diferite, nu poate rezulta decât un eveniment foarte interesant, dar cu mult potențial explosiv.
• Factorul personal. Așteptările tuturor de la Project Manager sunt uriașe, la fel și îndoielile, chiar față de un PM experimentat și respectat. Frumusețea oricărui proiect constă în unicitatea sa, la fel de unice sunt de fiecare dată și așteptările și interesele stakeholder-ilor, chiar dacă avem de-a face cu oameni cunoscuți. Gradul în care Project Manager-ul reușește să capteze participanții și să le câștige încredea pe parcursul Kick-Off-ului va avea o influență puternică asupra atitudiniii viitoare a tuturor stakeholderi-ilor, cu atât mai mult cu cât acesta va fi poate singura ocazie de a-i întâlni personal pe unii dintre ei, mai ales pe cei foarte influenți.

Fără o pregătire minuțioasă și un dram de noroc, Kick-Off Meeting-ul are din păcate șanse mari să aibă efectul opus celui intenționat, adică să demotiveze, să transmită informații false sau incomplete și să creeze așteptări greșite. Printre cauzele cele mai frecvente de eșec se numără:

• Materiale insuficient pregătite și neconcordante, care creează mai degrabă confuzie,
• Alegerea greșită a participanților,
• prezentarea defavorabilă a proiectului sau câștigul de cauză acordat oponenților,
• chiar o zi proastă a unui Stakeholder foarte influent

Și, din păcate, sau din fericire, prima impresie atârnă foarte greu. Deci, baftă!

Ce este un stakeholder? Termenul de “stakeholder” provine din engleză: “stake” se traduce prin miză, importanță sau însemnătate. “Holder” se traduce prin deținător. Stakeholder-ul este astfel cineva, care a mizat la un joc si are interes ca acel joc să se termine într-un anume fel – partida este în cazul nostru proiectul în care suntem implicați. În terminologia de Project Management, un „stakeholder” nu se referă doar la persone, ci poate fi transferat oricărei entități, care are interes ca un proces anume – sau tot proiectul – să se desfasoare într-un anume fel și să producă un anume rezultat.

Astfel, căutând o definiție, se poate spune că, stakeholder-i ai unui proiect sunt persoane, grupuri sau organizații, care au interes în proiect, sau sunt afectați într-o oarecare măsură de acesta. Rămanând la teorie si clasificare, stakeholder-ii unui proiect se împart în două categorii: cei activi și cei pasivi. Stakeholder-ii activi sunt implicați direct în evolutia proiectului (ex. Project Managerul, echipa proiectului) sau sunt direct afectați de rezultatul sau evolutia lui (client, sponsor, subcontractori ai proiectului, furnizori). Stakeholder-ii pasivi sunt doar indirect afectați de evoluția proiectului – de ex. familia unui membru al echipei. Diferențierea între stakeholder-i activi sau pasivi ajută în primul rând procesului de identificare al acestora. După ce stakeholder-ii au fost identificați, rămâne să definim pentru fiecare caracteristicile lui vis-a-vis de proiect:

- Influența pe care o exercită asupra proiectului – cu alte cuvinte, ce putere are acest stakeholder asupra proiectului, sau a mediului proiectului – este un factor de decizie, poate influența alți stakeholderi sau are doar o părere informativă?

- Poziția față de proiect – este un promotor al proiectului, sau se opune lui? Este neutru?

- Apropierea față de proiect – cât de des are respectivul stakeholder contact cu proiectul, cât de familiar îi este?

Identificarea stakeholder-ilor și definirea importanței fiecăruia față de proiect este piatra de temelie a planului de comunicare în proiect: cine când trebuie informat, și ce fel de informație este necesară fiecăruia? Combinația dintre influența și apropierea față de proiect a unui stakeholder definește importanța respectivului pentru proiect. Din aceeași analiză a stakeholderilor rezultă și o listă de riscuri – în ce fel interacțiunea proiectului cu stakeholder-ii săi poate direcționa evoluția proiectului într-o zonă nedorită.

Într-un proiect cu care am avut contact de curând, am întâlnit o constelație de interese neobișnuită, care m-a făcut să mă gândesc la modul în care interactionează stakeholder-ii într-un proiect, la dinamica intereselor fiecăruia și la evoluția scopurilor actorilor dintr-un proiect. Situația de care vorbesc era următoarea: un audit extern impus unei companii a concluzionat că anumite norme și reglementări nu sunt respectate în cadrul unui departament X. Pentru a îndeplini cerințele normelor respective, o aplicație software, care implementa procesele departamentului X, trebuia modificată. Iar dat fiind că auditul extern a găsit nereguli și în modul în care aplicațiile software erau exploatate în compania dată, aplicația va trebui mutată și operată într-un centru de calcul extern companiei, care poate garanta o funcționare și un service performant. Se profila un șantier destul de amplu, dat fiind că funcționarea după norme a departamentului X era vitală pentru firma dată. Astfel s-au pus bazele unui proiect, care să transforme aplicația și să o introducă în centrul de operații al unui prestator de servicii extern. Sponsorul proiectului era CIO-ul companiei. După o primă analiză a stakeholder-ilor rezultă ceva de genul: începând cu membrii departamentului X în cauză – care trebuiau să își modifice modul de muncă din ziua în care aplicația lor ar fi fost modificată și dată în outsource, și trecând pe la echipa centrului de calcul propriu al companiei – care pierdea din importanță, dat fiind că pierdeau din responsabilitate – practic nimeni nu dorea acest proiect, sau mai bine spus: și-ar fi dorit să eșueze. În interiorul companiei existau puțini susținători, care doreau cu orice preț ca firma să respecte normele impuse de lege. Având un astfel de vânt potrivnic, ar fi fost foarte greu, dacă nu chiar imposibil, ca proiectul să aibă success. Înțelegând însă problemele fiecăruia, ai o șansa de schimba în mod activ poziția unui stakeholder față de proiect: în momentul în care în scopul proiectului s-au introdus elemente care – după modificarea aplicației – ar fi ușurat munca departamentului X din companie, poziția membrilor echipei departamentului s-a modificat cu 180 de grade – erau acum promotori ai proiectului. În momentul în care echipa centrului de calcul a înțeles cererile referitoare la securitate, protecția datelor, backup, reporting și multe altele, cu care ar fi fost confruntați în cazul în care aplicația rămânea în departamenul lor, au realizat că pentru a le satisface ar fi fost necesară o restructurare a departamentului – ceea ce era mult mai problematic decât un outsourcing – au devenit astfel și ei promotori ai proiectului. Situația actuală era mult mai propice proiectului decât cea inițială. Acțiunile Project Managerului au adus o evoluție pozitivă a atitudinii stakeholder-ilor față de proiect, reducând deasemenea considerabil riscurile.

Scopul principal al activităților din procesele de management al stakeholder-ilor este acela de a înregistra și înțelege necesitățile actorilor importanți care activează în mediul unui proiect, și de a ține seama de aceste necesități în planificarea și execuția proiectului. Ideea de fond este, ca obiectivele stakeholderilor și cele ale proiectului să aibă cât mai multe elemente comune. În aceste condiții, riscurile proiectului se reduc. Activitățile de stakeholder management sunt recurente pe tot parcursul proiectului.

Mediul proiectului nu trebuie privit ca fiind un spațiu abstract. Primul reflex este de multe ori de a percepe un proiect ca fiind un sistem, care are de îndeplinit o anume sarcină, într-un timp definit, încadrat intr-un buget stabilit, folosind anumite resurse, de multe ori puse la dispoziție de mediul exterior proiectului – pe scurt, un ansamblu de componente abstracte. Cu toate acestea, când te gândești la un proiect, există un aspect al acestui sistem care prinde un contur foarte bine definit: oamenii cu care ai avut de-a face în acel proiect. Oamenii care au alcătuit echipa proiectului, oamenii care au avut de-a face într-un fel sau altul cu proiectul, clienți, furnizori, oameni care erau in continuă interacțiune cu mediul proiectului și cu mediul din afara proiectului. Un proiect este de fapt un sistem social, iar oamenii sunt cei care îl definesc.

Analiza SWOT simplifică complexitatea unei probleme printr-o definire consecventă de contraste. Prin această rafinare, problema este redusă la caracteristicile definitorii, de structură. Necesitatea existenței contrastelor trebuie subliniată, pentru ca granițele dintre puncte forte si oportunități, respectiv puncte slabe și amenințări să fie respectate. Spre exemplu, când existența de reclamații este interpretată ca și amenințare din exterior si nu ca problemă internă de calitate, atunci analiza respectivă poate să nu mai fie corectă.

Analiza pornește bineînteles definind tema, scopul pentru care este necesară luarea unei decizi – spre exemplu, considerând o companie producatoare de software: Care este strategia de urmat pentru creerea de noi produse? Ideal ar fi să se listeze câteva alternative posibile, deja identificate, spre ex: concentrarea eforturilor pentru crearea de produse pentru industrie, extinderea spre noi piețe/ramuri de industrie sau îndreptarea spre utilizatori privați?

Problema trebuie analizată din cele patru puncte de vedere:

• Strengths – existența de procese inovative in companie, compania este cunoscută pe piață pentru utilizatorii din industrie
• Weaknesses – costuri de productie crescute, probleme de viteză de execuție la module destinate telefoanelor mobile
• Opportunities – posibilitatea de a creea o extensie care se adresează unor noi piețe, concurența are probleme de calitate
• Threats – apariția pe piața a unui nou produs al unei firme noi, care ar putea acoperii functionalitatea oferită deja pentru piața din industrie, posibilitatea apariției unei legi care presupune schimbări masive in construcția programelor pentru industrie.

Toți participanții trebuie să iși exprime părerea pentru fiecare dintre cele patru module SWOT. Ideile se vor alătura, construindu-se o diagramă SWOT completă.

Urmează dezvoltarea strategiei, de fapt punctul forte al analizei SWOT: factorii interni și externi se vor combina între ei derivând alternativele posibile. Există patru astfel de combinații:

• Strategia S-O: Folosind punctele forte existente in companie să se atingă țelul ales. Considerând exemplul nostru, compania producătoare de software va îmbunătății un produs existent, dezvoltând o extensie care se adresează industriei hoteliere, un segment de piață nou firmei.
• Strategia S-T: Bazându-se pe punctele forte interne se apără de amenințările din exterior. În exemplul nostru, compania se folosește de puterea sa de pe piață împotriva concurenței unei alte companii, încercând să iși păstreze clienții.
• Strategia W-O: Îmbunătățirea punctelor slabe pentru a genera posibilități, și/sau folosirea unor oportunități pentru dezvoltare, in ciuda punctelor slabe. In exemplul nostru: dacă performanța modulelor pentru telefoanele mobile ar fi imbunătățită, atunci clienții ar putea părăsi concurență, care oricum are probleme de calitate.
• Strategia W-T: Imbunătățirea punctelor slabe, pentru a fi aparat de amenințări din exterior, sau protejarea punctelor slabe de posibile amenințări din exterior. In exemplul de mai sus, cel mai la îndemâna ar fi scăderea costurilor de producție – de ex. prin outsourcing.

Una sau o combinație de mai multe strategii pot fi, in urma analizei, adoptate. Analiza SWOT este un instrument simplu dar puternic de management, care insă nu pune la dispoziție un algoritm de automatizare al procesului decizional. Scopul acestei analize este de a realiza un cadru, în care deciziile se iau considerând aspectele esențiale ale unei problematici.

Inițializarea, cea mai importantă fază a proiectului, din punct de vedere managerial, poate fi văzută ca fiind drumul de la idee la acțiune economică bine definită, având la bază un contract. Pentru a putea întocmi contractul, va trebui să dispunem de parametrii săi constitutivi: durată, costuri, preț, părți implicate, rezultat final și nu în ultimul rând riscuri. Inițializarea proiectului va trebui să furnizeze aceste date … dar nu numai. În urma acestei faze vom fi pregătiți pentru începerea lucrului efectiv în proiect, ceea ce înseamnă că echipa este constituită, resursele interne alocate, subcontractorii și ceilalți parteneri sunt disponibili conform planului de resurse. Mai trebuie spus că precizia și realismul cu care este parcursă această fază, vor determina în mod decisiv succesul proiectului, în primul rând datorită angajamentelor contractuale care rezultă din ea.

Vă propun în cele ce urmează o abordare sistematică a acestei faze, cu pași preciși în direcția elaborării primului baseline al proiectului. Am văzut deja că orice proiect pornește de la o idee. Este esențial să ințelegem cât mai bine această idee, iar ca prim pas să o putem descompune – împreună cu owner-ul sau clientul proiectului nostru – în:

• obiective,
• beneficii

În acest context beneficiile reprezintă urmarea atingerii obiectivelor. Este important să înțelegem ce câștigă clientul nostru prin implementarea proiectului și prin atingerea fiecărui obiectiv în parte, înțelegând că de fapt primar este beneficiul, nu calea prin care este obținut (obiectivul). Probabil ați observat deja simplificarea cu care am lucrat până acum, și anume reducerea întregului grup de stakeholder-i la unul singur: owner-ul proiectului. Acum este momentul să identificăm persoanele care sunt atinse în interesele lor de rezultatele proiectului, în mod pozitiv sau negativ. Într-o primă fază este suficientă “inventarierea” lor într-o listă a stakeholder-ilor și sortarea lor în funcție de puterea lor de influență asupra proiectului. Într-o fază ulterioară va trebui să analizăm riscurile ce se desprind din această influență, precum și să dezvoltăm, planificăm și implementăm tactici de comunicare în vederea minimizării acestor riscuri, spre exemplu prin convertirea unor atitudini negative vizavi de proiect.

După completarea listei stakeholder-ilor, va trebui să consemnăm – eventual prin interviuri personale – obiectivele individuale ale fiecărui stakeholder în parte, în raport cu proiectul. Vom constata în multe cazuri contradicții între obiectivele diferiților stakeholder-i. Acum este momentul să întocmim matricea obiectivelor, etapă esențială în inițializarea proiectului prin care punem obiectivele stakeholder-ilor în raport unele cu celelalte, prioritizându-le în mod corect, în funcție de “greutatea” posesorilor lor și a așteptărilor acestora. O listă de obiective prioritizate, asupra cărora s-a agreat între principalii decidenți ai proiectului, este primul rezultat palpabil al definirii unui proiect.

Până la intrarea în faza de planificare ne mai lipsesc 5 etape/documente importante:

• finalizarea analizei stakeholder-ilor prin stabilirea și cuantificarea măsurilor concrete destinate obținerii sau sporirii suportului stakeholder-ilor, dar și atenuării eventualelor conflicte de interese/obiective dintre aceștia. În legătură cu analiza stakeholder-ilor este planul sau matricea de comunicare, care nu trebuie să lipsească în proiecte complexe, și va include căile și frecvența de raportare, precum și modele de escaladare a problemelor.
• o primă analiză de risc, care va avea la bază riscurile identificate în analiza stakeholderi-ilor – considerată prima analiză de risc a unui proiect. Se va cuantifica valoarea sau greutatea riscului, ca produs dintre mărimea pagubei pe care un risc l-ar produce și probabilitatea intervenirii lui. Măsurile de prevenire sau reducere a gravității riscurilor, trebuiesc tratate ca orice altă acțiune a planului de proiect, prin estimarea efortului, alocarea de resurse și includerea lor în planul de proiect.
• Împărțirea proiectului în faze, alegerea unui model de tranziție de fază (Waterfall, V-Modell, Agile etc.) și stabilirea intrărilor și ieșirilor pentru fiecare fază. În afara fazelor evidente – inițializare, implementare, finalizare – putem avea, în funcție de mărimea și natura proiectului, un număr de alte faze bine definite: pre-proiect, licitație/caiet de sarcini, studiu de fezabilitate, concepție, pilotare, diverse faze de implementare – de obicei în proiectele de investiții/construcții, testare, acceptanță, mentenanță etc.
• Identificarea cerințelor proiectului, pornind de la lista obiectivelor și formând de preferință o echipă mixtă, între specialiștii clientului și arhitecții proprii. În analiza și redactarea cerințelor e bine să avem în vedere faptul că rezultatul acestei analize – catalogul de cerințe – este punctul de pornire în definirea pachetelor de lucru. Deci, trebuie să prioritizăm cerințele, să le punem în legătură unele cu altele din punct de vedere funțional și să încercăm o primă estimare de efort/costuri.
• Identificarea într-un skill-list a cunoștințelor și aptitudinilor necesare pentru concepția și implementarea cerințelor definite anterior.

În acest moment avem elementele necesare pentru întocmirea primului plan al proiectului. Acesta va cuprinde, în această ordine:

• Plan temporal (faze, activități, milestone-uri),
• Estimarea efortului pentru fiecare activitate,
• Planul de resurse (responsabili, încărcare/resursă),
• Bugetul sau planul de cheltuieli (costuri cu resurse interne, externe, achiziții, investiții), eventual un prim cash-flow.

Odată ce asupra acestor elemente au consimțit toți decidenții importanți, putem afirma că proiectul nostru a primit o primă definiție – putem “pune sub cheie” primul baseline al proiectului care va sta la baza contractului. Acesta va include persoanele implicate, obiectivele și beneficiile acestora, tacticile de comunicare, măsurile de prevenire a riscurilor, cerințele si aptitudinile necesare implementării lor și planul de proiect cu toate aspectele sale. Aceste elemente au o interdependență atât de mare, incât omiterea unuia dintre ele va scădea automat calitatea celorlalte. Importanța capitală a primului baseline (agreat!) al proiectului constă în faptul că permite catalogarea cerințelor sau schimbărilor ulterioare în proiect ca Change Request, care poate fi bugetat separat și constituie o extindere a contractului inițial. O tactică destul de răspândită printre firmele de consultanță constă tocmai în oferirea inițială a unui preț mic, prin includerea conștientă de cerințe incomplete în primul baseline și creșterea veniturilor prin Change Request-uri în decursul proiectului – după modelul păgubos al subînțelesului neformulat explicit: meșterul care-ți spune că n-a fost vorba de la început să-ți facă și ușă la cameră.

Asupra fiecărui element vom reveni cu template-uri și best practices. Ca de obicei, îndemnul de a descrie experiențele personale pe tema abordată!

Firmele mai mici sunt astfel constrânse să își aleagă, din multitudinea de procese și metode existente, cele care, dacă ar fi implementate, ar aduce câștig maxim, și să se ferească de implementarea altora, pentru care efortul ar depășii câștigul.

Este de așteptat ca, dacă o firmă de mărime medie (aș lua ca ordin de mărime câțiva zeci de angajați) își concentrează mult prea multe resurse spre implemetarea de procese care să nu aibă aplicabilitate directă în creșterea vitezei implementării sau a calitații produsului, să piardă din performanță și flexibilitate – două arme extrem de importante ale unei companii mici în lupta pe piață.

Project Management-ul aduce o valoare reală în îmbunătățirea capacității de conducere și control al unei companii. Și doar din acest punct de vedere am putea trage concluzia că este de dorit ca ORICE firmă să înceapă să introducă PM, să îl facă parte integrantă din existența sa. Project Management-ul, dacă este folosit corect, susține schimbarea și îmbunătățește calitatea și performanța. Există însă un echilibru fragil, o culme, care dacă a fost ratată, dă o cădere spre over-regulation, care va avansa rapid spre un blocaj în dezvoltarea proiectelor.

Aș enumera câteva părți din metodologia PM (fără o ordine anume) care dacă sunt implementate corect, în contextul companiilor mici și mijlocii, aduc câștiguri imediate – fiecare cu avantaje și bineînțeles anumite dezavantaje:

• Distribuția și cumulul de roluri

Numirea unui PM este esențială oricărui proiect. Responsabilitatea proiectului este delegată unei persoane, nu unei echipe. Project Manager-ul este cel care trebuie să asigure execuția și terminarea unui proiect în timp și buget, la calitatea cerută. Este indicat ca PM-ul să joace și rolul de Ressource Manager sau cel de Release Manager – avantajele sunt clare, deciziile (de personal, de executie) se iau ușor și rapid.

Este de asemenea uzual ca persoane din executivul firmei să joace rol de PM. Avantajul acestei distribuții de roluri este clar, proiectul primește o prioritate vizibilă, importanța sa în interiorul firmei devine clară. Deciziile în proiect se iau mai ușor, iar echipa este mai motivată. Cumulul acesta de roluri poate însă să ascundă și dezavantaje: executivul firmei poate pierde multă energie în pachete de lucru specifice unui proiect, în loc să delege, pierzând poate din vedere decizii strategice, de importanță pentru firmă, din cauza implicării prea mari (poate chiar și emoționale) într-un anume proiect. În plus, lipsește o stațiune de control, cea a executivului, instanța superioară a unui proiect, care poate aduce o opinie distanțată de lucrul operativ.

Dacă există Project Manager numit într-un proiect condus de fapt de către executiv, în care deciziile majore se iau din afara proiectului, atunci PM-ului îi lipsește o verigă importantă a poziției sale. Se transformă din PM în executor, iar aceasta poate duce la o pierdere a motivației, cu efecte negative asupra proiectului. Acest efect se poate accentua și mai mult, dacă executivul îl consideră pe Project Manager răspunzător pentru rezultat, luîndu-i în același timp capacitățiile de decizie.

• Planificarea proiectului

Un plan trebuie să existe – sună simplu și banal, și chiar așa și este. Milestones trebuiesc marcate, un minim de calcul al pachetelor de lucru nu poate lipsi, minime estimări, planificarea resurselor și a bugetului sunt extrem de importante. Fără plan este și controlul proiectului imposibil. Software-ul ajută (vezi Software) – dar nu înlocuiește, nici persoana (PM-ul), nici metoda.

• Existența și actualizarea unui „Manual intern de Project Management”

Orice companie care introduce PM are obligația de a descrie procesele implementate. Descrierea trebuie să fie făcută într-un catalog (manual) accesibil oricând oricărui membru al echipei sau al echipelor de proiect. Implementarea unui proces sau a unei metode PM este de fapt pasul decisiv făcut de la abstract spre practic, în contextul firmei. Implementarea este croită pe măsurile companiei și în funcție de uzanțele firmei – iar aceste aspecte trebuiesc documentate. Membrii echipei trebuie să înțeleagă și să simtă beneficiile pasului făcut. Esențială este de asemenea și actualizarea acestor procese. Implementarea unui proces PM nu este o activitate punctuală, care s-a făcut o dată și e bună întotdeauna – orice schimbare (care e normală) trebuie să ducă și la actualizarea descrierii în manual. Bineînțeles, această actualizare este făcută folosind resurse rupte din activitatea direct productivă – dar investiția rentează.

• Inexistența unui studiu al riscului (Due Dilligence)

Este de multe ori o practică normală. Într-un mediu concurențial cu o schimbare atât de rapidă ca cel actual, o întârziere în acceptarea unui contract poate să reprezinte diferența între a avea un proiect sau nu. Nu se poate defini nici o regulă în a accepta sau nu un risc (considerând că îl cunoști). Este perfect legitim să îți asculți și să îți urmezi intuiția. Dar trebuie avut în vedere faptul că, intuiția unuia nu este cunoscută tuturor, din aceasta cauză, decizia trebuie comunicată într-un mod corespunzător, în special făcându-se cunoscut și cui îi aparține.

• Managementul comunicației

Acesta este un atu important al companiilor medii și mici, față de cele mari și multi-naționale. În principal, diferența este dată de apropierea spațială dintre membrii echipei. Aceasta duce automat la o comunicare informală performantă – persoanele se cunosc, comunicația non-verbală este prezentă continuu, există posibilitatea de a organiza întâlniri spontane, decizii importante se pot lua ușor, chiar între patru ochi, lângă mașina de cafea.

În performanța crescută a comunicării informale se ascunde o capcană: neglijarea comunicării formale, care nu poate să lipsească. Jour fixe, Project meeting, meeting minutes, trebuiesc ținute și documentate acribic (vezi Protocolul intâlnirilor). Orice decizie, chiar și cea luată la mașina de cafea, trebuie comunicată și documentată.

• Motivarea echipei

Este de multe ori mai usoară in companiile mici. Tocmai mulțumită apropierii, dorințele și aspirațiile fiecărui membru al echipei sunt mai bine cunoscute, față de companiile mari, în care există o anumită tendință de a impersonaliza „resursele”. În plus, pe lângă Project Manager există și un membru al management-ului mai apropiat proiectului, comparativ cu firmele mari. (Vezi Motivarea echipei)

• Controlul calității

Îmbunătațirea procesului de asigurare a calitații este în mare parte responsabilitatea echipei de execuție. Dar, de multe ori, și testarea este lăsată aceleiași echipe de execuție, resurse specializate pentru testare nefiind de multe ori folosite – de cele mai multe ori, pentru a minimiza costurilei. În acest caz, lipsa unei opinii externe proiectului, poate avea efecte negative asupra controlului calității. Iar dacă nu e QC nu e nici QA. A folosii echipe de testare inter-proiect este o idee bună în practică. (Vezi Calitatea)

• Proiect controlling

Implementarea unui mecanism de controlling este vitală în urmărirea bugetului și a execuției proiectului. Earned Value Management (Vezi Analiza EV) este o metodă simplă, cu o aplicabilitate practică foarte bună – chiar și în proiecte, în care există un minim de Project Management, respectiv un plan al proiectului.

Consider că următorul aspect are o importanță majoră: în momentul în care există un proces PM implementat și documentat, el trebuie respectat de către toate persoanele din companie – incluzând managementul și executivul. Altfel, valoarea lui se pierde, procesul devenind in cel mai bun caz unul opțional.

De multe ori, companiile interesate de introducerea Project Management-ului, nu au know-how-ul necesar. Aici, angajarea pe perioadă limitată a unui consultant experimentat are avantaje majore. O colaborare între un PM experimentat versat și angajații firmei (inclusiv executiv) duce la rezultate bune în timp minim. A invăța din Try-and-Error în interiorul firmei poate fi extrem de scump. Acceptanța Project Management-ului este un alt punct care ar trebui discutat, în special cu executivul, în momentul in care există opoziție la implementarea unui proces, trebuie văzut de ce – de multe ori această opoziție fiind un semn clar că acel proces nu este decupat pe necesitățile sau pe specificul companiei. Există oameni care strigă dupa reguli, care să îi apere de haos. Există oameni care se ascund în haos. Există oameni care cred că dispariția haosului le va omorâ creativitatea. Orice implementare a unui proces PM, va avea adepti și dușmani, pentru că regularizează o transformare și presupune disciplină.