Organizational Process Assets

Organizational Process Assets

We need to learn from our experiences in the project and others’ experiences within the team and the organization. Otherwise, in today’s cutting edge technology we cannot effort to build everything from the scratch. Organization Process Assets (OPA) is the collection of all the learning at the organization level. Beyond the project, the organizational learning (knowledge) is managed centrally so that future projects can take advantage of the past work of the organization. Some departments should be custodians of these assets. These assets are created, refined, preserved, protected, shared, made available to authorized people by the people of this department. Mainly OPA is categorized into 3 groups.

1. Knowledge shared by the project managers toward the end of the project or phase. Lessons learned.
2. Process assets refined by the quality department or project management office and standards are created for organizational use.
3. Historical data of the previous projects submitted by the project managers to the organization

Some examples of the OPA from the PMBOK in these 3 categories are as below.

Some Facts about Organizational Process Assets (OPA)

Processes and Procedures	Initiating and Planning	Guidelines and criteria for tailoring the OSSP
Specific organizational standards (Human resource policies, safety policies, ethics policies, project management policies)
Templates (risk register, work breakdown structure, project schedule network diagram, contract templates)
Project closure guidelines or requirements (lessons learned, final project audits, project evaluations product validations, acceptance criteria)
Executing, Monitoring, and Controlling	Change control procedures, policies, plans, how any document will be approved and validated
Financial control procedures (time reporting, required expenditure and disbursement reviews, accounting codes, standard contract provisions)
Issues and defect management procedures
Organizational communication requirement (specific communication tech, record retention policy, security requirements)
Procedures for prioritizing, approving, issue work authorizations
Risk control procedures, including risk categories, risk statement templates, probability and impact definition, probability and impact matrix
Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria
Closing	Project closure guidelines or requirements (lessons learned, final project audits, project evaluations product validations, acceptance criteria)
Corporate Knowledge Base		Configuration Management Systems (versions, baselines, org standards, policies, procedures, project documents)
Financial databases containing information (labor rates, incurred costs, budgets, cost overruns)
Historical information, lessons learned, knowledge base (project records, documents, information from risk management activities)
Issue and defect management database (issues, defect status, control information, issue & defect resolution, action items results)
Process measurement database
Project files from previous projects (scope, cost, schedule, performance measurement baselines, project calendars, project schedule network diagram, risk registers, planned response actions, defined risk impact)

Facts about OPA

1. Initiating processes: Both processes need to use OPA
2. Planning processes: Except Collect Requirements, Plan Risk Response all processes need to use OPA
3. Executing processes: Except Perform Quality Assurance, Develop Project Team all processes need to use OPA
4. M&C processes: Except Validate Scope, Control Risks, Control Procurements, Control Stakeholder Engagement all need OPA
5. Closing Processes: Close Procurements does not need OPA
6. By reading this analysis you come to know the importance of OPA in any project. You ignore it because of any reason and nobody forces you to use this but you cannot survive in a project environment by doing so.