Agile Earned Value Management

Postat la iunie 11, 2013 de ThePMJournal

Earned Value Management (EVM) descris de PMI in PMBoK este o tehnica de masurare a performantei si progresului proiectului intr-o maniera obiectiva. Desi EVM implica trei arii de cunoastere din project management: scope, schedule si cost, cand vorbim in general despre EVM ne referim la managementul bugetului. Este bine stiut ca EVM ofera una din cele mai eficiente metode de control si predictibilitate in cadrul dezvoltarii de proiecte. Din cauza complexitatii metodei, EVM este folosita in general in proiecte mari, gestionate „ca la carte” folosind o abordare traditionala de gestiune a proiectelor descris in PMBoK. Intrebarea este: Oare framework-ul Agile poate avea metode la fel de eficiente de predictibilitate si control asupra precum EVM-ul din PMBoK?

In general, oamenii „Agili” nu isi bat capul cu bugete si calcule complicate de predictii, pentru ca ei sunt genul de oameni care spun: „Decat sa facem planuri, estimari si predictii, mai bine muncim!„. Si e perfect just! Dar managerii vor ca afacerea pe care o conduc sa fie foarte predictibila, sa fie estimabila si sa arate foarte bine pe hartie (in cifre). Agile nu ofera prea multe cifre, mai ales in bani, asa cum poate orice manager de companie si-ar dori sa vada. Intr-o companie, cu model de afacere „Agile”, nimeni nu se intreaba: „Cati bani vom cheltui pe acest proiect?” ci se intreaba: „Cate Punte/Sprint va arde echipa?„.

Desi multe organizatii au implementata o metodologie Agile (de obicei Scrum), in practica, foarte putine sunt „100% Agile”. Iar acest lucru nu e datorat doar rezistentei la adoptie a culturii Agile din partea echipelor, dar si datorita faptului ca Agile nu poate fi implementat la toate nivelurile organizatiei.

Implementarea Agile la toate nivelurile unei organizatii este uneori imposibila datorita discrepantei intre ce doresc cei din managementul superior (un control absolut al tuturor cheltuielilor in cadrul proiectului) si ceea ce pot oferi echipele Agile (un control relativ al bugetului). Cei mai multi manageri de top nu au nici cea mai vaga idee ce reprezinta Agile, dar vor cu orice pret sa implementeze Agile in companiile lor deoarece este noul trend in industrie despre care se spune ca „mareste eficienta echipei”. De asemenea, managerii prefera un mediu Agile deoarece o parte din responsabilitatile lor (legate de activitatile de monitorizare si control) sunt transferate echipei.

Asadar, aproape toti managerii au implementat un framework Agile in compania lor, dar foarte putini isi conduc afacerea intr-o maniera „Agile”. La nivel de top management a ramas acelasi management de tip traditional, pe cand la nivelurile de jos si medii de management exista o cultura new age de tip Agile, libera si nebirocratica. Avand acest tip de organizatii semi-Agile, maangerii au decis sa imparta responsabilitatile in felul urmator: „Hei voi din echipa! Fiti Agile, livrati repede, auto-organizati-va! Legat de bugetul proiectelor, voi voi veti lucra cu Puncte Agile (sau cum vreti sa ii numiti), iar de restul finantelor ne ocupam noi!”. Acest lucru a bucurat pe toata lumea: angajatii s-au aratat fericiti deoarece se bucurau de libertate de organizare: fara intaliniri prea multe cu cei din conducere, fara rapoarte legate de buget si fara planuri elaborate. De asemenea, cei din management s-au aratat incantati deoarece aveau mai mult timp pentru ei, iar echipele aveau nevoie de mai putina supraveghere.

Pana acum, totul suna perfect, cu o singura exceptie: din cand in cand, managerii de top trebuie sa realizeze niste previziuni de buget pentru proprietarii companiei si asta inseamna ca echipele Agile vor trebui sa furnizeze cifre cu costul de „ardere” si previziuni legate de costul proiectelor.

Iata ce fel de cifre poate oferi echipa Agile

In Agile cea mai practicata forma de control si predictie a proiectului este Burndown Chart. Acest grafic poate sa ofere urmatoarele informatii: „ce s-a facut„, „cat mai este de lucru„, „ideal, cat ar fi trebuit sa fie facut„. Pentru un proiect mic, estimarile „ore lucrate”, „zile ramase de lucru” sunt bazate pe unitati de masura relative numite „Punte Agile” si, chiar daca estimarile sunt grosiere, sunt suficient de satisfacatoare pentru cei din conducere. Insa, in cazul in care graficul BurnDown arata destul de „urat” (indicand intarziere a livrabilului catre client), cu siguranta un manager de top va cere estimari detaliate in unitati de masura absolute, cum ar fi bani. Mai mult va cere si o serie de explicatii: Care va fi bugetul la final, tinand cont de graficul actual? Daca ar fi sa oferi un raspuns doar pe baza Burddown Chart-ului din Agile, putem sa tragem o linie intre coordonatele actuale ale graficului si pe baza pantei de ardere medii, vom putea estima data de sfarsit cea mai probabila a proiectului. Stiind timpul necesar terminarii proiectului si costul de ardere mediul al echipei in Puncte (o valoare relativa bazata pe istoricul proiectelor), se poate obtine cat va fi bugetul proiectul la final. Pe langa faptul ca aceasta metoda de calcul a bugetului este grosiera, ne va fi destul de greu sa convingem un director financiar cum am ajuns la aceste rezultate.

O alta metoda de „forecast” a bugetului

Previziunile de buget pe baza parametrilor EVM este folosit la scara larga atat in organizatiile guvernamentale cat si in corporatii. Datorita notorietatii metodei EVM, dar si abordarii holistice asupra bugetului (EVM include toate costurile operationale, pe cand BurnDown chart-ul din Agile include doar o parte a costurilor operationale), tehnica EVM este mai potrivita pentru a realiza rapoartele de buget.

Cum ar putea fi calculat parametrul EAC (Estimated at Completion) din EVM in Agile? Sunt cateva metode de a calcula EAC. De exemplu, daca stim cati bani au fost alocati la inceputul proiectului (Budget at Completition sau BAC parameter in EVM) si considerand costul de ardere aproximativ constant (cum de obicei se intampla, dupa cateva iteratii), putem afla instant cati bani vom cheltui pana la sfarsitul proiectului: EAC=BAC/CPI (voi arata in continuare cum se obtine Cost Performance Index sau CPI din EVM).

In Agile proiectul nu se masoara in bani, ci intr-o unitate de masura relativa numita Puncte, insa daca avem numarul de puncte „arse”, prin conversie din Puncte la ManDays (sau ManHours) si apoi din ManDays in bani, se poate cuantifica bugetul proiectul si in bani (valorile parametrilor EVM). Pentru a realiza acest lucru, trebuie sa stim doar conversia dintre Puncte si ManDays (sau ManHours). Conversia se poate obtine fie pe baza istoricului proiectelor anterioare, fie pe baza iteratiilor terminate. Bineinteles ca bugetul unui proiect nu se masoara numai in „cati bani arde echipa de dezvoltare„, ci cuprinde si alte costuri cum ar fi: costuri operationale, costuri administrative, etc. Pentru un proiect Agile, care implica de obicei o echipa mica, bugetul poate fi aproximat doar in ManDays, iar restul costurilor alocat riscurilor, echipamente de lucru, transport, electricitate, etc. poate fi inglobat cu usurinta in costul ManDays al unei resurse.

Conversia intre Puncte si ManDays

In organizatia in care lucrez conform istoricului proiectului, conversia intre Puncte si ManDays este urmatoarea:

Conversia dintre Puncte si ManDAys nu e liniara. Valoarea Punctelor sunt de obicei valori discrete din sirul lui Fibonacci (folosim Fibonacci, deoarece in Agile, estimarile din prezent iau intotdeuna in considerare estimarile din trecut: istoria proiectului, complexitatea user story-urilor trecute, etc; in mod similar, numerele Fibonacci sunt calculate pe baza ultimelor doua valori din serie:  F(t)=F(t-1) + F(t-2)).

Avantajul conversiei de Puncte ManDays este faptul ca echipele de dezvoltare pot sa ofere estimari fie in Puncte, fie in ManDays, dupa cum le e mai usor. Personal prefer estimarea in in MandDays. Pentru a calcula parametri EVM, va trebui sa culeg pentru fiecare livrabil(user story), la sfarsit de iteratie, urmatoarele informatii: cat % din livrabil este complet (vezi tabelul de mai jos: coloana % Work Completed). Pentru a afla cat % este complet, ma folosesc exclusiv de feedback-ul clientilor (sau al key stakeholderilor) conform criteriilor de acceptanta al fiecarui livrabil. Va rog sa observati ca un Product Owner nu poate decide de unul singul „% completed”, decat daca el are autoritate desemnata din partea clientului (clienti externi sau Sponsor) sau Product Owner-ul este clientul insusi.

Deci daca vreau sa obtin „% completed”: este livrabilul complet sau incomplet (pentru a simplifica decizia putem folosi regula „0/100”: un livrabil este considerat complet, daca indeplineste 100% criteriile de acceptanta si incomplet (0% complet), daca nu indeplineste toate criteriile de acceptanta).

Nota: Regula „0/100” este o regula de tip „totul sau nimic”. Daca un livrabil nu e total complet, chiar daca e facut in proportie de 99%, este considerat 0% complet. Putem folosi de asemenea regula „20/80” (un livrabil este considerat 20% complet, daca lucru e in progress) sau regula „50/50” sau o combinatie de reguli daca e necesar. Regulile se pot stabili prin contract (cu clientul) sau la nivel de organizatie. Personal nu folosesc nici o regula predefinita ci prefer sa culeg exact „% completed” chiar daca acest lucru presupune mai mult timp (pentru a obtine un procent cat mai apropiat de realitate, trebuie sa existe cat mai multe criterii de acceptanta, iar fiecare criteriu sa fie: independent, masurabil, fezabil, etc).

EVM parameters

Tehnicile EVM si Agile BurnDown chart  folosesc aceleasi principii pentru a calcula costul curent si viitor al proiectului. Probabil va intrebati: Ce poate oferi EVM in plus fata de BurnDown chart? Hai sa aflam raspunsul.

Stiind ce este complet si ce e incomplet (% work completed” in ManDays), putem calcula Earned Value (EV) al fiecarui livrabil (EV este un parametru din EVM si reprezinta cati bani valoreaza cu adevarat munca livrata).

In tabelul de mai sus, coloana „Original Estimated” se estimeaza in Sprint Planing, inainte de a incepe lucrul efectiv si este echivalent cu parametrul Planned Value sau PV) din EVM.

Exemplu. Sprintul numit „Sprint Alpha 20 june” are PV = 2 MD (ManDays), adica 2 ManDays estimate initial, dar nu toate livrabilele au fost considerate facute(100% complete) conform criteriilor de acceptanta. In acest caz Earned Value = EV = 1 MD. Stiind EV si PV, putem calcula alti parametri EVM: Schedule Variante (SV)=EV – PV=-1 si Schedule Perfomance Index (SPI) = EV / PV=0.5.

De ce e important SPI si SV?

Deoarece raspunde la intrebarea: Care e viteza de implementare? Noi progresam la [SPI] % din cat ne-am planificat. Daca SPI<1, atunci putem spune ca suntem in urma cu executia si daca continuam in acelasi ritm com depasi deadline-ul, daca SPI>1 atunci suntem inainte cu dezvoltarea si am putea finaliza proiectul inainte de deadline. SPI=0.5, inseamna: Progresam la 50% din potentialul nostru.

Costul real al livrabilului

Pana acum in calculele noastre ne-am folosit doar de valoarea Planned Value si Earned Value, pe care le-am  fi putut obtine si din datele graficului Burndown Chart-ului. Acum, presupunem ca pe parcursul iteratiei s-a facut overtime sau a fost necesara achizitia unui nou echipament sau a fost necesar trainingul unui coleg, iar toate aceste activitati au presupus costuri suplimentare care nu au fost incluse in costul initial al proiectului. Costurile suplimentare ale proiectului (alte costuri decat cele asociate cu user storiurile) sunt de asemenea parte din costul proiectelor (Costul Real al proiectului).

Din nefericire, implicit, frameworkul Agile nu tine evidenta parametrului Cost Real al proiectului (in EVM poarta denumirea de Actual Cost sau AC), deoarece predictiile de buget in Agile sunt bazate doar pe taskurile ramase (costul Backlogului, nu costul real al proiectului). Deoarece parametrul AC este unul din cei mai importanti parametri in predictiile de buget si din moment ce AC nu este calculat in Burndown chart, s-ar putea ca Burndown chart-ul sa nu fie cea mai potrivita metoda de predictie de buget in cadrul unui proiect.

In exemplul de mai sus, „Sprint Alpha 20 june” are Actual Cost (AC) = 4 MD (deoarece echipa a facut overtime). Stiind AC, am putea spune ca Cost Performance Index (CPI) din EVM. CPI = EV/AC = 1/4 = 0.25. De asemenea, un alt parametru important care se poate obtine este Cost Variance (CV) = EV – AC = 1 – 4= -3.

De ce este atat de important CV si CPI?

CV si CPI sunt importante deoarece pe baza lor putem raspunde la urmatoarele intrebari: Cati bani valoreaza cu adevarat proiectul nostru in momentul de fata? Ne vom incadra in buget? La prima intrebare putem raspunde astfel: Pentru fiecare [CPI] $ castigat, noi cheltuim 1$ (in exemplul de mai sus: pentru fiecare 25 centi castigati, noi cheltuim de fapt 1$). La a doua intrebare putem raspunde astfel: Daca [CPI] 1 (CV > 0), inseamna ca resursele si fondurile proiectului sunt folosite foarte eficient si ne vom incadra in buget. In exemplul de mai sus, resursele au un randament scazut deoarece CPI=0.25=25%.

Daca stim parametrul AC, putem calcula: Estimate at Completition (EAC) si Estimate to Complete (ETC) from EVM:

EAC se poate calcula in mai multe moduri, insa in cele mai multe cazuri se pot folosi formulele: EAC = BAC/CPI (daca stim ca CPI va ramane constant) sau EAC = BAC + AC – EV (avem un CPI putin probabil sa ramana constant sau sa reflecte desfasurarea ulterioara a proiectului).

ETC = EAC – AC. 

EAC inseamna: „Cati bani va costa proiectul la final?” si ETC inseamna: „Cati bani vom cheltui din acest moment pana la finalul proiectului?”

Agile EVM aplicat in practica

Am incercat sa aplic Agile EVM in 3 companii. Din nefericire, forecasting-ul si rapoartele pe baza de Agile EVM au avut un succes restrans. De exemplu, in F-Startup, raportul EVM nu a ajutat prea mult pe cei din top management sau pe clienti deoarece nu ii intersau prea mult previziunile de buget si rapoartele… In alta companie in care am lucrat raportul pe baza EVM nu a fost acceptat ca o medota folositoare de raportare, deoarece key stakeholderii nu au inteles teoria din spatele Managementului bazat pe „Valoarea Castigata” (Earned Value Management). Totusi, am avut succes cu Agile EVM intr-o companie de tip startup unde am putut optimiza costul operational pentru intreaga companie (parametri SPI si CPI au fost folositi nu numai la raportarea costurilor, dar au fost folositi ca si KPI-uri pentru evaluarea angajatilor. Tot datorita implementatii Agile EVM, compania a devenit constienta de importanta definitiei clare a criteriilor de acceptanta pe proiecte si a semnarii documentelor la livrare, estimarile pre-sales pentru clienti au inceput fie mai realiste (pentru ca pe baza lor se faceau predictiile de buget) si s-au salvat mii de ore de lucru prin crearea unor proceduri de raportare transparente catre/dinspre client si conducerea companiei despre cum s-au cheltuit banii pe proiect si la nivel de organizatie).

Iata un proiect simplu Agile. Contractul cu clientul a fost semnat pentru 1400 manhours, aproximativ 7 sprinturi (iteratii de 2 saptamani). Planul nu fost bazat pe o planificare Agile 100% deoarece bugetul e fix, scopul e fix, doar deadline-ul este negociabil. Estimarile incluse in contractul original au fost prea optimiste si ca urmare si planul de proiect initial a fost nerealist. When the project has been handover to me, the planning has already approved. But after the first demo review, I figure out there might be a problem with the deadline, the budget and possible with the scope itself.

La sfarsitul primei iteratii, am adunat urmatoarele informatii: Planned Value (pe Sprint au fost 160 manhours), Earned Value (pe sprint) = 128 manhours, Actual Cost = 116 manhours, proiectul a avut un Scheduled Performance Index = 80% (viteza echipei), Cost Performance Index = 110% (cati bani obtinem inapoi pentru fiecare dolar cheltuit). Asadar, dupa cum se vede din raport, doar 80% din munca a fost considerata „DONE” conform conditiilor de acceptare si pe baza feedback-ului clientului.

Acestea au fost concluziile mele:

• proiectul este behind the schedule (SPI=80%)
• am castigat mai mult pe livrabilele decat am cheltuit (CPI=110%, under the budget; fondurile au fost cheltuite eficient), dar suntem behind of schedule (SPI=80%). Asta inseamna, ca putem aloca resurse suplimentare pentru urmatoarele sprinturi (pentru aceiasi bani), in asa fel incat sa produca mai multa valoare castigata (Earned Value) si un parametru SPI mai mare.
• daca mentinem acelasi cost de performanta pana la sfarsitul proiectului, Estimated at Completion = BAC/CPI = 1400 manhours/1.1 = ~1270 manhours (proiectul va salva costul echivalent a 130 ore de lucru).
• daca mentinem aceiasi viteza de dezvoltare, munca ramasa va fi: BAC – EV = 1400-160 = 1240 manhours. Bazandu-ne pe viteza SPI=0.8,  numarul de sprinturi ramase va fi: BAC-EV/EV = 1240 manhours /128 manhour/sprint= 9.7 sprinturi. Deadline-ul ar trebui extins cu 2.7 sprinturi, sau va trebui sa planificam in lucru 206 manhours/sprint (fata de 160 manhours/sprint, cum e in momentul de fata).
• Raportul trimis catre client cu informatiile de performanta de cost CPI a fost irelevant, deoarece clientul vrea doar sa stie daca noi putem atinge deadline-ul (pretul proiectului a fost deja fixat), si am decis scoaterea parametrului CPI din raportul catre client. Dar CPI-ul, care arata daca suntem sub/peste buget (under/above budget), a fost extrem de folositor Sponsorului proiectului pentru ca a putut aloca mai multe resurse, pe aceiasi bani, pentru a putea adauga mai multa valoare castigata in proiect).

Nota: acesta este un exemplu in care performanta de cost (CPI) este irelevanta pentru client. Un alt motiv pentru care CPI-ul nu este inclus in raportele catre client este: companiile care vand „servicii Agile” in general ele vand disponibilitate, nu proiecte cu pret fix. Deoarece tu oferi doar „disponibilitate”, scopul si costul real al proiectului este nestiut, deci predictiile de buget sunt inutile. Intr-un mediu 100% Agile, poti face predictii de buget grosiere doar pana la un anumit nivel (depinzand de viteza de lucru cea mai mica si cea mai mare a echipei). Daca ai implementat recent Agile in compania ta, fii atent la termenii contractelor, pentru ca contractele ar trebui sa se bazeze pe disponibilitate, nu pe predictibilitate de cost. Implementand Agile cu clientii care nu inteleg filozofia Agile, poate fi periculos, deoarece, pe termen lung, poate impacta credibilitatea, satisfactia clientilor si poate chiar intregul model de afaceri al companiei.

SPI si CPI, KPI-uri pentru evaluarea angajatilor si al proiectelor

In trei din companiile in care am lucrat, una din responsabilitati era sa definesc KPI-uri de performanta pentru angajatii companiei. Ca un experiment, am incercat sa vad in ce masura parametrii EVM (SPI si CPI) pot evalua performanta angajatilor si al proiectelor. Am pornit cu un proiect pilot la care am colectat o serie de informatii pentru fiecare echipa/resursa/feature.

Pentru a vedea mai multe detalii despre cum se poate folosi AGile EVM in evaluarea angajatilor, al proiectelor si al operatiunilor, citeste EVM, KPI evaluarea personalului, proiectelor si companiei.

Agile EVM, un tool de raportare pentru top management

Daca majoritatea proiectelor Agile nu folosesc parametrul CPI, iata un proiect Agile in care CPI sunt importanti (proiect cu „scope” variabil, cost variabil, deadline fix, iteratie de 3 saptamani, sponsorul si clientul sunt interni si direct interesati de costul real al proiectului). Parametri Agile EVM sunt:

Nota: Efortul de realizare a acestui tabel este mic, deoarece se poate realiza in Excel din cateva clickuri la sfarsitul fiecarei iteratii, in sedinta de Sprint Review. Va rog sa remarcati de asemenea ca parametrul BAC (bugetul total alocat proiectului la inceput) nu s-a mentinut constant, deoarece in cazul nostru, la fiecare nou Sprint, scopul proiectului s-a schimbat si cost baseline-ul de asemenea s-a schimbat.

Astfel, pe baza datelor din tabel, se poate realiza, spre incantarea celor din top management, o serie de grafice foarte utile:

Pe baza datelor de mai sus, iata si o varianta de Burndown chart „personalizata”, numita sugestiv „Estimated to be Completed” pe baza calculelor EVM si a predictiilor Agile:

„Estimated to be completed” este un grafic care da bine in prezentarile din board. In exemplul de mai sus graficul ne „spune” ca: „pana pe 23 august vom avea 80-90% din produs livrat” (o informatie foarte utila, stiind ca la mijlocul verii, cand toata lumea e plecat in concediu, avem aproape tot proiectul finalizat cu aproape o luna inainte de deadline). Acest grafic da un sens de „liniste” si de completitudine organizatiei. Impactul vizual al graficului este mai puternic decat in cazul Burndown Chart-ul din Agile, care reprezinta grafic un trend descendent (Work Remaining vs. Time).

Acest grafic avand „in mod natural” un trend ASCENDENT (deoarece are la baza valorile acumulate ale zilelor lucrate si nu valoarea zilelor ramase de lucrat, asa cum este in Burdown Chart), in mod involuntar sugereaza ideea de „PROGRESS”, „EVOLUTIE”, desi in realitate este doar un „Burndown Chart inversat”.

In final, iata o alta varianta personalizata de burdown chart numita mai jos „Estimated to be Completed” (vs Total Work) obtinut prin insumarea valorilor EV pana la Sprintul curent. Graficul evidentiaza in timp, cand s-au produs schimbarile de scop (cereri de implementari noi, dar si momentul cand au fost eliminate functionalitati).

Conlcuzii

Dupa ce am aplicat Agile EVM in 3 companii (2 startup-uri si o companie middle-level), am invatat ca implementarea EVM si buna definire a KPI-urilor pentru EVM la toate nivelurile operationale, are urmatoarele beneficii:

Urmeaza: Managementul de tip reactiv si haotic.

Recomandari: EVM, KPI evaluarea personalului, proiectelor si companiei, Agile sub umbrela PMI