Pentru proiecte mai mari, vă recomand să creați o matrice de trasabilitate a cerințelor. Aflați mai multe aici:

Matricea de trasabilitate a cerințelor în gestionarea proiectelor (exemplu + șablon)

Procesul nr. 2: Cum să reduceți cerințele și să definiți domeniul de aplicare

Iată o cerință :

„Site-ul web pmbasics101.com ar trebui să aibă capacitatea de a colecta e-mailuri și de a trimite în schimb un document PDF.”

Ce este necesar pentru a îndeplini această cerință?

1. Selectați un furnizor de servicii de e-mail.
2. Creați un cont.
3. Proiectați formularul pentru a colecta e-mailuri.
4. Implementați formularul proiectat.
5. Instalați pluginul de la furnizorul de servicii de poștă.
6. Încărcați documentul PDF.
7. Activați formularul.
8. Testați formularul.

Este doar o listă de acțiuni necesare. Dacă aș pune-o corect ca Livrabil și pachete de lucru, s-ar ajunge la:

1. Optare prin e-mail -in Form
   1.1 Raport privind furnizorii de servicii de corespondență
   1.2 Proiectarea formularului aprobat
   1.3 Formular opt-in pentru mediul de testare
   1.4 Raport de testare

Deci, cum se face ajungeți de la acea cerință de o singură frază la domeniul de lucru real?

A) Puteți găsi pe cineva care are experiență sau cunoștințe relevante

Poate fi părți interesate, clienți sau externi consultanți, experți în materie sau alte părți.

Deci, obiectivul dvs. este să le achiziționați de la echipa de proiect sau să luați legătura doar pentru a comunica. Este posibil să aibă deja o soluție.

În caz contrar, puteți primi indicații sau sfaturi. Este o tehnică de bază pe care o veți aplica pe scară largă.

B) Efectuați analiza produsului

Este aplicabilă atunci când trebuie să creați un produs mai degrabă decât un serviciu sau un rezultat.

Această tehnică se concentrează pe descompunerea valorii produsului. La fel cum face WBS cu domeniul de aplicare.

Mai mult, trebuie să analizați produsul din punct de vedere ergonomic și funcțional; și apoi luați decizii cu privire la materiale sau procese care vor respecta cerințele de performanță.

25 Exemple de analiză a produselor

Una peste alta, obiectivul dvs. este să definiți rezultate tangibile.

C) Utilizați tehnica de generare a alternativelor

Această tehnică funcționează bine atunci când aveți expertiză în natura proiectului.

Deci, trebuie să găsiți cea mai bună soluție pentru îndeplinesc cerințele. În majoritatea cazurilor, veți folosi brainstorming-ul pentru a obține alternativele.

Care este obiectivul?

Trebuie să definiți clar ce este și ce nu face parte din domeniul de aplicare al proiectului.

Procesul nr. 3: Gestionați domeniul de aplicare al proiectului cu un software PM

Cu siguranță, puteți urmări domeniul de aplicare al proiectului în orice aplicație disponibilă. De exemplu, Google Drive, Evernote sau MS Word vor face acest lucru.

Cu toate acestea, există beneficii serioase în utilizarea software-ului integrat de gestionare a proiectelor pentru a menține totul într-un singur loc.

În mod ideal, dvs. trebuie să fie capabil să conecteze cerințele la livrabilele proiectului.

Apoi, de la livrabil la sarcini specifice cu estimări, riscuri conexe și defecte.

De exemplu, vă pot recomanda Paymo. Este una dintre cele mai bune aplicații pentru uz personal și pentru proiecte mici. În plus, are capabilități excelente de urmărire a timpului și facturare.

Procesul nr. 4: Cum să controlați domeniul de aplicare al proiectului

Nu este suficient să identificați 100% din domeniul de aplicare al proiectului la început . Acel 100% se va schimba pe parcursul duratei de viață a proiectului.

Deci, aveți nevoie de o modalitate de a monitoriza, controla și efectua modificări în domeniul de aplicare.

Remediul este bine cunoscut. Este o structură de repartizare a lucrărilor.

Ei bine, de asemenea, aveți nevoie de un flux de lucru clar pentru a introduce modificări în toate domeniile proiectului ori de câte ori se modifică cantitatea de lucru.

Cu toate acestea, este vorba de un proces integrat de gestionare a modificărilor.

Deci, care este problema?

Aveți nevoie de un WBS de înaltă calitate. Mai mult decât atât, aveți nevoie de o modalitate non-nerd pentru a descrie domeniul de aplicare al proiectului. Prin urmare, aveți nevoie și de o declarație privind domeniul de aplicare al proiectului. O vom discuta mai jos.

Dacă vă aflați într-un proiect agil, sfera clar definită de creștere sau iterație este și mai importantă. Nu credeți că agilitatea vă scutește de documentarea amănunțită a muncii de făcut. Păstrați ordinea Sprint Backlog și User Stories. Aplicați o regulă simplă: „Un nou-venit ar trebui să înțeleagă ce trebuie făcut din descrierea User Story.”

Cum să validați domeniul de aplicare

Din când în când, trebuie să obțineți un formal deconectați-vă că un livrabil îndeplinește așteptările părților interesate.

Este crucial să faceți acest lucru continuu pe tot parcursul proiectului.Chiar dacă conduceți un proiect bazat pe planuri, nimic nu ar trebui să vă împiedice să furnizați măriri de produs pentru examinare.

De ce aveți nevoie de acest lucru?

Nu doriți să obțineți toate solicitările de modificare, toate defectele și „modificări minore ale proiectului” la final.

Vă veți priva de posibilitatea de a integra efectiv o modificare în proiect.

Cu cât sunteți mai aproape de închiderea proiectului, cu atât mai puțin timp și resurse vor rămâne. Mai mult, părțile interesate vor fi mai puțin predispuse la negocierea modificărilor domeniului de aplicare, calendarului sau bugetului. De asemenea, vor pune mai multă presiune asupra echipei obțineți ceea ce au nevoie.

Afirmând doar ceea ce este evident:

Este foarte important să aveți un domeniu de proiect clar descris și aprobat de la început.

Când un livrabil nu îndeplinește așteptările, vor exista corecții.

Este responsabilitatea dvs. să demonstrați dacă o corecție este o cerere de modificare și, prin urmare, ar trebui să fie integrată corect. În caz contrar, este un defect și trebuie să te repari. Uneori pe cheltuiala ta.

Cum validezi de fapt domeniul de aplicare cu clienții?

În orice proiect, poți folosi Reuniunea demonstrativă de tip Scrum.

Doar pregătește o scurtă demonstrație a livrabilului. Explicați starea și progresul curent al proiectului. După aceea, indicați defectele cunoscute și părțile aflate în lucru.

De asemenea, colectați feedback de la client. Ulterior, puteți furniza orice documentație de sprijin și rapoarte solicitate de politicile dvs.

Concluzie:

Colectați continuu feedback de la părțile interesate. Negociați termenii introducerii de noi cereri de modificare. Păstrați actualizarea proiectului Scope Baseline.

Obțineți șablonul de gestionare a domeniului meu de proiect

Nu inventați roata! Ar putea fi costisitor pentru dvs.

Doar faceți clic pe butonul de mai jos și obțineți șablonul meu de completare. Acesta vine cu un ghid de resurse despre tot ce trebuie să știți despre gestionarea domeniului.

De ce întregul domeniu de aplicare Linia de bază este critică pentru proiectul dvs.?

De obicei, un proiect începe și primim cerințe în diferite forme.

De exemplu: e-mailuri, PDF-uri, întâlniri, machete, rapoarte de erori, orice .

Și, desigur, nu pregătim o Cartă a proiectului sau ceva similar. Practică proastă!

În majoritatea cazurilor, nici măcar nu discutăm cazul de afaceri pentru proiect.

De obicei, creăm o structură de repartizare a lucrărilor.

Cu toate acestea, este utilizat numai intern și nu merge niciodată la client. Apoi, descompunem activitatea la activități și estimăm proiectul. Folosim o tehnică de estimare ascendentă.

Acum vine prima verificare a așteptărilor:

Prezentăm estimări pentru proiect.

Vedeți, aparent există o lipsa de transparență aici. Clientul nu știe ce lucru am estimat de fapt.

Dacă estimarea este aproape de așteptările clientului, el nu va intra în detalii. Acest lucru se datorează faptului că este gata să cheltuiască deja acea sumă de bani și timp. Nu vrea să-și piardă timpul prețios.

Iată adevărul:

O mulțime de organizații și manageri de proiect ascund ineficiențele în spatele unor astfel de acorduri silențioase.

Este un subiect pentru o postare separată, dar este cauza principală a multora dintre problemele dvs.

Ce se întâmplă în continuare?

Începem executarea proiectului! Mai devreme sau mai târziu, clientul va cere să adauge o altă lucrare.

După aceea, vom găsi o parte a muncii neidentificate. Mai târziu, vor apărea probleme de calitate. Vor consuma mult timp.

Una peste alta, predăm o livrare pentru a afla că am făcut ceva greșit.

Și atunci clientul ne informează că el ați uitat ceva și ar trebui adăugat cât mai curând posibil.

Crede-mă, îl experimentezi de mai multe ori.

Definiția liniei de bază a domeniului

”Linia de bază a domeniului este versiunea aprobată a unei declarații de domeniu, a structurii de repartizare a lucrărilor (WBS) și a dicționarului său WBS asociat, care poate fi modificat numai prin procedura formală de control al modificărilor și este utilizat ca bază pentru comparație. ” -PMBOK® Guide

Ce este o declarație privind domeniul de aplicare al proiectului?

Definiția declarației privind domeniul de aplicare al proiectului

Declarația privind domeniul de aplicare al proiectului este o descriere narativă a unui produs și a domeniului de aplicare al proiectului.

Este folosit ca o confirmare scrisă a ceea ce va produce proiectul dvs. și cum.

Care este cheia unei declarații valoroase privind domeniul de aplicare al proiectului?

Cred că trebuie să folosiți termeni și limbaj pe care orice părți interesate le înțelege. Această parte a liniei de bază a sferei de aplicare a proiectului este în principal pentru client.

OK, ce ar trebui inclus?

Justificarea unui proiect

Este o scurtă descriere a nevoile afacerii. Uneori este suficientă o propoziție. Restul ar trebui să rămână într-o Cartă a proiectului

Domeniul de aplicare al produsului

Este o descriere a caracteristicilor, trăsăturilor și funcționalității unui produs sau a unui serviciu pe care îl veți produce.

Rețineți că ați colectat cerințe de la diferite părți interesate. Deci, nu presupuneți că toți urmează fiecare cerință. De asemenea, nu este întotdeauna clar cât de multă muncă este necesară pentru a îndeplini o cerință.

Este locul principal pentru a alinia așteptările părților interesate cheie.

Trebuie să arătați cantitatea și complexitatea a muncii necesare pentru a îndeplini diferite cerințe. Prin urmare, depuneți cele mai multe eforturi în această secțiune.

Criterii de acceptare

Sunt condițiile care trebuie îndeplinite înainte ca livrabilele proiectului să fie acceptate.

Puteți include un nivel acceptabil și numărul de defecte și aici.

Livrabile

Este o descriere a tuturor livrabilelor pe care proiectul dvs. le va produce.

Poate include produsul sau service, documentație a proiectului, manuale de produs, materiale educaționale pentru produsul dvs. etc.

Excluderi de proiecte

Aici trebuie să specificați ceea ce nu intră în domeniul de aplicare al proiectului.

Destul de des, o parte din părțile interesate își dorește ceva anume. Cealaltă parte a părților interesate sau a unui client nu o acceptă.

Prin urmare, este o situație conflictuală. Odată ce conflictul a fost rezolvat și s-a decis eliminarea ceva din domeniul de aplicare al proiectului, puneți-l aici.

Fiți specific și foarte clar în legătură cu acesta. Economisește timp în viitor.

În primul rând, nu va trebui să revizuiți din nou aceste excluderi de proiecte. Părțile interesate pot încerca să le includă mai târziu în timpul execuției proiectului.

Cu toate acestea, cu excepția cazului în care se schimbă ceva dramatic, nu ar trebui să pierdeți timpul la examinarea excluderilor.

În al doilea rând, dacă nu este clar indicat, cineva poate așteaptă totuși că o vei livra. Nu alimentați așteptări false. Va fi mai ușor să transmiteți proiectul la final.

Constrângeri

Orice lucru care vă limitează să livrați produsul în mod eficient ar trebui menționat aici.

Ipoteze

Incertitudinile care nu au putut fi clarificate în acest moment.

Trebuie să acceptați unele dintre ele în timpul planificării. În cazul în care o ipoteză se dovedește a fi invalidă, veți avea dreptul să modificați planul de proiect.

Un client ar trebui să aprobe declarația privind domeniul de aplicare al proiectului. De fapt, este un acord formal și reciproc.

De asemenea, afirmă că sunteți angajat să furnizați rezultatele descrise în ipoteza definită și cu constrângeri clare. Pe de altă parte, clientul este de acord să accepte rezultatul specificat.

Nu înseamnă că nu putem schimba domeniul de aplicare al proiectului. Nu. Înseamnă că pentru a face o modificare – trebuie să modificăm acordul.

Organizați domeniul de aplicare al proiectului cu WBS

WBS este o parte obligatorie a domeniului de bază pentru toate proiectele. Mare sau mic. Agil sau bazat pe plan.

Există deja un ghid complet pentru o structură de repartizare a lucrărilor pe PM Basics. Nu îl voi repeta aici.

Există un singur punct crucial pe care vreau să-l subliniez:

Livrabilele descrise în Declarația Scopului Proiectului ar trebui să intre în WBS așa cum este. Păstrați livrabilitățile pe tot parcursul proiectului.

Puneți tot ce știți în dicționarul WBS

Dicționarul WBS este un document care descrie munca care ar trebui făcută pentru fiecare pachet de lucru.

În calitate de PM modern, aș spune că ar trebui să facă parte dintr-un sistem de urmărire a sarcinilor. Majoritatea software-ului de gestionare a proiectelor vă oferă posibilitatea de a păstra aceste informații într-un singur loc.

Prin urmare, nu v-aș sugera să creați un document separat. Menținerea dicționarului WBS este o mulțime de muncă. Căutați soluții integrate.

Puteți include orice informații care specifică o componentă în WBS. De exemplu, Dicționarul WBS poate include:

• Descrierea lucrării
• Ipoteze și constrângeri
• Persoane sau organizații responsabile
• Repere
• Activități conexe
• Resurse necesare
• Estimări de cost sau buget
• Criterii de acceptare
• Referințe alte documentații

Deci, orice se potrivește nevoilor dvs. și vă ajută să integrați WBS în alte procese.

Concluzie

„Nu există vânt care să sufle corect pentru marinarul care nu știe unde este portul.”

Nu puteți duce proiectul la un rezultat de succes fără să știți ce trebuie făcut.

Încă o dată, vreau să subliniez acest punct.

Chiar dacă vă aflați în mediul Agile și domeniul de aplicare nu este clar definit pentru întregul proiect, trebuie totuși să planificați o modalitate de a defini, gestiona, urmări și modifica domeniul de aplicare al proiectului.

Ambele pentru un nivel de iterație și rezultatul final al proiectului.

Vă recomand, de asemenea, să citiți:

• Articolul prezentat: Cum să deveniți manager de proiect IT fără experiență
• Următorul în serie: Ghid final despre cum să creați o structură robustă de defalcare a lucrului
• Anterior în serie: Matrice de trasabilitate a cerințelor în gestionarea proiectelor (Ex ample + Șablon)