In this blog, we will explore the Manage Project Knowledge process, along with its associated inputs, tools and techniques, and outputs.

Manage Project Knowledge is the process of using existing knowledge and creating new knowledge to achieve the project’s objectives and contribute to organizational learning.

This process focuses on both explicit knowledge and tacit knowledge. Explicit knowledge refers to things that can be documented, such as reports, templates, procedures, databases, and project artifacts. Tacit knowledge, on the other hand, exists in people’s minds in the form of experience, insights, judgment, and know-how.

In practice, this process helps us avoid reinventing the wheel by reusing knowledge that already exists within the organization. It also helps us capture new learning generated during the project so that future projects can benefit from it. At the same time, it promotes collaboration and knowledge sharing among team members, stakeholders, and different functional groups.

Now let’s begin with the inputs.

The first input is the Project Management Plan.

The Project Management Plan serves as the primary guide for executing, monitoring, controlling, and closing the project. Each of its components describes how a specific aspect of the project will be managed.

For example, the Scope Management Plan explains how scope will be managed. The Resource Management Plan explains how resources will be acquired and managed. Similar guidance exists for schedule, cost, quality, risk, procurement, communications, and stakeholder engagement.

As the team executes these plans, they inevitably encounter challenges, issues, successes, and opportunities for improvement. All of these experiences become valuable project knowledge.

This knowledge is captured in the Lessons Learned Register and can be reused both within the current project and in future projects across the organization.

In addition, team members document best practices and successful approaches discovered during project execution. These are also added to the Lessons Learned Register to support continuous improvement and knowledge sharing.

Next, let’s discuss the Project Documents.

The first project document is the Lessons Learned Register.

This is the central repository for lessons identified throughout the project. It captures what worked well, what did not work well, and recommendations for the future.

One interesting aspect of the Lessons Learned Register is that it serves as both an input and an output.

As an input, it provides lessons that have already been identified. The team can review these lessons, refine them, and continue building upon them throughout the project.

It also helps prevent the team from repeating the same mistakes during the current project.

The next project document is Project Team Assignments.

This document identifies who is on the project team, along with their roles, responsibilities, skills, and experience.

Knowledge often resides in people rather than documents. This is especially true for tacit knowledge, which is difficult to document and share.

To access this knowledge, we first need to know who possesses it.

Project Team Assignments help us identify subject matter experts, mentors, and key knowledge holders who can participate in knowledge-sharing activities.

Next is the Resource Breakdown Structure, commonly known as the RBS.

The Resource Breakdown Structure organizes project resources into a hierarchical structure based on resource type, skill group, department, or function.

This helps us understand where specific knowledge clusters exist within the organization.

For example, suppose recurring issues involve integration between two systems. The RBS may reveal that these systems are managed by different specialized teams. Based on this information, we can organize knowledge-sharing sessions between those teams to improve collaboration and reduce future integration problems.

The next document is the Stakeholder Register.

The Stakeholder Register contains information about project stakeholders, including their interests, influence, expectations, and communication preferences.

This document helps us identify stakeholders who possess critical knowledge or who need access to important project knowledge.

For example, a regulatory expert may have deep knowledge of compliance requirements. By identifying this stakeholder through the register, we can involve them in knowledge-sharing sessions and document their insights for future projects.

The next input is Deliverables.

Deliverables are the products, services, or results produced by the project.

Deliverables themselves often contain valuable knowledge. Design documents, software code, user manuals, procedures, and process descriptions are all examples of explicit knowledge embedded within deliverables.

Deliverables also create learning opportunities. The process of building, testing, deploying, and receiving feedback on deliverables generates valuable knowledge that can be captured and shared.

For example, a newly developed automated deployment pipeline may become a reusable best practice for future projects.

Next, we have Enterprise Environmental Factors, or EEFs.

These include the organization’s culture, structure, technology infrastructure, industry conditions, and external environment.

Enterprise Environmental Factors influence how knowledge flows throughout the organization.

For example, an organization with a collaborative culture typically encourages knowledge sharing, whereas a highly siloed organization may create barriers to knowledge transfer.

Similarly, if the organization already uses tools such as Microsoft Teams, SharePoint, or a corporate wiki, knowledge-sharing practices can be built around those platforms.

The final input is Organizational Process Assets, commonly known as OPAs.

These include existing knowledge repositories, templates, guidelines, project archives, databases, standard operating procedures, and lessons learned from previous projects.

Organizational Process Assets are often the primary source of reusable knowledge at the beginning of a project.

Throughout the project, we search these repositories for relevant information, best practices, and historical lessons.

At the end of the project, we contribute newly created knowledge back into these repositories so future projects can benefit from it.

Now let’s move on to the tools and techniques.

The first tool is Expert Judgment.

Experts can help identify what knowledge is most valuable, how it should be captured, and how it can be reused effectively.

They can distinguish between useful knowledge and unnecessary information. They can also recommend appropriate formats such as playbooks, training materials, templates, or best-practice guides.

The next technique is Knowledge Management.

Knowledge Management focuses on sharing both tacit and explicit knowledge through collaboration and social interaction.

Examples include retrospective meetings, training sessions, workshops, mentoring, webinars, communities of practice, and informal discussions.

The goal is to ensure that valuable knowledge flows between people and teams.

Next is Information Management.

Information Management focuses on capturing, storing, organizing, retrieving, and sharing explicit knowledge.

Without a structured information management system, knowledge becomes fragmented and difficult to locate.

For example, a project wiki containing architecture decisions, technical guides, operating procedures, FAQs, and lessons learned makes knowledge easy to access and reuse.

The next technique is After Action Reviews, often called AARs.

An After Action Review is a structured discussion conducted after a significant event such as a release, incident, milestone, or iteration.

The discussion focuses on what was expected to happen, what actually happened, why the differences occurred, and what can be improved.

These reviews help convert experience into explicit knowledge that can be documented and shared.

Next are In-Progress Postmortems.

Unlike traditional postmortems that occur at the end of a project, these reviews take place during project execution.

They help capture learning while experiences are still fresh and allow improvements to be applied immediately within the same project.

Another important technique is Storytelling.

People often communicate tacit knowledge more effectively through stories than through formal reports.

Stories provide context, emotions, challenges, and decision-making rationale that make knowledge easier to understand and remember.

For example, a senior architect may share a story about how a rushed design decision nearly caused a project failure. Such stories often leave a stronger impression than reading a formal document.

Next are Retrospective Meetings.

Retrospectives are commonly used in agile environments and provide regular opportunities for teams to reflect on how work is being performed.

The team discusses what is working well, what needs improvement, and what actions should be taken moving forward.

Retrospectives create a continuous learning culture and generate valuable inputs for the Lessons Learned Register.

Finally, we have Interpersonal and Team Skills.

These skills are essential because most valuable knowledge exists in people’s minds.

Active listening helps us understand and capture tacit knowledge accurately.

Facilitation helps guide discussions, workshops, and knowledge-sharing sessions effectively.

Leadership encourages a culture of learning and openness where people feel comfortable sharing experiences and lessons.

Networking helps project managers connect with individuals who possess valuable knowledge across the organization.

Political awareness helps manage sensitive situations involving mistakes, conflicts, and failures while still ensuring learning takes place.

Now let’s discuss the outputs.

The first output is the Lessons Learned Register.

As the project progresses, the team continuously captures new knowledge, including successes, failures, recommendations, best practices, and improvement opportunities.

All of this information is documented in the Lessons Learned Register.

The next output is updates to the Project Management Plan.

As new insights are gained, adjustments may be needed in the way the project is managed.

Relevant components of the Project Management Plan are updated to reflect improved approaches, corrective actions, and optimized processes.

The final output is updates to Organizational Process Assets.

The knowledge generated during the project should not remain limited to the current project team.

Lessons learned, best practices, templates, and improvements are added to Organizational Process Assets so that future projects can benefit from the knowledge created.

And that’s it.

With that, we’ve completed the Manage Project Knowledge process.

I hope you enjoyed this blog and now have a solid understanding of how project knowledge is captured, shared, reused, and transformed into organizational learning.