Cum să stabiliți prețul proiectelor și să gestionați Scope Creep

Sunt sigur că ați citit articole nerealiste care sugerează că există o abordare științifică a prețurilor care vă va permite în mod magic să creați o cotație exactă. S-ar putea să fi fost, de asemenea, făcut să credeți că scăderea domeniului de aplicare ar trebui evitată cu orice preț, dar în lumea reală, se va întâmpla întotdeauna.

Este timpul ca noi să încetăm să jucăm acest joc ridicol și să începem să rulăm proiecte într-un mod mai puțin asemănător cu jocurile de noroc și mai mult ca urmărirea unui proces robust și de încredere.

exagerez? Posibil, dar haideți să vedem unde lucrurile merg atât de des prost cu proiectele digitale.

Problemele cu procesul nostru de proiect

Din experiența mea, majoritatea organizațiilor din orice industrie derulează proiecte aproximativ în același mod:

1. Cineva din conducere cere ca un proiect să fie finalizat. Din păcate, această solicitare nu are deseori detalii în ceea ce privește livrabilele și tinde să aibă doar obiective vagi.
2. Un comitet de părți interesate este întrunit pentru a defini proiectul în detaliu și a decide asupra domeniului de aplicare.
3. Scopul detaliat este apoi dus echipei care îl va construi și li se cere să estimeze cât timp va dura și cât va costa.
4. Proiectul este livrat conform specificațiilor, punând accent pe livrarea la timp și în buget. Ca rezultat, scăparea lunei devine inamicul.
5. Proiectul este livrat și toată lumea trece la următorul proiect din lista de sarcini.

Această abordare este departe de a fi ideală, mai ales pentru proiectele digitale. Digital ne oferă feedback fără precedent cu privire la comportamentul utilizatorilor și face relativ ușor implementarea modificărilor (comparativ cu produsele fizice). Cu toate acestea, odată ce domeniul de aplicare a fost definit și o ofertă oferită, proiectul devine blocat, toată lumea reticentă să facă modificări pe măsură ce proiectul progresează.

Cu toate acestea, în mod inevitabil, domeniul de aplicare sfârșește prin a se schimba, în principal pentru că părțile interesate au interpretări diferite ale ceea ce va fi construit sau pentru că își dau seama la mijlocul proiectului că elementele critice sunt greșite.

Într-adevăr, nu este nimic în neregulă cu sfera de aplicare . A rămâne flexibil și a te adapta pe măsură ce înveți mai multe este fundamental pentru a crea servicii digitale excelente. Problema nu este cu variația de aplicare, ci cu modul în care rulăm proiecte.

Din păcate, deoarece s-au convenit termenele limită și costurile, încercăm să livrăm aceste modificări în limitele acestor constrângeri, ceea ce duce la tăierea colțurilor.

Nu că termenele și costurile au fost exacte în primul rând. Proiectele digitale sunt complicate, implicând adesea specialiști și părți interesate care lucrează împreună. Drept urmare, ele sunt notoriu greu de estimat cu precizie.

Am citit multe articole care propun metodologii de estimare cu acuratețe. Cu toate acestea, ele sunt nepractice în lumea reală în aproape toate cazurile, în principal pentru că necesită prea mult timp pentru a fi aplicate. Estimarea unui proiect se reduce la intuiție, experiență și o presupunere educată!

După cum vă va spune oricine care a lucrat în domeniu pentru orice moment, majoritatea estimărilor sunt o operă de ficțiune . De obicei, nu știm suficient de la început nici măcar pentru a determina care este soluția potrivită sau cum ar putea răspunde utilizatorii la ea. Prin urmare, este imposibil să estimați cu acuratețe un întreg proiect în avans.

Din păcate, această ambiguitate duce adesea la distribuirea incorect a vinei atunci când proiectul își pierde în mod inevitabil termenul limită și depășește bugetul.

Din fericire, există o modalitate de a furniza estimări precise și de a gestiona scăderile în domeniul de aplicare care implică modificarea proiectelor rulate. Secretul constă în împărțirea proiectelor în bucăți mai mici. Această abordare evită preluarea proiectelor mari și complexe.

Împărțiți proiectele într-o serie de angajamente mai mici

Trebuie să fiu clar în acest moment. Nu sugerez că programele de lucru ambițioase sunt greșite. Lucrez pentru clienți mari pe site-uri web substanțiale și programe de lucru extinse. Cu toate acestea, rareori tratez aceste angajamente ca pe un singur proiect mare. În schimb, le descompun în proiecte mai ușor de gestionat pe care le delimitez pe rând.

Când un client mă abordează dorind să întreprind un proiect digital (fie el mare sau mic), de obicei îl împărțim în patru etape care se întâmplă în următoarea ordine:

1. Descoperire,
2. Alfa,
3. Produs minim viabil,
4. Iterație și optimizare continuă.

Fiecare etapă este un angajament separat, cu rezultate clare. Prin urmare, nu mă angajez la întreg proiectul ci doar la prima fază. Acest lucru face ca estimarea și gestionarea domeniului de aplicare să fie mult mai ușoară.

De exemplu, trebuie doar să definiți domeniul de aplicare al etapei următoare. Acest lucru vă permite să gestionați mai bine scăderea domeniului, deoarece o puteți adapta pe măsură ce definiți următoarea etapă , odată ce etapa anterioară a fost finalizată.

În loc să estimați un întreg program de lucru, estimați următorul proiect din acel program. De asemenea, puteți folosi etapa anterioară pentru a vă ajuta să estimați mai precis.

Fiecare etapă ajută la definirea și estimarea etapei următoare, începând cu descoperirea.

1. Descoperire

În faza de descoperire, lucrez cu părțile interesate pentru a valida proiectul. În funcție de dimensiunea totală a proiectului, acesta poate fi la fel de simplu ca câteva întâlniri sau poate fi un întreg program de lucru.

De obicei, include elemente precum:

• efectuarea cercetării utilizatorilor;
• analiza competitiei;
• identificarea indicatorilor cheie de performanță;
• definirea cum arată succesul;
• înțelegerea constrângerilor;
• colectarea opiniilor părților interesate.

Ideea este că faza de descoperire va oferi o definiție mai informată a proiectului, inclusiv nevoile utilizatorilor, obiectivele de afaceri și ceea ce trebuie creat.

Cel mai important, va valida faptul că proiectul va oferi valoarea necesară.

Apoi putem folosi acest livrabil pentru a defini și estima munca necesară într-o fază alfa. Procedând astfel, estimările noastre sunt mai precise și, de asemenea, ajustează domeniul de aplicare în funcție de ceea ce am învățat.

2. Alfa

Faza alfa este cea în care definim modul în care serviciul digital (fie că este o aplicație web sau un site) va funcționa și ne asigurăm că utilizatorii au o experiență pozitivă folosindu-l.

Acest lucru se realizează de obicei prin crearea unui prototip. În cazul proiectelor mai mici, aceasta ar putea fi altceva decât niște machete de design. În proiecte mai mari, ar putea fi un prototip funcțional pe care oamenii îl pot încerca.

Oricare ar fi cazul, ideea este să vizualizați serviciul digital pe care îl construiți.

Facem asta din trei motive.

• În primul rând, o vizualizare se va asigura că toate părțile interesate au o viziune comună asupra a ceea ce creați. Un document poate fi interpretat în multe moduri diferite, dar acest lucru este mult mai greu de realizat cu un prototip.
• În al doilea rând, un prototip va face mult mai ușor să identifici orice ar fi putut fi trecut cu vederea, așa că evitați scăderea domeniului de aplicare mai departe, atunci când este mai costisitor de abordat.
• În cele din urmă, dacă avem ceva tangibil, îl putem testa cu utilizatorii pentru a ne asigura că va fi potrivit scopului, înainte de a trece pe cheltuiala construirii unui lucru real.

Dacă se testează prost, mai avem loc înainte de următoarea fază să ne adaptăm fără a scăpa bugetul sau a încurca cronologia.

Ca și în faza de descoperire, putem folosi alfa pentru a estima munca necesară în etapa următoare. Având o vizualizare a ceea ce necesită construirea, estimarea lucrărilor necesare este mult mai ușoară pentru toate părțile interesate implicate. Ei pot vedea ce li se cere să construiască.

În plus, putem folosi lecțiile învățate din testarea alpha pentru a adapta ceea ce vom crea, creând încă o dată spațiu pentru modificări ale domeniului de aplicare fără a deraia proiectul.

Odată ce avem alfa, putem trece cu încredere în build, știind că vom crea lucrul potrivit și că utilizatorii vor răspunde pozitiv la acesta.

3. Produs minim viabil

Obișnuiam să mă refer la această etapă drept „construire”. Cu toate acestea, am constatat că părțile interesate au asociat finalizarea construcției cu finalizarea proiectului. În realitate, serviciile digitale nu se realizează niciodată, deoarece trebuie să fie repetate în mod constant pentru a se asigura că sunt cât mai eficiente posibil.

Pentru a evita această problemă, am început să mă refer la această etapă ca fiind produsul minim viabil (MVP). În această etapă, construim și lansăm versiunea inițială a serviciului digital.

Referindu-ne la acesta ca fiind produsul minim viabil, subliniem că va exista o iterație după lansare. Acest lucru ne oferă o modalitate de a face față decalajului și complexității neprevăzute, împingând-o înapoi până după lansare. Acest lucru asigură că proiectul rămâne pe drumul cel bun și își menține impulsul.

Inevitabil, în timpul construcției, vom amâna unele lucruri până după lansare. Aceste elemente devin apoi baza pentru definirea etapei noastre finale, permițându-ne să facem o estimare inițială pentru optimizarea post-lansare.

4. Iterație și optimizare continuă

Faza de după lansare tratează funcționalitatea, complexitatea și alte probleme pe care nu le-am abordat în MVP. Această listă de îmbunătățiri este relativ ușor de urmărit până în acest moment și poate fi estimată cu o precizie rezonabilă.

Cu toate acestea, pe lângă această activitate, ar trebui să existe un proces continuu de monitorizare, iterare și testare care să rafineze și mai mult eficacitatea serviciilor digitale.

Estimarea cât de mult din această muncă o întreprindeți ar trebui să se bazeze pe dimensiunea și complexitatea serviciului digital. Estimarea dvs. ar trebui să fie, de asemenea, proporțională cu investiția în restul proiectului.

Prin împărțirea proiectelor dumneavoastră în aceste patru faze și completând fiecare separat, veți elimina multe dintre provocările cu care ne confruntăm atunci când folosiți abordările tradiționale de management de proiect.

De ce funcționează Breaking Projects Down

Patru beneficii semnificative rezultă din defalcarea proiectelor în acest fel:

• Fiecare fază este mai bine definită .
  Deoarece livrabilele fazei anterioare definesc fiecare etapă, înseamnă că există o viziune clară a direcției. Acest lucru îi ajută pe părțile interesate să înțeleagă unde merg lucrurile și evită surprizele urâte ulterioare.
• Proiectele sunt estimate mai precis .
  De exemplu, în loc să trebuiască să ghiciți cât timp va dura pentru a livra un proiect semnificativ, nebulos, cu un număr substanțial de necunoscute, estimați doar faza următoare și faceți acest lucru pe baza rezultatelor din faza anterioară.
• Rezultă servicii digitale mai bune .
  Deoarece ideile de proiecte sunt validate și testate cu utilizatorii, puteți fi mai sigur că produsul final se va potrivi scopului. De asemenea, oferă spațiu pentru a adapta domeniul și funcționalitatea între faze pentru a vă asigura că oferiți cel mai bun rezultat posibil.
• Este o abordare mai puțin riscantă .
  Compania care pune în funcțiune serviciul digital nu trebuie să se angajeze în avans pentru întregul proiect. Dacă faza de descoperire nu reușește să valideze viabilitatea proiectului, acesta poate fi abandonat cu pierderi minore. De asemenea, dacă prototipul alfa nu testează bine cu utilizatorii, acesta poate fi adaptat înainte ca lucrurile să devină prea scumpe.

Acest ultim punct este liniștitor dacă un furnizor extern este utilizat pentru prima dată. În loc să înscrieți o agenție pentru un proiect substanțial fără să știe dacă poate livra, clientul îi poate angaja pentru o fază de descoperire pentru a vedea cum sunt. Dacă sunt buni, pot continua să lucreze cu ei. Dacă nu, ei pot duce constatările la o altă agenție fără nimic pierdut.

Dacă conduceți o agenție sau sunteți freelancer, ați putea crede că aceasta sună a o idee proastă. Este de înțeles că preferați să vă înscrieți un client pentru întreg proiectul. Cu toate acestea, am evitat multe licitații competitive cu această abordare, deoarece clientul nu a simțit că își asumă un risc la o investiție inițială atât de mică. În plus, nu au simțit nevoia să vorbească cu diverși furnizori pentru că dacă nu le-ar plăcea de mine puteau schimba cu ușurință.

În plus, utilizarea acestei abordări în etape va face mult mai ușoară stabilirea domeniului și stabilirea prețului următorului dvs. proiect cu preț fix. Sigur, nu va oferi, în mod magic, o estimare și nici nu va preveni mutarea domeniului de aplicare. Cu toate acestea, va face estimarea mai ușor de gestionat, deoarece analizați doar o parte la un moment dat. De asemenea, vă va permite să lucrați cu scăparea lunei, mai degrabă decât să încercați să o suprimați.

Așadar, sfatul meu, indiferent dacă lucrați intern sau extern, pe site-uri mari sau mici, este să nu mai încercați să estimați și să definiți proiectele fără a le împărți în faze. În schimb, abordează o fază odată și folosește ceea ce ai învățat pentru a informa următoarea . Dacă o faci, vei estima mai precis, vei avea loc de adaptare pe baza a ceea ce ai învățat și vei descoperi că managementul de proiect este mai simplu.