6th Edition PMBOK® Guide–Process 4.4 Manage Project Knowledge: Inputs

In the 6th Edition of the PMBOK® Guide, there are 49 project management processes, divided into five process groups and ten knowledge areas.   In the 5th Edition, there were 47 processes.   So it turns out that the Project Management Institute added a few processes, and this is one of them.   Manage Project Knowledge is a new process in the Executing process group that is covered by the Integration knowledge area.

Manage Project Knowledge is about using existing knowledge within the organization to achieve the project’s objectives and then using new knowledge gained on the project to contribute to the organization”s body of knowledge.   This new knowledge is referred to as lessons learned, and in the past 5th Edition of the PMBOK® Guide, this was collected during the final process called Close Project or Phase.

The “lessons learned” document was then given to the organization’s Project Management Organization so it could be used on future projects to guide project managers by helping them avoid the same mistakes and to assist them in dealing with similar issues on their projects.

However, since the publication of the 5th Edition, the “best practice” of companies with regards to lessons learned has evolved, due to the influence of agile project management methodologies.    In agile, at the end of each iteration or sprint, there is a review called a “retrospective” which, among other things, documents the issues encountered that have been resolved and the lessons learned from them.    This does two things:  it helps the current project by helping the project team take corrective action in real time to improve the performance of the project, and secondly, it helps future projects by adding to creating a lessons learned register which can capture and share the knowledge gained to the organization at large.

Those companies doing traditional or waterfall project management methodology took note of this and started doing the same on their projects, by incorporating the process of creating lessons learned during the project and not just at the end of it as had been done before.   By the time of the 6th Edition PMBOK® Guide, PMI had recognized this sea change with regards to the lessons learned process, and enshrined in its own new process, 4.4 Manage Project Knowledge.

This process is a prime example of the way that agile project management methodologies are profoundly shaping the way that ALL projects are done, including those still done with the traditional or waterfall methodology.

This post will discuss the inputs to this process,

  • the project management plan and project documents (outputs of process 4.2 Develop Project Management Plan)
  • deliverables (outputs of process 4.3 Direct and Manage Project Work)
  • the “generic” inputs of Enterprise Environmental Factors (EEFs) and Organization Process Assets (OPAs)

4.4.1 Manage Project Knowledge:  Inputs Project Management Plan

All components of the project management plan are inputs to this process.   Remember, the project management plan is the main output of process 4.2 Develop Management Plan, along with project documents (see next paragraph).  In the course of doing the project work in process 4.3 Direct and Manage Project Work, there may be some issues related to the project management plan that need to be resolved.  For example, if the estimates for time and/or cost for a particular activity turn out to be inaccurate, then rather than trying to change the work to fit the unrealistic plan, it may be necessary to change the plan.   The new knowledge gained which caused people to realize that the plan was inaccurate may be just the sort of thing that you would want to include in the lessons learned register, so that other people doing similar projects won’t make the same mistake.  Project Documents

The other main output of process 4.2 Develop Project Management Plan which is in turn used as an input for this process are certain project documents, such as the following:

  • Lessons learned register (also an output of this process)–this is the document to which new lessons learned will be added.   Notice that it is called a “register” which implies a system of categorization that will make it easier for people to find information stored in it.   Also, a register is something to which you add entries on a regular basis, implying that it is a “living document” that will continue growing throughout the project.   The existing register is an input to the process, the process itself updates it, the resulting updated document is then an output of the process.
  • Project team assignments (output of process 9.3 Acquire Resources)–this may provide information on the type of competencies and experience available in the project, so that any gaps in the knowledge and/or experience required on the project can be identified and then filled (by training existing resources or acquiring new resources with that knowledge and/or experience).
  • Resource breakdown structure (output of process 9.2 Estimate Activity Resources)–this provides information on the composition of the team and the various roles of its members, so that any gaps in the knowledge required by the project can be identified and then filled (by rewriting descriptions of roles or adding new roles).
  • Stakeholder register (output of process 13.1 Identify Stakeholders)–this contains details about identified stakeholders to help understand the knowledge they have.   If they have knowledge that is pertinent to one of the lessons learned on the project, then may need to be consulted.  Deliverables

A deliverable is the product of a work package, a “bite-size” portion of the scope, like a piece of the puzzle that is put together to form the final work product.   These are tangible components completed to meet work requirements.   The deliverables created in the time since the last lessons learned review may be reviewed in order to come up with new lessons learned.   Enterprise Environmental Factors

These are factors which are contained in the environment the project is done in:   the organizational environment, the social, culture and political environment, as well as the legal and regulatory environment.

The various types of environment are outlined in the diagram below, taken from the website.


There are interior/collective CULTURAL aspects of the organization (its values, mission statement, etc.) , and its exterior/collective SYSTEMS (processes, procedures, etc.).   These are within the organization, but there are the same categories within the larger circle of the society itself, the CULTURAL aspects of society as well as the SYSTEMS (for example, the legal and regulatory environment).



Here are the EEFs that can influence this process 4.3 Manage Project Management

  • Organizational, stakeholder, and customer culture (lower left quadrant in the diagram above)– in order to manage knowledge, it needs to be shared, and sharing implies a relationship of trust in the working relationships between members of an organization, and with stakeholders including customers.
  • Geographic distribution of facilities and resources (lower right quadrant in the diagram above)–location of team members determine methods for gaining and sharing knowledge (how will knowledge gained be added to the organization, and how will such information be accessed by its members).
  • Organizational knowledge experts (lower right quadrant in the diagram above)–these are individuals or a team of people in the organization who specialize in knowledge management.
  • Legal and regulatory requirements and/or constraints (lower right quadrant in the diagram above in a larger circle including society)–this relates specifically to the confidentiality of project information. Organizational Process Assets

Organizational process assets or OPAs such as project management processes and procedures have embedded in them knowledge gained about projects done in the past.   The new knowledge generated in a project that is the subject of this process will therefore directly affect these very OPAs, such as the following:

  • Organizational standard policies, processes, and procedures regarding knowledge management, such as
    • Confidentiality and access to information
    • Security and data protection (passwords, encryption, etc.)
    • Use of copyrighted information
    • Destruction of classified/proprietary information
    • Maximum size and format of files
    • Lessons learned data and metadata
    • Authorized social media
  • Personnel administration
    • Employee development and training records
    • Competency frameworks
  • Organizational communication requirements
    • Formal, rigid communication requirements–good for sharing information
    • Informal communication requirements–good for creating new knowledge and integrating knowledge across diverse stakeholder groups
  • Formal knowledge-sharing and information-sharing procedures
    • Scheduling learning reviews during project phases and at the end of project phases
    • Methods of identifying, capturing, and storing lessons learned in the lessons learned register

Okay, so that gives us all the ingredients to create a lessons learned register.   But how are those lessons created?    To understand this, it is necessary to some of the theory of knowledge management, which I will do during the next post on the tools and techniques of process 4.4 Manage Project Knowledge.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: