Prioritatile, o alegere logica!

Postat la octombrie 25, 2012 de ThePMJournal

Prioritatile de business ar trebui alese intr-un mod transparent, logic si consistent. Dupa cum am vazut in sedinta de Gathering Requirements, prioritatile de business in F-Startup se aleg, de obicei, dupa buna dispozitie a stakeholderilor cheie, fara nici un rationament.

In sedinta operationala am prezentat problema noastra:

-Cu tot respectul… Prioritatile pe care le-am stabilit pana acum au fost in functie de preferintele noastre individuale. Scopul nostru nu e doar sa stabilim doar prioritatile de business (Business Priorities), ci sa si justificam alegerea lor in relatie cu obiectivele noastre.

-Lasa deoparte „scopul nostru”! replica acid COO-ul. Ne-am adunat aici ca sa stabilim niste prioritati. In functie de impactul pe care il au, noi decidem prioritatile!

-Si cum stabilesti impactul asupra business-ului? il intreb.

-Treaba e simpla! Le stabilim si gata! Hai sa trecem mai departe, ca vreau sa plec mai repede acasa…

Oamenii confunda cu usurinta notiunea de „prioritati” (ordinea de lucru) cu cea a „importanta functionalitatilor„. Ca un mic experiment, am vrut sa aflu parerea key stakeholderilor legata de cum ar alege ei ordinea de implementare:

Care credeti ca este ordinea de implementare a celor 4 functionalitati de mai sus (T1, T2, T3, T4)? Iata ce raspunsuri am primit de la fiecare din key stakeholderi:

A). Ordinea e clara: le vreau pe toate sa fie facute in acelasi timp! raspunde CEO-ul.

B). Ordinea de lucru e data de prioritatea de business (coloana Business Priority) pe care am stabilit-o in sedinta de prioritizare: (T1, T2, T3, T4), spune COO-ul.

C) Ordinea de implementare nu e este data numai de prioritatile de business.

Desi teoretic varianta B este valida deoarece poate fi considerata o cerinta din partea unui stakeholder cheie, varianta C este varianta optima. Ordinea de implementare (prioritatea) depinde atat de prioritatile de business cat si de alte constrangeri ale proiectului (bani, timp, resurse, calitate, riscuri, etc).

Iata cum ar putea fi justificata alegerea variantei „C” in contextul managementului de proiecte: se stie ca orice functionalitate implementata implica un cost, asadar intrebarea de mai sus poate fi reformulata astfel:

Care este ordinea de lucru a acestor 4  functionalitati stiind ca echipa are un cost de ardere in valoare de „7” intr-o singura luna si care sunt functionalitatile care ar trebui implementate in prima luna de lucru?

Iar cele 3 raspunsuri de mai sus, cu un mic exercitiu de imaginatie, se pot traduce asa:

A). Spuneti-mi voi! spune mirat CEO-ul.

B). T1, T2, T3, T4. In prima luna ar intra T1, T2, e de parere COO-ul.

C). Este necesara o evaluare cost-beneficiu pentru a determina ordinea.

Evident Varianta B are si o explicatie logica: ordinea T1, T2, T3, T4 reprezinta ordinea importantei functionalitatilor din punct de vedere al businessului. In prima luna, se pot face T1+T2 = 6, valoare mai mica decat costul de ardere, in valoare relativa „7”, iar ordinea de implementare (prioritatile) poate fi: T1, T2, T3, T4. Insa aceasta solutie nu foloseste la maxim potentialul echipei. In prima luna, T1+T2=6 un cost de ardere mai mic decat costul ideal de ardere „7”, ceea ce inseamna ca ar mai ramane timp de implementare si pentru un alt task/functionalitate care sa aiba un cost de ardere in valoare „1”.

De aceea, implementarea proiectelor in aceasta ordine sugerata de raspunsul B: T1, T2, T3, T4 inseamna o utilizare ineficienta a resurselor. Pentru a raspunde corect la intrebare, cheia raspunsului se gaseste in coloana „Business Reason”, adica motivul pentru care au fost alese aceste functionalitati sunt importante. Dupa cum se observa, motivele noastre sunt dintre cele mai „interesante”: „My gut tells me„, „Because I said so„, etc, deci contin „toate” motivele din lume, mai putin cele care tin de business si de „bunul simt” al logicii…

Cred ca pentru nimeni nu ar fi o noutate sa afle ca, de fapt unii managerii iau decizii exclusiv pe instinctul lor „natural” sau pe argumentul „Cuvantul meu e litera de lege”. Imaginati-va ca acest un astfel de manager are puterea de a decide prioritatile de business (Business Priority). V-ati simti confortabil sa stiti ca prioritatile unui proiect se stabilesc doar pe baza opiniei lui? Probabil ca nu. Acesta e motivul pentru care prioritatile nu se aleg doar pe baza unui singur om (sau grup restrans de manageri or un singur manager „Atotputernic”) si poate acecsta e si motivul pentru care deciziile in companii, in general, se iau de mai multe persoane, in colaborare. Prioritatile in cadrul unui proiect ar trebui sa fie alese pe baza tuturor stakeholderilor interni si externi. PM-ul are responsabilitatea de a se asigura ca se va tine cont de parerile tuturor stakeholderilor in procesul de alegere a prioritatilor.

Pentru ca un PM sa poata stabili prioritatea unei functionalitati trebuie mai sa inteleaga de ce acea fucntionalitate este importanta: De ce se vrea aceasta functionalitate implementata? Folosind aceasta informatie in corelatie cu informatiile de la toti stakeholderii, un PM poate decide intr-un mod logic, transparent, consistent si obiectiv prioritatea unei functionalitati. In acest sens, un PM poate folosi o analiza de tip Cost Beneficiu (Benefit-Cost Analysis), una din cele mai cunoscute si acceptate metode de prioritizare.

Luand exemplul de mai sus, indicatorii cost benefiu arata astfel:

T1 are un beneficiu/cost = 5/5 = 1

T2, are beneficiu/cost = 4/1= 4.

T3 4/4 = 1.

T4 2/1 = 2.

Dornic sa arat solutia mea key stakeholderilor, ii convoc intr-o noua sedinta si le arat analiza mea:

-Aceasta e ordinea de lucru care mi-a rezultat mie pe baza acestei analize si arata asa: T2, T4, T1, T3.

-Ce e asta? intreaba COO-ul.

-O analiza de tip cost beneficiu, raspund.

COO-ul a inlemnit:

-Cine esti tu sa ne spui care e ordinea? Lasa analiza de business in seama noastra!

Argumentez solutia propusa:

-Ordinea de lucru T2, T4, T1, T3 foloseste la maximum potentialul echipei, in prima luna: T2+T4+T1 =7 (o rata de ardere de 100%), fata de prima solutie care foloseste doar T1+T2=6 (6/7=85% rata de ardere). De asemenea valoarea totala pe care o putem aduce companiei (Business Value) la sfarsitul lunii este 10 fata de varianta a 2-a (implementare T1, T2) care are un Business Value relativ  in valoare de „9”. Asa arata calculele analizei cost-beneficiu:

-Nu! Nu asta e ordinea! Facem asa cum am stabilit eu: in prima luna (T1, T2), raspunse COO-ul.

Prioritatile o subiect „sensibil” de discutie

A decide prioritatile este un subiect foarte sensibil, deoarece este greu sa impaci punctele de vedere ale tuturor stakeholderilor. M-am intrebat des: Cand sa folosesc o analiza de cost beneficiu si cand nu? Pentru proiecte mici (de obicei proiecte Agile), prioritatile de business pentru functionalitati, adica Business Priorities sau Business Value stabilite de client, pot fi una si aceleasi cu Prioritatile (ordinea de implementare) functionalitatilor. De exemplu, un proiect dezvoltat cu metodologia Scrum, nu ai nevoie intotdeuna de o analiza cost-beneficiu pentru a alege prioritatile si exista si o explicatie logica pentru asta: fiecare Sprint livreaza un demo; daca clientul nu este multumit cu ceea ce primeste (ceea ce primeste este ceea ce plateste), el poate termina proiectul, daca clientul continua proiectul, el poate sa ceara o schimbare a functionalitatilor (Scope Change). In timpul Sprintului/Iteratiei, prioritatile se pot schimba rapid in functie de nevoiele clientului, iar de obicei recalcularea indicatorilor cost beneficiu este doar o pierdere de timp (bineinteles ca nimic nu impiedica echipa sa ofere o analiza cost beneficiu clientului in favoarea unei decizii mai bune). Dezvoltarea in Scrum este foarte asemanatoare cu „un joc de-a viata si de-a moartea”: Lupta sa supravietuiesti schimbarilor, Adapteaza-te sau mori!

Prioritatile, un raspuns la alegerile ilogice 

Analiza Cost-Beneficiu propune o metoda pragmatica de prioritizare care reduce sansa de a alege prioritatile doar pe baza parerilor personale, interpretarilor si a raspunsurilor emotionale. Exista si tehnici in alegerea prioritatilor, raspunsurile emotionale joaca un rol foarte important, asa cum se intampla in Modelul Kano. In ciuda faptului ca modelul ofera o interpretare a datelor doar pe baza raspunsurilor emotionale si subiective ale stakeholderilor, surprinde foarte bine comportamentul cumparatorilor in piata. Modelul Kano este in acelasi timp, interesant si util, pentru ca ofera o interpretare logica a alegerilor ilogice. (Pentru mai multe detalii citeste o Analiza a Modelului Kano).

O metoda riguroasa de a alege prioritatile

In ciuda faptului ca modelul Kano, care se bazeaza pe un raspuns emotional si mai putin pe ratiune, este un model solid, cu multe aplicatii practice in spate,  rezultatele lui pot fi considerate la fel de „valabile” precum cele ale analizei de tip cost-beneficiu.

Pentru ca procesul de decizie al prioritatilor sa fie unul riguros este necesar sa aiba o serie de reguli:

1. Sa tina cont de parerea tuturor stakeholderilor (interni sau externi). Exemplu: Echipa de dezvoltare trebuie sa aiba de asemenea un cuvant de zis in alegere prioritatilor. In lipsa acestui lucru, se incalca principiul MBO (Management By Objectives, in care obiectivele sunt agreate si sustinute de catre toate nivelurile organizationale).

2. Daca in procesul de alegere a prioritatilor se tine cont de Efortul(Costul) echipei de dezvoltare, estimarea de Efort trebuie sa fie evaluat pe seama unor criterii prestabilite. Ponderea fiecarui criteriu este stabilit la nivel de organizatie sa in functie de strategia de produs. Estimarea de Efort este reprezentata ca o valoare relativa (de exemplu folosind o valoare din sirul lui Fibonacci: 1, 3, 5, 8, 13, 21, etc sau o scara de valori predefinita: 5 = very hard to implement, 1=very easy to implement). Example de criterii cu diferite ponderi:

3. Alegerea prioritatilor tine cont intotdeuna de prioritatile de business (Business Priority/Business Value). Business Priority/Business Value se estimeaza in functie de o serie de criterii prestabilite la nivel de organizatie (portofoliu sau program) si, ideal, nu ar trebui sa nu se schimbe de la proiect la proiect. Business Value ar trebui de asemenea sa contina minim 3 criterii de evaluare (ponderile criteriilor pot diferi de la un proiect la altul). In figura de mai jos sunt descrise doua categorii de criterii: criterii curente si viitoare. La fel ca si in cazul estimarii efortului, Business Value se abstractizeaza in valori numerice (exemplu: 5 = very high priority, 1=very low priority).

De ce sunt necesare mai multe criterii criteriile de a stabili prioritatile de business?

De nenumarate ori, in sedintele de prioritizare am observat ca oamenii au tentinda de a supraevalua sau subevalua prioritatile.(De exemplu, la intrebarea „Care functionalitati vi se par importante?”, raspunsul e de multe ori „Toate sunt importante”. Este evident, ca pe baza acestui raspuns nu poti face o diferenta intre functionalitatile mai importante si mai putin importante). Asadar pentru a reduce subiectivitatea evaluarii se predefinesc mai multe criterii de evaluare.

5. Fiecare criteriu de priorititzare este o medie a parerilor (valorilor) a cel putin trei experti. Dar de ce minim trei?

Oamenii indiferent cat sunt de buni intr-un domeniu sunt supusi erorilor. In managementul de proiecte, estimarile de timp folosite in tehnica PERT (Program Evaluation and Review Technique), tin cont de 3 estimari diferite (P=o estimare Pesista, O=Optimista, M=Cea mai probabila (din engleza: Most probable)). Indiferent de metoda pe care o folosim in estimari (PERT, jocul de Poker, etc) e nevoie de minim 3 oameni pentru ca opiniile sa convearga spre un rezultat mai realist. In orice dezbatere, e nevoie de mai mult de doi oameni pentru a nu se ajunge la situatia „cuvantului meu impotriva cuvantului tau”.

Puncte bune si slabe ale analizei Cost-Beneficiu

Tehnica Cost-Beneficiu se poate folosi in prioritizarea atat a functionalitatilor in cadrul proiectelor, a proiectelor in sine sau a produselor. Mai jos un exemplu de prioritizare a produselor folosind analiza cost beneficiu be baza Efortului si a Business Value (Ordinea de release a produselor pe piata este data de sortarea coloanei „Benefit/Cost ratio”).

Din ce cauza nu ne putem baza intotdeuna pe raportul cost/beneficiu pentru a stabili prioritatile?

Fie urmatorul exemplu:

In figura de mai jos exista doua proiecte P1 si P2 cu raport identic 1. Daca ar fi sa ordonam aceste proiecte strict pe baza raportului cost beneficiu, pur si simplu nu am putea pentru ca ambele au acelasi raport. Aceeasi situatie exista pentru toate proiectele aflate pe dreapta de ecuatie y=Cx (pentru care beneficiu/cost=y/x= panta dreptei C de raport constant).

Un alt exemplu de care m-am lovit in practica si care demonstreaza ca analiza cost beneficiu nu este intotdeuna o metoda potrivita de prioritizare:

In tabelul de mai sus, functionalitatea „UI/UXD part 1” si „UI/UXD part 2” sunt legate de unul si acelasi scop si anume de interfata grafica pe care key stakeholderii au considerat-o foarte importanta (are Business Value „5”). In urma analizei cost beneficiu, a rezultat ca implementarea interfetei grafice ar trebui sa se realizeze in doua iteratii diferite, insa clientul vrea sa vada finalizata „interfata grafica” mai intai de toate.

Pentru a rezolva situatia de fata, s-a ajuns la impartirea interfetei grafice in mai multe module mai mici, s-a reestimat efortului de munca si am putut livra livra cat mai mult din interfata grafica in prima iteratie. In acest caz analiza cost beneficiu nu a fost utila.

In managementul de proiecte, exista o serie de metode des folosite de prioritizare care pot fi aplicate impreuna sau ca o completare a analizei cost beneficiu: Matrix Prioritization (vezi mai jos), NPV (Net Present Value), IRR (Internal Return Rate), ROI (Return of Investment) sau chiar analize de tip Monte Carlo (pentru a dovedi care decizii de implementare sunt bune si implicit care trebuie implementate mai intai).

Matrix Prioritization

O alternativa a analizei beneficiu cost, poarta numele de Matrix Prioritization Plan care are la baza tot o analiza de tip cost beneficiu, dar care ofera o interpretare vizuala a datelor. Ordinea de implementare este data de Axa Y (Business Value) si apoi axa X (Efort): cadran 1, 2, 3, 4. Pentru „bulele” care sunt in acelasi cadran, se poate imparti cadranul in alte patru cadrane si se aplica aceiasi metoda. Aceasta metoda nu are aceiasi limitare („C de raport constant” – vezi mai sus exemplul) ca si Analiza Cost Beneficiu „clasica”, deoarece la sortare folosim doua dimensiuni (Y si X) in loc de una (raportul Y/X). In prima dimensiune Y, sortam dupa Beneficiu (Business Value), apoi folosim a doua dimensiune „X” si sortam dupa Cost, si chiar daca raportul Benefit/Cost este identic, totusi putem sorta functionalitatile dupa Beneficiu. metoda Matrix Prioritization are totusi o limitare, daca sunt doua produse cu acelasi raport Benefit/Cost=C si acelasi Cost (in aceast caz, produsele nu pot fi ordonare doar dupa cele doua dimensiuni, ci este nevoie de „dimensiuni de sortare” sau constrangeri suplimentare).

Avantajul acestei metode este ca poti stabili ordinea de implementare cu ochiul liber, fara a necesita calcule: P1, P3, P2, P4.

Prioritatile, o alegere logica

Realizez faptul ca sunt putini PMi care isi permit luxul de a decide prioritatile in cadrul unui proiect. Alegerea prioritatilor folosind o metoda standardizata este o poveste frumoasa, dar in realitate, de cele mai multe ori, prioritatile sunt impuse din afara proiectului de catre managerii functionali, clienti, Sponsori si nu sunt in atributiile unui PM. In mod normal, un PM ar trebui sa poata stabili prioritatile folosind o procedura standard de alegere a prioritatilor (procedura ar trebui sa faca parte din OPA – Organization Process Assets). Procedura de alegere a prioritatilor este un document care descrie clar cum sunt stabilite criteriile prioritatilor, felul cum se calculeaza prioritatile, felul in care prioritatile se aliniaza la obiectivele companiei si la strategia de produse. Acest document este un fel de „Noul Testament” al angajatilor sau un „Crez” al companiei, care ar putea defini criteriile de alegere a prioritatilor astfel:

Criteriul UXD: „Cred ca experienta utilizatorilor este cel mai important factor care decide succesul sau esecul unui produs”, Criteriul de Upselling: „Cred ca functionalitatile de upsell vor mari semnificativ castigurile companiei”, Criteriul de Brand: Cred ca functionalitatile care maresc vizibilitatea brandului nostru pot sa ne mareasca veniturile!” etc.

Daca nu aveti un astfel de document in companie, faceti-va rugaciunea si spuneti in cor „Dumnezeu cu mila…”.

Prioritatile sunt alese logic pe baza unor criterii prestabilite, nu pe baza de instict. Dar acum apare intrebarea fireasca: Daca prioritatile sunt o alegere logicam cum se face ca cei de la Apple, acei nebuni care au schimbat lumea, care au sfidat logica prin tot ceea ce au facut au reusit sa aiba atat de mult succes? Au folosit cumva metode analitice, grafice, modele matematica ca sa isi aleaga prioritatile? Evident ca nu! Mai intai de toate, ei nu au ales prioritati, ci obiective. Au pornit de la esenta lucrurilor (obiectivele companiei), iar priorittatiule au derivat in mod natural si logic din acele obiective. Desi obiectivele lor au fost uneori nebunesti si aparent irationale, totusi prioritatile lor au fost o alegere logica.

Citeste mai departe: O zi din viata unui Product Manager.

Anterior: O lectie de Gathering Requirements.

Recomandari: Cand e vorba de afaceri, logica esueaza!

Carti: Agile Excellence for Product Managers