Organizational Process Assets – Partea 1

Organizational process assets (OPA) si enterprise environmental factors (EEF) sunt doua elemente care apar ca input sau output la o mare parte din procesele din PMBOK Guide. De asemenea puteti regasi acesti termeni si in unele intrebari de la examenul de PMP.

Conform PMBOK Guide editia a 4-a, OPA se refera la toate resursele ce faciliteaza/reglementeaza desfasurarea proceselor companiei. Ele includ pe de o parte diverse template-uri, politici, proceduri legate de anumite procese, iar pe cealalta parte ceea ce se numeste baza de cunostinte a companiei: lessons learned, date istorice, diverse documente/rapoarte/statusuri/planuri completate din activitati/proiecte anterioare.

Ne vom concentra atentia in acest articol asupra OPA si mai precis asupra celei de a doua componente si anume baza de cunostinte a companiei (n.a. n-am gasit o traducere mai buna pentru corporate knowledge base) cu scopul de a intelege unde si de ce apare ca input/output. Sa le luam pe rand:

– Baza de cunostinte a companiei ca input

Logic este ca informatiile existente deja in companie si din care putem invata ceva sa fie folosite ca input mai ales in zona de Initiating si Planning si mai putin in fazele ulterioare cand doar urmarim/masuram executia proiectului. Mai concret, toate procesele de Initiating si Planning folosesc aceste informatii mai putin:

• Collect Requirements – care doar strange cerintele pornind de la Project Charter si lista de stakeholders
• Develop Schedule, Determine Budget – acestea sunt procese care lucreaza pe baza output-urilor din procesele anterioare. De exemplu, Develop Schedule foloseste estimatele din procesele anterioare de Time Management, foloseste Project Scope Statement si alocarile membrilor echipei pentru a obtine calendarul proiectului. Deci e doar un proces de agregare. Cu toate acestea, ambele procese au OPA ca input dar din punct de vedere al celeilalte componente a OPA si anume template-uri de buget si schedule, politicile bugetare, reguli specifice companiei de a determina timeline-ul proiectului, tool-uri specifice si altele
• Plan Risk Responses – e un proces care pe baza listei de riscuri si a planului de management al riscului planifica raspunsul corespunzator fiecarui risc

Toate procesele de Integration Management folosesc ca input baza de cunostinte pentru ca fiind procese mai generale care coordoneaza de fapt procesele particulare de pe celelalte arii, ele folosesc din plin zona de lessons learned si informatiile istorice tocmai pentru a imbunatati aceasta coordonare. Doar procesul Close Project or Phase are ca si scop, si evident si output, update-uri de OPA in sensul de arhivare a documentelor de proiect, lessons learned etc.

Procesul Conduct Procurements de asemenea foloseste ca input informatii istorice despre diverse companii ce ar putea fi contractate.

– Baza de cunostinte a companiei ca output

Corespunzator, procesele care actualizeaza baza de cunostinte sunt mai ales cele din fazele finale ale proiectului cand se aduna informatii acumulate din proiectul curent pe masura ce monitorizam. Asa se face ca mai toate procesele de Monitoring and Controlling fac update la baza de cunostinte, mai putin procesul de Verify Scope (care nu face decat sa compare livrabilele cu Scope Baseline pentru a se asigura ca tot scopul si doar atat a fost livrat) si cele din aria de cunostinte Integration Management.

Evident toate procesele de Closing fac update la baza de cunostinte a companiei, acesta fiind unul din obiectivele acestor procese.

In zona de Executing, singurele procese care actualizeaza baza de cunostinte sunt:

• Distribute Information – care are ca scop chiar generarea de rapoarte care evident se adauga bazei de cunostinte
• Manage Stakeholders Expectations si Manage Project Team – pentru ca din felul in care se face managementul stakeholder-ilor si al echipei se pot extrage lessons learned

Intr-un articol viitor vom trata OPA din punct de vedere al celeilalte componente, cea de template-uri, politici si proceduri.