by Din scurta mea experienta de manager de proiect as dori sa impartasesc un scurt ghid de 7 intrebari, fara sa consider ca este o lista exhaustiva, pe care consider ca orice manager de proiect ar trebui sa si le puna la initierea unui proiect:
1. Care e business need-ul clientului?
De ce vrea clientul acest proiect? Ce nevoie ii satisface? Este clientul intr-un lant trofic in care rezultatul acestui proiect este livrat mai departe catre un alt client? Daca da, cel de la capatul lantului trofic la ce foloseste livrabilele acestui proiect? In ipoteza unor cerinte nu foarte clare si pus in fata unor decizii de-a lungul proiectului de a face compromisuri intre timp, cost, aria de cuprindere a proiectului sau calitatea livrabilelor, business need-ul clientului este un driver important daca vrem ca acesta sa fie multumit si sa se reintoarca la noi.
2. Care e business case-ul organizatiei mele?
De ce organizatia a luat acest proiect? Sa marcam marja de profit? Sa intram intr-o piata noua sau la un client nou? Sa ne dezvoltam capabilitati noi care sa fie folosite ulterior in proiecte care vor avea ca prioritate profitul? Alaturi de business need-ul clientului reprezinta driverul care trebuie avut in vedere cand se iau decizii in cadrul proiectului. Vreau sa am un client multumit ca sa mai vina la mine insa e la fel de important sa mai aiba la cine veni 🙂 S-au auzit multe cazuri de clienti multumiti si furnizori falimentari in urma predarii unor proiecte…
3. Care este aria de cuprindere a proiectului?
Ce activitati/efort trebuie sa facem? Primim proiectul tehnic/design-ul? Il facem noi? Intra in aria de cuprindere si pregatirea utilizatorilor sau nu? Raspunsurile la acest gen de intrebari ar trebui sa fie date de contract. “Ar trebui”… pentru ca nu tot timpul se intampla asa. Zonele “gri” din contract, cerintele amibgue reprezinta o stare de fapt des intalnita. Si atunci, clarificarea raspunsului la aceasta intrebare si inca o parcurgere a contractului la initierea proiectului sunt recomandate.
4. Care sunt constrangerile?
Care sunt constrangerile de buget si de timp? Avem vreo constrangere de ordin tehnologic sau de resurse? Care este sursa acestor constrangeri: organizatia noastra, clientul?
5. Ce presupuneri s-au facut?
Ca sa putem construi un plan de proiect va trebui sa ne bazam pe diferite presupuneri, unele dintre ele chiar documentate in contract, altele interne organizatiei din care facem parte. O presupunere va fi asociata intotdeauna cu un risc, pentru ca atunci cand presupunerea se dovedeste falsa, vom avea de-a face cu o problema…. 🙂
6. Cine ce anume trebuie sa aprobe, valideze?
Atat intern cat si in relatia cu clientul apar diferite “milestone-uri” sau “gate-uri” in urma carora livrabile intermediare, documente de specificatii etc sunt revizuite, aprobate, asumate si constituie intrari pentru faze ulterioare ale proiectului. Este foarte important de clarificat ce roluri sunt implicate si cu ce responsabilitati in aceste validari/revizuiri/aprobari si sub ce forma se fac aceste activitati pentru a evita situatii in care anumiti reprezentanti ai clientului, de exemplu, vin si spun, dupa obtinerea unor validari pe niste livrabile intermediare de la alti reprezentanti ai clientului, ca acele validari sunt nule. Odata clarificat acest aspect reducem riscul de aparitia conflictelor si reworkului datorate acestor lucruri.
7. Ce anume trebuie sa livram?
Contractul ar trebui sa fie un input primar din care sa extragem nu numai livrabilele ci si conditiile de acceptare a lor de catre client si datele de livrare. Pot exista discutii verbale/informale in care reprezentantii clientului pot cere mai mult sau mai putin, mai devreme sau mai tarziu si apoi acei reprezentanti sa dispara din peisaj, pentru ca, nu-i asa, traim intr-o lume libera. Toate intelegerile nescrise pot disparea odata cu ei. Noii veniti se vor uita inainte de toate in contract…
In viata de zi cu zi, e posibil sa nu avem raspunsuri complete la toate intrebarile de mai sus atunci cand initiem proiectul. Insa faptul ca avem o intrebare din cele 7 fara raspuns, este un risc pe care va trebui sa il gestionam. Este ma bine sa stim ce nu stim, decat sa fim convinsi ca le stim pe toate si ca nimic rau nu se poate intampla…
