PMO – Biroul de Mangement de Proiect

la AtekPC

Biroul pentru Managementul de proiect al AtekPC

O ploaie a început în seara de 3 martie 2007 și străzile metropolei unde erau localizate sediile AtekPC
erau reci și gri. Cum John Strider, CIO al AtekPC, își împacheta servieta la finalul zilei, gândurile lui s-au
întors la noul Birou de Management al Proiectelor (PMO) pe care l-a aprobat acum câteva luni. În timpul lui
de peste 20 de ani la AtekPC, Strider nu a fost martor niciodată la astfel de presiuni cum trebuia să facă față
acum industria de personal computer (PC). Strider a recunoscut că industria era în tranziție și că organizația
lui de tehnologie a informației (IT) ar putea fi implicată în câteva proiecte critice în zilele următoare, acum
AtekPC ar trebui să ocupe un rol de leadership în aceste schimbări. A fost acel gând care i-a adus în minte
de inițiativa PMO. Dacă ar fi implementate corect, acest PMO ar putea fi un mare ajutor pentru AtekPC, dar
Strider avea griji în privința a ceea ce s-ar putea întâmpla dacă ei ar fi încercat prea mult cu această idee. În
locul ajutorului, ar putea deveni un alt lucru în lista lui de probleme. Erau atât de multe întrebări în mintea lui:

Cât de mult PM este suficient PM? Cât de mult suport PMO este suficient suportului PMO? Când
ajungi la ideea că structura și procesul PMO ușurează productivitatea și contribuie la un rezultat cu un
succes mai mare cu mai puține greșeli și cu un rezultat de o calitate mai mare – indiferent de cum definești
succesul la început? Și când implicarea PM devine administrație pentru propriile scopuri? Când treci linia?

Strider credea că a înțeles ce ar putea face acest PMO pentru AtekPC, dar inițiativa era încă în fazele
timpurii. Avea nevoie de timp pentru a demonstra. Pe de altă parte, echipa lui de management a angajat
câțiva oameni experimentați cu un real talent de a influența programul PMO. Dar ei erau noi pentru afacerea
PC și pentru AtekPC. Ei nu înțelegeau cât de puternică era cultura aici, se gânde el. Cum Strider s-a
exprimat, PMO-ul trebuia să devină a parte a culturii AtekPC și asta cerea mici schimbări pe o perioadă lungă
de timp. Dacă PMO-ul se găsea luptând împotriva culturii, ar fi fost un eșec, cu siguranță. Ca CIO era
conștient de inițiativele și responsabilitățile pe care ar fi trebuit să le îndeplinească cu resursele sale limitate
și știa că PMO-ul era unul singur dintre acestea. Nu putea să lase lucrurile să cadă doar pentru a construi
acest nou PMO. Totul trebuia făcut împreună. Strider știa că oamenii lui care lucrau la PMO erau frustrați că
nu se putea mișca mai repede. El, de asemenea, a fost tentat de gândul încărcării rapide a PMOului cu mai
multe resurse și distrugând alte proiecte. Dar în opinia lui, asta ar fi fost o inițiativă de scurtă durată – prea
mult, prea devreme, prea repede.

Strider și-a închis servieta și s-a îndreptat către lift. Echipa lui de management pe IT a fost cu el pentru
muți ani. Se simțea încrezător că ar putea să îi conducă către calea cea dreaptă fără să li se piardă
entuziasmul pentru acest nou PMO. Dar ar fi asta de ajuns? Pentru Strider plata era despre aliniere –
alinierea directiilor de business strategic cu resursele IT și asta era esența PMO-ului. Marja de eroare era
mică la AtekPC în aceste timpuri schimbătoare.

Istoricul industriei

Industria PC experimenta o presiune a costului și trecea printr-o perioadă de consolidare. Cum marja
de profit a căzut, producătorii PC lansau strategii de cost redus țintind către o îmbunătățire a eficienței a
lanțurilor lor de ofertă, în timp ce scădeau prețul distribuției. Dintr-un articol recent de ziar:

Recentele rezultate financiare pentru producătorii PC arată o scădere atât în vânzări, cât și în
profitabilitate. Atât corporațiile cât și consumatorii țin de PC-urile lor pentru o perioadă mai lungă de timp
pentru a evita costul asociat cu upgradingul echipamentelor lor. Ca rezultat, cumpărăturile sunt în scădere și
producătorii PC caută noi piețe pentru oportunități de creștere. Industria pare să treacă printr-un val de
consolidare în timp ce controlul costului și scalarea devin mai importante ca oricând.
1
 În 2007, o importantă revistă a realizat o copertă cu titltul ,,Unde se va plasa PC-ul?”. Amenințările
raportate în analizele lor erau în întreaga lume și se datorau unei varietăți de factori încluzând creșterea
popularității pentru telefoanele mobile, tablete și software-uri cu aplicații web.

Pentru majoritatea oamenilor, emailul este cea mai importantă aplicație pe care o folosesc. Pentru o
perioadă lungă de timp, trimiterea și primirea mailurilor necesita deținerea unui întreg PC. În zilele noastre,
oamenii de afaceri și consumatorii vor să profite de beneficiul de a fi capabili să acceseze mailul de oriunde
24/7 fără să care un calculator după ei. Telefoanele mobile și tabletele oferă acum această posibilitate,
făcând mulți oameni să pună la îndoială necesitatea unui calculator. În zilele de glorie a calculatorului, piața
era fără granițe, dar creșterea a încetinit considerabil. Mai mult, prin creșterea popularității aplicațiilor web,
atât oamenii de afaceri cât și consumatorii cumpără aparete mai ieftine care pot accesa aplicațiile web și
care nu necesită cantități masive de spațiu de stocare. Ignorând realitatea mai mulți ani la rând, producătorii
PC fac în sfârșit ceva. Ca să scadă costurile, ei deja folosesc tehnologia informației și caută noi produse și
noi piețe pentru a menține greșterea veniturilor și pentru a crește profitabilitatea.

AtekPC

Înființată în 1984, AtekPC a crescut ca să ajungă un producător de talie medie în Statele Unite cu
vânzări în 2006 în valoare de 1.9 bilioane de dolari. AtekPC a angajat 2100 lucrători full time și în plus 200
de lucrători part time. În ciuda istoriei sale de creștere rapidă în anii 90, AtekPC s-a trezit zbătându-se printre
alți producători la nivel mondial, deoarece aceștia au depășit tranziția de la o creștere a industriei la una a
maturizării industriei. Strider a explicat:

Industria PC s-a schimbat și va continua să se schimbe la un pas accelerat. La un anumit punct,

industria PC s-a bucurat de ratele de creștere și de marginile bune de profit. Ca rezultat, am avut tendința de
a nu fi grijulii cum ar fi trebuit legat de controlul costurilor și făcând față amenințărilor competiției. Acum,
desigur, imaginea s-a schimbat și luptăm împotriva competiției din Asia, care este în creștere. Producătorii
din Asia au făcut tranziția de la contractele de producție la partea de marketing pentru propriile lor branduri
de PC.

Industria PC trece prin consolidare cât timp jucători mai mari acaparează jucători mai mici ca să
obțină o scară mai mare. Avem o nevoie mai puternică decât niciodată să fim agresivi și să ne mișcăm repede
pentru a reduce costurile și de a acapara noi piețe. Trebuie să devenim o companie mai agilă pentru ca
abilitățile noastre să fie mai consistente cu numele noastre implicate. În viitor, va trebui să fim mult mai
pregătiți sau vom risca ori să devenim neprofitabili ori să devenim ținta unei preluări ostile.

În toamna anului 2006, AtekPC deja începuse câteva initiative axate pe poziționarea organizației în
viitor. Una din acestea a fost stabilirea unui birou pentru planificare strategică a căui responsabilități erau sp
propună schimbări de afaceri. Sub autoritatea acestui birou, inițialul efort al PMO-ului care era axat pe
proiectele IT ar putea într-o bună zi să devină o companie PMO. AtekPC a recunoscut că vor trebui să fie
capabili să managerieze proiecte mai eficient și mai efectiv astfel încât să propunerea pentru biroul de
planificare să poată merge mai departe. În martie 2007, biroul pentru planificare strategică și inițialul PMO
au fost operative doar pentru câteva luni. După spusele lui Strider, AtekPC era sub o competiție de creștere
a prețurilor și managementul era sub o mare presiune să se asigure că fiecare mișcare era anticipată.

Tehnologia informației la AtekPC

De-a lungul anilor AtekPC a dezvoltat un portofoliu extensiv de aplicații. Aceste aplicații erau în
principal axate pe nivelul operațional al funcțiilor tipice ale afacerii pentru un producător PC, cum ar fi
contabilitate, vânzări, sourcing și distribuție. Integrarea arhitecturală a acestor sisteme de aplicații a fost doar
parțial realizată, așa că până în 2007, ariile funcționale primeau adesea servicii discrete de informații cu
puțină integrare multi funcțională. Proiectele de sisteme informaționale erau operaționale sau se realizau
eforturi pentru menținere la cererea unei arii funcționale particulare. Ele erau în general proiecte de

2
dimensiuni mici până la dimensiuni medii în termeni de dimensiuni și durată și erau manageriate informal
fără practici standartizate. Ca director al Dezvoltării Aplicațiilor, Richard Steinberg explică:

Din punct de vedere istoric, noi întotdeauna am făcut doar treaba noastră. Am avut multe proiecte
operaționale și multe dezvoltări în desfășurare, dar am avut foarte puține aplicații de companie în
desfășurare. De-a lungul anilor, erau câtiva oameni în companie care au recunoscut că se putea îmbunătăți
calitatea muncii. Cum am început să ne interesăm ce aveam de făcut în viitor, am realizat că trebuia să ne
îmbunătățim abilitățile pentru a putea fi mai agresivi și siguri pe proiecte și să fim capabili să gestionăm mai
multe proiecte în același timp. Așa că am realizat un plan pentru PMO, în esență o metodologie de
management de proiect pentru toate ariile mele.

Mediul în continuă schimbare pe care AteKPC trebuie să îl înfrunte a creat un număr de provocări
care se adresau unor proiecte mari și complexe. Noul PMO a fost introdus pentru a oferi standartizare în
managerierea acestor proiecte și să câștige îmbunătățiri în părțile de planificare și de performanță ale
inițiativelor. Deși AtekPC a realizat câteva proiecte mari în trecut pentru care s-au adoptat nilte practici
formale, aceste proiecte nu au rezistat în formalizarea practicilor. Steinberg explică:

Poți merge în trecut, înapoi la Y2K, la conversia sistemului nostru de management; pentru acele
proiecte mari a fost folosită o abordare de management de proiect. Ei nu au realizat asta. Ei i-au adunat pe
toți; ei au vorbit despre ce va trebui făcut pentru a realiza asta și au reușit. Toți au felicitat și au spus ,,Asta
a fost bine făcut. Acum că am terminat cu asta, trebuie să ne întoarcem să realizăm proiecte în mod normal
.” Ei nu au realizat că aceasta este calea de a face lucrurile. Dintr-o dată, când acele lucruri importante dispar,
ajungi să faci lucrurile așa cum le făceai înainte.

În 2007, proiectele IT erau manageriate prin adăugarea responsabilităților de manager de proiect unui
angajat din aria de dezvoltare care era alocat unei arii funcționale specifice. De exemplu, șeful analist alocat
pentru fabricație trebuia să ocupe și poziția de manager de proiect. Acesta superviza grupuri de muncă
formate din analiști și programatori care variau în funcție de nivelul abilităților lor și erau responsabili pentru
satisfacerea cerințelor ariilor funcționale și pentru performanța lor în grupurile de muncă. Folosind un proces
informal de inițiere pentru proiecte, utilizatorii au cerut servicii IT prin șeful analist, care atunci manageria
proiectul cu suportul resurselor din grupurile de muncă. Managerul, în cazul acesta Managerul Sistemelor de
fabricație, a rezolvat orice problemă sau conflict, dacă era necesar; în caz contrar, cererea era primită,
executată și livrată prin șeful analist. Metodele proiectelor, documentația, practicile și instrumentele erau
individualizate de către șeful analist fără implicarea grupurilor IT sau a alor domenii de business.

AtekPC a obținut multe beneficii în urma utilizării acestei abordări informale în proiecte. Șeful analist
a dezvoltat cunoștințe aprofundate despre activitățile de business, nevoi și oameni. Ca un rezultat al acestei
abordări informale, ei au oferit răspunsuri rapide cererilor utilizatorilor și erau capabili să cântărească nevoile
urgente în grupurile lor de lucru, fără conflicte. Datorită acestui record de livrare receptivă, s-a dezvoltat
încrederea între între ariile funcționale și șeful analist. Relația bazată pe adevăr era puternic personalizată
către angajații individuali și din ambele părți au apărut loialități. Deschiderea acestor relații i-a permis șefului
analist să adune și să stabilească rapid cerințele și să ajungă la un consens în privința programului și a datei
de livrare. Linda Star, șef analist pentru fabricație, a descris munca ei:

În lumea mea am o varietate de utilizatori cu care vorbesc. Ei pot spune că ,,am nevoie de asta, chiar
am nevoie de asta, pot să o obțin? Aceasta este o urgență și trebuie să o am.” Când se întâmplă asta, mă
întorc și mă uit la ce lucrează oamenii mei și le spun ,,Trebuie să schimbăm cea ce facem. Am nevoie să îți
dați două ore, două zile sau cât va fi nevoie. Trebuie să facem această mică bucățică...” Realizez un program
bazat pe ce face fiecare din grup și ceea ce știu în urma unei discuții cu ei.

Această abordare informală a managementului de proiect a fost norma tradițională la AtekPC. Din
punct de vedere istoric, viziunea principală era că IT-ul era periferic activităților centrale de afaceri la AtekPC.
Ca rezultat, IT-ul a fost văzut ca un primitor de ordine, de la care se aștepta să ofere servicii la cerere. În

3
timpul ultimului deceniu, proiectele au devenit din ce în ce mai axate pe operații și mentenanță într-un efort
de a îmbunătăți eficiența în funcțiile afacerii. Dezvoltarea sistemelor multi-funcționale de integrare și folosirea
tehnologiilor de internet erau doar două dintre nevoile urgente, având în vedere faptul că AtekPC se lupta cu
schimbări radicale în industrie și pe piață. Noile proiecte cerute erau mai mari, mai complexe și implicau arii
multi-funcționale și arii tehnologice multi-funcționale, spre deosebire de proiectele realizate în trecut de către
un singur grup. Cererea acestor noi inițiative și proiecte se aștepta să suprasolicite metodele curente de
management de proiect informal. PMO-ul a fost implementat pentru a oferi practici mai consistente și mai
bune pentru afacere și pentru proiectele IT. Cu toate acestea, implementarea PMO-ului a fost în sine o
provocare ce a cerut un noi abilități de management pentru a putea reuși. Trebuia să se mențină o balanță
dificilă între fabricație și noi dezvoltări la fel ca între resursele care intrau în activitățile de dezvoltare și
resursele care intrau în activitățile de management de proiect sub conducerea noului PMO. Strider a descris
provocarea:

Nu am rezolvat totul. Asta este mai bine decât să te gândești că ai reușit când, de fapt, nu ai făcut-o.
În departamentele de IT trebuie să fim mai buni în a administra conflictele între inițiativele noii afaceri și
operațiile cu schimbări incrementale în sistemele existente. Nu putem sacrifica una pentru cealaltă. Istoria
arată că nu am făcut doar operațiuni de fabricație și acum trebuie să avem o cultură pentru a le face pe
amândouă.

Misiunea PMO

Misiunea PMO-ului a început să evolueze gradual de la conceperea acestuia în 2006. În primăvara

anului 2007, nu exista un consens complet referitor la scopul, responsabilitățile și autoritatea acestuia. Cum
nu existau documente formale și nici planuri, primul scop era să se înființeze biroul și să își demonstreze
valoarea. Consensul general era că scopul PMO-ului era să realizeze beneficiile derivate din practicile
proiectelor. Deși nu era clar specificat sau măsurabil la acel timp, aceste beneficii erau exprimate într-o
varietate de termeni, pornind de la îmbunătățirile IT în performanța proiectelor, eficiență și utilizarea
resurselor pentru îmbunătățirile companiei în managemetul costului și capabilitatea de a lansa produse.
Steiberg a explicat din perspectiva companiei:

Dacă mă gândesc la industria PC și la provocările acesteia, mă gândesc la două lucuri care ar putea
funcționa pentru PMO. Una ar putea fi reducerea costutului. Nu ne permitem să fim neglijenți. Sincer, trebuie
să fim mult mai atenți cum ne folosim resursele. Altă motivație să devenim mai buni în proiecte ar fi să
devenim mai creativi, adaptabili și agili în lansarea noilor produse. Și pentru a lansa noi produse, cine ar
putea conduce acele inițiative, dacă nu managementul de proiect?

Deși, responsabilitățile PMO-ului nu erau foarte clare. În prezent, responsabilitățile sunt limitate la
proiecte IT, deși existau discuții despre extinderea scopului către un nivel al întreprinderii care să includă
proiecte de afaceri în viitor. Îndatoririle specifice ale lui PMO erau divizate tipic în două categorii: axate pe
proiect și orientate către companie. Responsabilitățile axate pe proiecte, cum ar fi consultanță, mentoring și
trainingul erau servicii care permiteau succesul individual al proiectelor. Pe de altă parte, responsabilitățile
companiei au adresat servicii care ar putea îmbunătăți toate proiectele, cum ar fi portofoliul managementului,
standartele managementului de proiect, metodele și instrumentele și arhivele performanței proiectului.
Clarificarea responsabilităților PMO-ului a fost într-o continuă evoluție în timp ce AtekPC a încercat să obțină
suport și să ajungă la un acord în misiunea și carta sa:

La AtekPC, responsabilitățile proiectelor erau primele folosite pentru a demonstra meritele PMO-ului.
Planul era să se creeze acceptare prin consultarea și mentoringul proiectelor individuale. Mark Nelson, noul
manager al PMO-ului, a vorbit despre acest efort:

Ceea ce am făcut din octombrie 2006 a adus mentoring și suport pentru managementul de proiect cu
proiecte-cheie care au fost identificate de către salariații din IT. Pentru viitorul apropiat, până începem să ne

4
desfășurăm, planul este să lucrez cu o persoană de la planificarea proiectului – întâlniri regulate cu echipele,
rapoarte, probleme de fabricație și gestionarea riscurilor.

Până atunci, PMO-ul a continuat să câștige suportul ariilor funcționale și personalului IT implicat în
aceste proiecte. O mare limitare a fost scăderea resurselor experte care suportau aceste proiecte. În plus
față de ce a spus Nelson, erau alți trei manageri de proiect desemnați pentru PMO, iar aceștia erau angajați
cu contract. Folosind angajații PMO pentrua gestiona direct proiectele era o practică frecventă; deși, Nelson
a desemnat unul dintre managerii de proiect pentur un proiect critic, care presupunea lansarea de noi
computere de tip notebook.

Responsabilitățile orietate către companie erau greu de dezvoltat pentru PMO la AtekPC. Noul PMO
dezvolta câteva noi procese și proceduri standard de proiect. Steven Gardner, managerul sistemelor de
fabricație, a comentat asupra unui proces pe care PMO-ul l-a introdus:

Nelson ne-a ajutat să dezvoltăm ceea ce numim ,,forma ideii” unde noi încercăm să eliminăm
apelurile aleatorii care ajung la noi. Încercăm să prioritizăm mai bine ceea ce lucrăm și folosind această
,,formă a ideii” ne conduce către construirea unei afaceri înțelegând despre ce este acea idee. Asta ne
forțează să gândim, dar asta se întâmplă și pe partea solicitantului. Îi ajută să gândească în prinvința utilizării.
De ce avem de gând să economisim aici? Care este motivul pentru așa ceva? Merită să facem acest proiect
în locul altuia? Acum, cum prioritizez asta? Așadar, ne ajută să deținem controlul lucrurilor la care lucrăm.

Serviciile dezvoltate de echipa PMO a lui Nelson au fost bine primite. În timp ce progresul în această
arie era constrâns de resursele limitate ale PMO-ului, exista o înțelegere clară chiar și la nivlul CIO-ului că
PMO-ul era responsabil de stabili, publica și împărți practicile de proiect, standardele și instrumentele. Pe de
altă parte, portofoliul de management și înregistrarea responsabilităților nu erau adresate. Nelson spera să
fie capabil să includă aceste îndatoriri în misiune pe măsură ce PMO-ul se dezvolta, dar fără resurse
adiționale nu era posibil în termen scurt. De asemenea, el a realizat că resursele adiționale ar fi putut venit
doar luându-le de la alte responsabilități critice și asta ar fi putut compromite abilitatea lor de a menține
eficiența operațională. Era o balanță provocatoare.

Ultima arie de îngrijorare legată de misiune era problema autorității. Strider a recunoscut că
implementarea acestor noi practici de proiect au cerut o autoritate formală și el era pregătit să asigure asta
doar când PMO-ul s-ar fi dovedit în fața afacerii și în fața IT-ului. Pentru eforturile timpurii, Nelson lucra sub
beneficiul unei autorități care era general conștientizată de către schimbarea direcțiilor de management. Deși,
PMO-ul a avut, de asemenea, suportul vice președintelui. Larry Field care era un membru cheie al inițiativei
PMO de la început și el a explicat: ,,Pentru a fi eficienți, trebuie să avem susținere de sus. Și avem susținere
de la vice președinte prin John Strider și în jos. Acesta este primul și cel mai urgent lucru de realizat pentru
a face lucrurile să meargă.”

Cu toate acestea, pentru că nu toți seniorii erau entuziasmați în mod egal legat de conceptul PMO,
autoritatea a fost dezvoltată de jos în sus prin valoarea serviciilor PMO. Chiar și acest aspect a fost limitat la
acele arii funcționale și la ariile IT. Nu exista un plan curent pentru a întări utilizarea nivelului companiei.
Nelson a rezumat abordarea sa prin aceste remarci:

Cel mai important lucru este mentoringul care se desfășoară și chiar influențează proiectele. Noi
suntem răbdători acum pentru a putea primi niște exemple concrete pe care să le putem arăta. Putem spune
,,uite ce poate să facă pentru tine. Acest proiect care ar fi durat un an și jumătate, noi în facem în trei sau
patru luni acum deoarece am pus aceste practici în aplicare.” Și aceatsa este cheia pentru că ne lasă să ne
arătăm valoarea. Aceasta trebuie să fie abordarea pentru acum.

5
 Organizarea PMO

Pentru PMO au fost luate în considerare două modele organizaționale. Acestea au fost denumite
PMO-greu și PMO-ușor și reprezentau două extreme pentru abordarea organizațională a PMO-ului. La o
extremă, PMO-greu era caracterizat prin angajați formați doar din manageri de proiect care și-au asumat
responsabilitatea pentru managementul tuturor proiectelor de IT. Acest model se axa pe achiziția de experți
pe managementul de proiect, ori din surse interne, ori din surse externe și folosirea acestora sub direcția
PMO-ului. În versiunea extremă a PMO-greu, niciun proiect nu ar fi operat în afara controlului direct al PMO.
Cealaltă varianyă, PMO-ușor era caracterizat prin un număr mic de angajați format din experți care lucrau în
proiectele interne pentru a realiza responsabilitățile PMO-ului. Acest model se axa pe dezvoltarea abilităților
managerilor de proiecte interne care nu erau formal conectați cu PMO-ul. În versiunea extremă a PMO-ușor,
toate proiectele operau sub controlul organizațional, iar proprietatea proiectelor reieșea din grupul însărcinat
cu executarea proiectului, format din aria funcțională și IT. Au apărut multe discuții legate de ce variantă să
de adopte. Strider a vorbit despre această controversă:

Chiar acum, sunt patru oameni full-time...dată fiind viteza cu care vrem să ne mișcăm – noi ca
industrie trebuie să ne mișcăm – cred că patru oameni permanenți sunt prea puțini. Văd acești oameni
desemnați să asiste în proiecte importante, dar diversitatea aplicațiilor este prea largă. Nu văd toată mișcarea
de management în acest grup. Există o diferență de opinie între mine și PMO în acest moment despre asta.
Va trebui să găsim o cale de mijloc...sunt convins că ar trebui să fie ușor. Asta nu înseamnă că nu mă
îndoiesc, pentru că sunt foarte mulți oameni în acest departament care în mod constant mă provoacă. Ceea
ce este bine, nu am nevoie de o grămadă de oameni care să fie de acord cu mine.

În timp ce Nelson a fost de acord să lucreze cu o echipă mică la început, el simțea că întârzierile
provenite din această abordare ar putea compromite abilitatea lor de a furniza serviciile PMO și de a
demonstra valoarea acestora ariilor funcționale ale afacerii. Deși, el și ceilalți manageri au recunoscut că
resursele nu erau gratuite și că trebuiau să vină de undeva, ceea ce însemna reducerea capabilităților de
muncă ale cuiva pentru a le avansa pe ale sale. Strinder s-a chinuit cu această provocare și cele patru
resurse PMO au fost furnizate la prețul altor echipe operaționale. Chiar dacă Nelson lucra cu aceste limitări,
el spera să primească mai mult ajutor. Nelson a explicat:

Dacă nu aș avea constrângeri mi-ar plăcea să fiu capabil să formez rapid echipa din oameni care să
fie analiști de proiect sau manageri. Să aduc un grup de oameni în față. Mulți dintre ei ar putea fi noi la
început. Apoi, pe parcurs, poți să te dai la o parte de restul organizației. Ei toți ar face parte din PMO. Așa că
am avea grade variate de experiență, de la oameni care au fost manageri de proiect până la cei care au fost
juniori. Am putea obține atât de mult, doar făcând acest pas.

Steinberg era îngrijorat de resursele necesare și cum ariile funcționale ar putea percepe introducerea
mai multor oameni în același timp. El a explicat: ,,Ce implică un sponsor pe vânzări să încerce să inițieze un
proiect care primește aprobare de la PMO? Ei nu înțeleg în totalitate ce este PMO-ul. Ei consideră că este
un obstacol în calea progresului.”

Îngrijorarea lui Steinberg legată de cum oamenii ar putea vedea PMO-ul era împărtășită de către
Strider. Deși Strider era convins că PMO-ul era pe drumul cel bun pentru AtekPC, el știa că de asemenea
trebuia să se asigure că IT-ul își păstra ritmul și că își făcea treaba. Cum Strider a explicat:

Acum, dacă adaugi oameni, unde îi adaugi? Faptul că îi poți adăuga este o descoperire. Îi adaugi în
acest PMO sau îi adaugi în altă parte?...întrebarea este cum mergi unde trebuie să mergi, dar fără să încalci
cultura atât de mult încât să primești un steag roșu... Pentru că PMO-ul nu poate să facă proiectul. Ei nu vor
scrie codul; ei nu vor instala servere; ei nu se vor întâlni cu utilizatorii care înțeleg cerințele funcționale; ei nu
se vor întâlni cu clienții.

În prima fază, Star obținea niște informații prin bârfe despre acest nou PMO și încerca să pună cap
la cap ce auzea astfel încât ea să fie gata să se adapteze la orice schimbări noi. Ea în mod sigur spera să
6
primească mai mult ajutor, în special cu ceea ce ea a văzut ca ,,lucruri administrative” în proiect. Ca șef
analist, ea trebuia să gestioneze multe probleme de managementul de proiect și ea era conștientă de
oportunitatea creată de PMO pentru ea. Ea aștepta să învețe să fie mult mai eficientă ca manager de proiect,
dar ea nu era sigură ce se întâmpla cu adevărat. Ea a descris ceea ce a înțeles despre PMO:

Am crezut că ar fi o idee bună pentru că m-am gândit la acel moment că acesta urma să fie un grup
care va realiza diferite proiecte și ei vor fi managerii de proiect. Și atunci noi am fi fost echipa lor. Am presupus
că ce s-ar putea întâmpla este că aș fi încă în funcție – șeful – pentru acel proiect, pentru grupul care lucra.
Dar, în esență, aș fi răspuns în fața managerului de proiect care avea abilitățile, cunoștințele, pregătirea și
instrumentele pentru a ne ajuta să mergem mai departe. Asta pentru că istoricul meu în managementul de
proiect este format din procesele create de mine și de instrumentele pe care mi le-am făcut pentru a crea,
analiza și pentru a ține evidența. Așa că, m-am gândit, ei vin cu toate acele instrumente și, în cele din urmă,
ne vor învăța; și în cele din urmă noi vom fi manageri de proiect care pot fi independenți.

Gardner, managerul lui Star, avea așteptările ca modelul PMO-ului avea să fie mai mult greu decât
ușor. El era deja convins de meritele PMO-ului de la utilizarea ideii de a aduna cererile de proiect. Ceea ce
înțelegea el era că PMO-ul putea să furnizeze un fond comun de resurse de managentul de proiect. El a
vorbit despre viziunea lui asupra modelului organizațional:

Ei se mișcă doar pentru a ne ajuta cu metodologia pentru proiecte...ei se gândesc la un fond comun
de manageri de proiect. Poți avea un astfel de proiect și poți împrumuta acea persoană pentru o perioadă.
Și proiectul tău le-ar răspunde lor. În instanță, noi folosim unul acum pentru această nouă lansare de proiect
în plus față de proiectele pe care le avem acum. Ea începe să preia controlul asupra planificării timpului,
programării, adunarea oamenilor potriviți și asigurării că toți oamenii sunt informați – sarcinile tipice ale lui
manager de proiect... Atâta timp cât managementul de proiect este în desfășurare, proiectul este
responsabilitatea ei. Este slujba ei.

În viziunea lui Gardner, el ar putea menține controlul asupra proiectului și pentru durata acestuia,
managerul desemnat din angajații PMO ar respecta deciziile sale. Resursele ar putea fi desemnate într-o
structură matriceală pe durata proiectului. Asta este ceea ce făcea Gardner prin manager de proiect actual
al PMO-ului, care a fost desemnat unuia dintre proiectele sale și, în opinia lui Gardner, acesta era un mare
ajutor, pentru că el avea prea puțini oameni și o grămadă de proiecte de realizat. Gardner se aștepta ca
PMO-ul să umple grupul lui cu manageri de proiect într-o manieră similară PMO-ului greu.

Pe de altă parte, Field a recunoscut că problema structurii PMO nu era legată doar de angajații IT:

Problema cu PMO-greu nu este doar legată de aducerea unor manageri și analiști. Este și despre
resursele companiei. Azi, avem manageri care lucrează pe multiple proiecte în plus față de slujbele lor
obișnuite și nu mai rezistă mult. Ceea ce conduce multe proiecte într-o companie este disponibilitatea
resurselor companiei pentru a lucra în acele proiecte. Disponibilitatea resurselor este deja o problemă pentru
noi. Cu un PMO-ușor suntem mai bine aliniați cu numărul resurselor și este mult mai bine balansat.

Nelson favoriza PMO-greu spunând că este cel mai bun model pentru AtekPC, dar a recunoscut că
nu ar fi capabil să obțină acceptarea imediată pentru această abordare. Cererea pentru resurse era mare în
AtekPC și PMO-ul trebuia să-și demonstreze valoare pentru a obține resursele pe care le voia. El intenționa
să obțină suport pentru modelul PMO-greu prin succesele proiectelor. Cum PMO-ul a câștigat acceptarea,
el a vrut să implementeze o abordare PMO-greu, aducând manageri de proiect în proiecte variate. Așa cum
el a spus:

Cum AtekPC a căutat să găsească modelul organizațional corect, echipa PMO lucra să livreze
serviciile care care le construiau încet credibilitatea și care le dovedeau valoarea în fața AtekPC. Găsind
locul potrivit pentru PMO între greu și ușor, modele organizaționale erau o tensiunea continuă care trebuia
să fie rezolvată mai devreme sau mai târziu. Cu mai multe resurse, Nelson credea că echipa lui putea furniza
mai mult suport și mai rapid cu proiecte și standarte. Pe de altă parte, Strider i-a amintit lui Nelson că PMO-
7
ul era una dintre responsabilitățile organizației de IT. Existau alte nevoi pentru resurse cu propriile justificări
și rambursare. Totuși, problema lui PMO-greu versus PMO-ușor nu era o decizie simplă sau ușoară.

Implementare și cultură

AtekPC era implicat într-o provocare dificilă prin încercarea de a implementa metode standart într-o
organizație care nu era obișnuită cu procesele disciplinare și standardizate. Managementul de IT a realizat
că în viitor ei vor depinde de standarte și de procese consistente pentru a gestiona proiectele lor. Cu toate
acestea, implementarea PMO-ului într-un mediu non-management de proiect a fost o provocare, pentru că
a mers împotriva culturii organizaționale. Mulți oameni din AtekPC au văzut managementul de proiect ca pe
ceva administrativ – ceva care inevitabil ar putea interveni în modul în care se face treaba reală. Field a
descris provocarea culturală:

Ne mutăm de la o companie care nu a avut un management de proiect real la o companie care ar

prefera să fie foarte formală. Intenționăm să fim undeva la mijloc. Nu putem fi atât de rigizi legat de
managementul de proiect. Această cultură nu ne va lăsa să facem asta. Trebuie să mixezi cultura cu
metodele și procesele și acum chiar aud unde procesele nu pot fi atât de rigide. Dacă devenim prea rigizi, va
fi un eșec. Trebuie să fim puțin fluizi și dinamici din când în când și asta îi deranjează pe unii oameni din
PMO, dar trebuie să o facem în felul acesta. Pentru a reuși, trebuie să dezvoltăm o organizație care va fi
flexibilă și care va fi precisă în raportări. Așadar, asta este lupta mea – potrivirea managementului de proiect
într-o cultură care se schimbă dar care nu este încă gata.

Forțele care se opun PMO-ului păreau copleșite din când în când. Strider s-a întrebat cât de dispusă
ar fi organizația IT să-și schimbe procesele și să se adapteze la noile practici de management. Aceasta era
o problemă culturală în mintea sa. Mulți dintre angajați, inclusiv manageri aveau puțină experiență sau deloc
cu practicile formale de management de proiect. Foarte puțini știau cum să folosească instrumentele
software, cum ar fi Microsoft Project. În plus la aceste bariere ale cunoștințelor, partea informală a acestor
practici i-a atras în mare măsură pe oameni. Ariile funcționale au lucrat bine cu oamenii de pe IT care erau
receptivi la nevoile lor și făceau lucrurile repede. Angajații IT, de asemenea, au găsit partea informală
atrăgătoare de când nu se urmăreau costurile și se înregistrau recordurile de performanță. Ariile funcționale
nu erau responsabile pentru măsurarea beneficiilor rezultate din proiectele lor, iar angajații din IT nu lucrau
cu un buget desemnat pentru proiect. O altă sursă de rezistență a fost lipsa de înțelegere a tuturor nivelelor
de valoare a managementului formal de proiect. Toate aceste surse de rezistență au creat bariere culturale
care au oprit succesul PMO-ului.

Strider a înțeles multe dintre aceste bariere culturale și a recunoscut că trebuia să găsească căi de a
le depăși dacă PMO-ul avea să supraviețuiască. Într-o discuție recentă în jurul mesei din biroul său, el a
rezumat situația: ,,Opinia mea este că avem două opțiuni. Mă pot conforma culturii și să supraviețuiesc; sau
pot lupta împotriva culturii și să eșuez...Poți doar să înoți în direcția curentului, indiferent de cât de bun sau
deștept ești. Dar, dacă lupți împotriva culturii la fiecare pas, tu vei pierde.”

Pentru acum, strategia de implementare a PMO-ului la AtekPC era să se plieze pe cultură și să

dezvolte forțe care să promoveze PMO-ul și să depășească rezistența culturii. Forțele de susținere includeau
mentoringul, coachingul și trainingul care erau oferite de echipa PMO. Compania era clar sub presiune să
schimbe modul în care făcea afaceri, dar nu exista un consens între managerii seniori în ceea ce privește
gradul în care PMO-ul era integral procesului de schimbare. În opinia lui Strider, era prea devreme pentru a
aplica o autoritate formală fără dovezi de valoare și fără mai mult suport pentru conceptul PMO. El credea
că era necesar să fie cumpărată mai multă intrare de la ariile funcționale. Una dintre problemele culturale era
cât de repede ariile funcționale ar fi dispuse să adopte un proces mai formal. Ei trebuiau să fie dispuși să
prioritizeze proiectele și să ia cele mai grele decizii și compromisuri. În anumite cazuri, pentru a înainta un
proiect, ei trebuiau să fie dispuși să ajute cu justificarea resurselor adiționale.

8
 Nelson lucra pentru a crea intrarea ariilor funcționale prin utilizarea echipei lui pentru a furniza
mentoring și management de proiect direct pentru proiectele cheie. El a recunoscut că această strategie de
implementare era o muncă înceată și care necesita răbdare. Pentru el, lupta era despre crearea și livrarea
succesului dovedit. El a explicat provocarea așa cum a văzut-o:

Nu o pot numi de jos în sus (abordarea lui de implementare), pentru că avem aprobarea de sus. Dar
este ca și cum ar fi aproape în vârf, dar nu chiar acolo... este văzută ca birocratică sau este văzută ca având
potențialul de a fi birocratică. Asta este din cauza industriei și ale cadrelor sale – scoate produsele afară,
introduce ordinele. Unul din lucrurile pe care le-am auzit de sus este ,,doar nu lăsa acest management de
proiect și proces de management să încetinească lucrurile. Toate acesea sunt lucruri minunate și vrem să le
vedem că funcționează; doar nu le lăsa să-mi intre în cale.”

Ca director al dezvoltării de aplicații, Steinberg a fost unul dintre primii sponsori ai PMO-ului și el a
văzut ceva progres în trecerea prin aceste bariere culturale. Când Steinberg a venit pentru prima dată la
AtekPC, el a primit sarcina de a implementa o metodologie de dezvoltare a unui software standard. Acel efort
timpuriu a fost un eșec, în opinia lui, deoarece cultura nu era potrivită pentru o abordare disciplinată. Acum,
el susținea cu încredere efortul PMO și a adus o înțelegere profundă a culturii companiei și a provocărilor
acesteia. În viziunea lui, doar prin lucrarea cu aceste grupuri de afaceri cineva într-un moment poate să-și
cumpere intrarea în PMO. El și-a explicat abordarea:

Vânzarea PMO-ului din IT este o problemă. Oricât de mult aș fi încercat să obțin niște vizibilitate în
afara acestui departament, nu am fost capabil să obțin vreo vizibilitate oficială. Ceea ce s-a întâmplat este
că am început să îi implicăm pe oameni în proiecte și să le trimitem utilizatorilor implicați în asta. Fabricația
a fost una dintre primele arii. Persoana care este purtătorul de cuvânt pentru proiectele IT în fabricație a spus
,,ce se face în acest PMO?” când i-am spus despre ce este de acord a vrut imediat să se implice. Același
lucru s-a întâmplat și la vânzări.

Nu este atât de bine primit în anumite grupuri, dar din fericire este în unele arii...fabricația este
implicată și vânzările încep să se implice. Dar nu sunt sigur că celelalte arii funcționale vor să se implice în
totalitate, încă.

Cu suportul unor arii funcționale, echipa PMO a continuat eforturile de implementare. Așa cum a
remarcat Nelson, avansarea lor în date s-a făcut cu pași de bebeluș. Frustrarea unui progres atât de plictisitor
i-a tentat să considere o abordare alternativă – să forțeze schimbarea cu mandate de sus în jos și prin
angajarea de experți. Câțiva manageri, încluzându-i pe aceia implicați direct cu PMO, au recunoscut nevoia
unui număr mai mare de experți pentru a construi standarde și metode rapid și ei au susținut o strategie mai
rapidă cu o implementare intensivă pe resurse. O astfel de abordare i-ar permite PMO-ului să-și demonstreze
valoarea prin gestionarea activă a mai multor proiecte și ajutarea companiei să obțină o performantă mai
consistentă și mai bună pentru proiecte. Managementul de It era îngrijorat că o astfel de abordare ar putea
eșua pentru că ei nu ar fi putut să forțeze o schimbare radicală la AtekPC. În plus, managerii seniori de IT au
încurajat o strategie înceată care să permită conceptul PMO să-și demonstreze valoarea cu mici victorii
câștigate prin mentoringul unui proiect la timpul potrivit.

Guvernanță

Problema guvernanței PMO nu era discutată pe larg, dar avea deja importanță. În prezent, nu existau
mape pentru maturizarea sa, deci nu exista o cale de a măsura performanța PMO în afară de opiniile
subiective a celor implicați. Acolo era un sens că AtekPC ar ști dacă PMO-ul funcționa, dacă proiectele erau
duse la sfârșit și compania primea ceea ce-și dorea. Field a luat la cunoștință că erau câteva măsuri pentru
proiecte sau pentru PMO. El a explicat:

Cum ne măsurăm pe noi? Cum măsoară succesul o organizație bazată pe proiect? Una dintre
îngrijorări a fost managementul de proiect, din cauza birocrației, care încetinea lucrurile. Încă mai sunt
îngrijorări legat de asta. Noi încercăm să spunem că noi chiar vom face lucrurile mai rapid și vom termina
9
lucrurile mai repede cu mai puțină muncă. Deci cum ne măsurăm pe noi pentru a putea spune că reușim?
Noi încă nu am legat toate acele măsurători încă.

Determinând cum să dovedească valoarea PMO-ului a fost cea mai mare provocare a lui Nelson:
,,Demonstrarea valorii este singura cale pentru a face lucrurile să meargă. Și asta are să fie greu pentru că
nu există o colecție de date. Dar chiar dacă ar fi, trebuie să fim capabili să arătăm progresul.”

Având această abordare de a măsura performanța PMO-ului prin consens subiectiv și date
anecdotice, următoarea problemă guvnamentală a fost stabilirea cui era PMO responsabil. Pentru moment,
îi era raportat lui Steinberg, directorul de dezvoltare a aplicațiilor, deoarece, în opinia lui, avea experiență cu
metodologiile și standardele. El a explicat câteva din opțiunile curente de guvernanță:

Pe moment mi se raportează mie pentru dezvoltarea aplicațiilor, dar chiar cred că ar trebui să se facă
în altă parte...cheia este că am fost văzut ca persoana care să înceapă. Cred că la un moment dat ar fi mai
corect să se raporteze în altă parte – dacă nu la CIO, în altă parte în organizație...cred că este o posibiltate
să se raporteze ori la vice președinte, ori la biroul de planificare.

Strider a recunoscut că modelul curent de guvernanță era doar temporar și a explicat viziune sale:

Singurul motiv pentru care putem obține o stabilire pentru PMO este pentru că există un birou de
planificare pentru companie și vice președintele este dedicat unei abordări mai planificate și mai riguroase.
Nu aș putea să conduc asta intern prin IT doar dacă aș avea suportul... chiar acum, raportarea se face la
șeful dezvoltării aplicațiilor. Eu și Steinberg am vorbit despre asta de-a lungul timpului, probabil PMO-ul îmi
va raporta mie direct. Dar sincer, nu am timp acum...există și biroul de planificare care nu-mi raportează mie.

Înțelegând această interacțiune strânsă între noul birou de planificare și PMO, Steinberg și-a
împărtășit îngrijorarea de a rămâne în IT.

Cred că atâta timp cât aceasta rămâne un element, o parte divizată în IT, va mai exista partea de
,,noi-ei” și sentimentul că noi suntem acolo pentru a reuși... am muncit cu aplicațiile de grup și au fost un
succes. oamenii vor mai multe. așa că speranța mea este că vom avea suficient spațiu aici pentru a începe
cu PMO și pentru a arăta beneficiile acestuia. Asta se va vinde și altor atii și îi va permite să continue să
trăiască.

Hotărând cum să progresăm cel mai bine

Industria PC se schimba și AtekPC era ocupată cu rezolvarea unor presiuni dramatice din partea unor
competitori mai mari, cum ar fi HP, Dell și Lenovo. Pentru a concura în schimbarea industriei în care
consolidarea avea loc, AtekPC a implementat un birou de planificare. Recunoscând rolul pe care IT-ul ar fi
fost probabil să îl joace îi permitea companiei și să răspundă presiunilor industriei, vice președintele a susținut
crearea PMO-ului în IT. Rolul PMO-ului ar putea fi extins să includă proiecte non-IT dacă s-ar dovedi de
succes. În același timp, exista o posibilitate ca PMO să eșueze din cauza provocării de a implementa o
abordare atât de măsurată și disciplinată într-un mediu în care asta era văzută străină de cultură. Până la
urmă, AtekPC era o organizație care era obișnuită ca oamenii să se grăbească să facă orice era necesar
pentru a construi produse în fiecare zi.

Implementarea PMO-ului deja stârnise câteva probleme, unele care s-au dovedit a fi prea
controversate pentru a putea fi rezolvare imediat. AtekPC simțea drumul de-a lungul efortului pentru PMO.
Cum ei au încercat să elaboreze un acord pentru probleme de bază ale PMO-ului, toți oamenii din organizația
IT erau conștienți de provocările cărora trebuiau să le facă față și de riscurile asociate eșecului. Proiectele
eșuau repede. Succesul ar depinde în întregime de deciziile și de eforturile lor și asta era un motiv de
îngrijorare pentru toți.

10
 Traficul era blocat când Strider conducea pe autostradă încercând să iasă din Metropolis și să ajungă
acasă la familia lui în acea seară. Avea timp să reflecte din nou asupra PMO-ului. Și-ar fi îndrumat echipa de
management pentru implementarea strategiei. Era încredințat că modelul PMO-ușor era cel mai bun. A avut
rețineri de a mai angaja oameni full time pentru PMO. Era îngrijorat de multe probleme pe care implementarea
PMO le-a adus. Putea fi treaba terminată destul de repede prin pași mici construind pe succese mici? Se
gândea în timp ce aștepta să se schimbe culoarea semaforului: Cum pot ajunge acolo unde avem nevoie să
mergem fără să încălcăm cultura atât de mult încât să atragă un steag roșu?...simt că trebuie să o fac în
modul în care o fac deja, în loc să încarc un mare PMO și să spun ,,acesta este PMO-ul meu”.

Teme propuse pentru discuție:

1. Care este scopul și misiunea implementării unui PMO?

2. Care sunt provocările și obstacolele implementării unui PMO?
3. Care sunt factorii organizaționali care influențează succesul implementării PMO?
4. Propuneți trei măsuri prin care să se îmbunătățească implementarea PMO la AtekPC.

11
Anexa 2 AtekPC „Formularul unei Idei”

FORMULARUL DE DEZVOLTARE AL UNEI IDEI

Secțiunea A. (Solicitantul completează această secțiune) Numele proiectului:

Data la care a fost înregistreată cererea:

Numele sistemului (dacă se cunoaște):
Data limită la care este necesară:

Secțiunea B. (Recenzorul completează această secțiune)

□ Aprobat
Recenzorul ideii: □ Neaprobat – Motivul pentru care
Data recenziei: nu a fost aprobat
ID-ul proiectului:

Secțiunea C. Tipul lucrării/muncii (Recenzorul completează această secțiune)

□ Intensificată □ Urgență □ Fix (stabil)

Secțiunea D. (Solicitanul completează această secțiune)

1. Asigurați o descriere (Despre ce este vorba?)

2. De ce ar trebui să facem asta? (Explicați valoarea afacerii și selectați cel mai apropiat tip de
beneficiu) Explicație:

Tipul de beneficiu (puteți selecta variante multiple) Estimați dacă este posibil
□ Creea venituri Venituri anuale estimate: ____________
□ Evitarea costurilor Costuri evitate estimate: ____________
□ Economii de costuri Economii anuale estimate: ___________
□ Siguranță operațională
□ Îmbunătățirea serviciilor cu clienții
□ Îmbunătățirea calității

3. Scopul (Descrieți ce include și ce este exclus)

4. Livrabile (Modificări de rapoarte, new screen, data de intrare, etc.)

5. Departamentele afectate/ Clienții afectați



6. Ipoteze


7. Proiecte asociate


8. Riscul/Impactul provocat de nerealizarea proiectului



Sursă: AtekPC.
12
 CIO
John Strider

Director - Dezvoltarea
Director
aplicațiilor
Tehnologie & operații
Richard Steinberg

Director de Proiect
Înlocuirea avansată a
Manager de vânzări Grup de suport Manager de comunicare sistemului
Manager de producție Manager Financiar
management al grupurilor de muncă
Project Manager
Larry Field

Analist lider Director PMO

Linda Starr Mark Nelson

Analist lider Project Manager

Project Manager

13