| Definirea cerintelor - factor critic de succes |
|
|
|
|
A sosit timpul sa discutam despre cei mai importanti factori de succes pentru un program. Lasand deoparte politica, managementul asteptarilor etc si trecand la lucruri concrete, palpabile, definirea cerintelor de business este unul dintre cei mai importanti factori de succes pentru un program.
Cunosc extrem de multe programe care puteau sa faca diferenta, sa aduca beneficii poate mai mari decat cele estimate, sa dea extrem de putine batai de cap echipei de proiect daca ar fi beneficiat de cerinte de business detaliate si cat mai complete. Sa analizam cauzele pentru care cerintele de business nu sunt complete sau nu sunt suficient de detaliate. Complete este aproape imposibil sa fie din cauze nenumarate dar pot fi suficient de detaliate.
Principalele cauze pentru care nu putem beneficia de cerinte detaliate sunt urmatoarele: - presiunea mare pentru termenul de implementare. Business Owner-ul primeste sarcina de a elabora cerinte intr-un termen foarte scurt si lansarea se doreste a fi cat mai urgenta. Cum putem evita acest lucru? Nu intotdeauna se poate insa putem sa reducem din riscuri. Planificarea, este raspunsul cheie. Daca am face o planificare riguroasa, inainte de inceputul noului an financiar sau calendaristic, si am defini un roadmap care sa acopere cat mai bine nevoile clientilor nostri, cu siguranta ca am avea mai putine "interventii" din partea sefilor. "Trebuie sa lansam urgent produsul X, competitorii nostri sunt mult inaintea noastra" samd. De cate ori nu am auzit astfel de cuvinte, dar ne-am intrebat oare, noi ce am facut pentru a preintampina astfel de situatii? Inca o data doresc sa mentionez ca nu le putem exclude dar le putem diminua
- business owner-ul nu are cunostinte aprofundate despre produsul/serviciul care trebuie lansat si elaboreaza cerintele presupunand sau avand convingerea ca stie despre ce vorbeste desi nu este nici pe departe asa. De ce procedeaza asa? Pentru ca fie nu vrea sa recunoasca faptul ca nu stie dar nici nu are timp sa invete, sa se documenteze, sa identifice expertii care ar putea sa aibe o contributie foarte utila in elaborarea acestor cerinte, fie pur si simplu vrea sa demonstreze ceva, sa arate ca poate. Sunt foarte frecvente astfel de situatii si se continua daca nu se face o post implementare riguroasa care sa compare estimarile, performantele produsului/serviciului cu rezultatele reale. Cat de frecvente sunt astfel de situatii depinde de cultura companiei, de regulile interne si ct de riguros se face post implementarea
- una dintre cele mai frecvente situatii este aceea cand initiativa se regaseste in roadmap, business owner-ul cunoaste relativ bine domeniul dar nu face o documentare detaliata, nu discuta cu ariile unde poate exista impact sau pot aduce o contributie utila la definirea noilor cerinte. Termenul de incepere a proiectului se apropie vertiginos si deoadata realizeaza ca nu prea mai are timp si totusi trebuie sa livreze ceva. Ce face in acest moment? Elaboreaza rapid un set de cerinte, generale care sa sustina cat de cat termenele asumate la momentul includerii initiativei in roadmap si incepe proiectul sperand ca vor fi acoperite lipsurile pe durata fazelor ulterioare. Uneori se intampla sa se acopere aceste lipsuri dar in cele mai multe cazuri acest lucru nu se intampla sau se intampla partial.
Ce putem face noi ca program manageri sa evitam astfel de situatii astfel incat sa nu ajungem in situatia in care sa depasim scopul programului, bugetul sau termenul?
Depinde de momentul in care preluam programul. Daca il preluam inainte de faza de analiza mai avem sanse sa impunem completarea cerintelor daca nu este destul de dificil dar in toate cazurile trebuie sa ridicam riscurile corespunzatoare. Nu trebuie sa uitam si de presiunea care vine, de foarte multe ori, din partea management-ului. "Trebuie sa facem ceva, sa iesim pe piata rapid etc, etc". Chiar daca nu mai putem sa facem mare lucru pentru cerinte (ca sa evitam sa fim vazuti ca un stoper al programului) putem sa avem un foarte bun management al asteptarilor.
Daca identificam corect riscurile la care este expus programul si le prezentam la steering evident impreuna cu propunerile de evitare/reducere a acestor riscuri, mai putem face un pas important pentru un program de succes.
Mai bine sa dezamagim la inceputul programului decat sa dezamagim la sfarsitul lui. |
|
BNR Exchange Rates
Currency RON 06-02-2012 |
||
![]() | EUR | 4.3420 |
![]() | USD | 3.3295 |
| XAU | 183.6147 | |