This is the second in a series of three blogs that I’m be posting on the intimate relationship between Project Management, Knowledge Management (KM), and Risk Management. In the first blog, “The Interdependency of Project, Knowledge and Risk Management”, I made the assertion that there is an intimate relationship between the three disciplines. I also said that Project Managers are in fact Knowledge Managers, and further, that whatever role you have in an organization, understanding this interdependency will enable you to make more informed decisions and make you more effective in executing your job responsibilities.

In this second blog, I’ll try to illustrate the pervasive nature of knowledge management activities within the responsibilities of a Project Manager (PM). To do this, I’m going to provide a fairly detailed summary of what I view as the knowledge management activities that a PM must engage in throughout the life cycle of a project. I’m highlighting those KM activities by using a bold italics font. I hope, in this way to convey just how critical they are in the life of a project and a PM. I’m using an Aerospace Industry Project Management context for my project life-cycle description because that’s what I know best. However, I’m open to, and very interested in hearing your views on how these ideas might apply (or not) to other industries and job responsibilities.

Prior to the initiation of any project knowledge transactions, a necessary pre-condition is the definition and communication of a set of executable business strategies that are based on a compelling vision, and focused by a set challenging, but realistic goals. Future business development activities must be aligned with this business strategy knowledge base. With that alignment achieved, the earliest project knowledge transaction activities can begin. This usually takes the form of business development and project management personnel interactions with customers to build a customer knowledge needs baseline which identifies the wants, expectations and constraints that will focus and define the boundaries of the future project.

The next step is to compare the customer knowledge needs baseline to the existing explicit (documented) and tacit (personnel expertise and experience) knowledge base available in the organization.

In my experience, at this point in the project life cycle, a Project Manager should be selected. The selection of a PM is itself, a heavily knowledge dependent process. Knowledge related selection criteria would typically include technical domain knowledge, customer knowledge, market knowledge, project management knowledge, and leadership skills. It would also be highly influenced by experience, which I would define as the degree to which someone has demonstrated the ability to apply his or her relevant knowledge over time.

Gaps between the knowledge needed to execute the project, and the knowledge available in the organization, then drive many critical decisions. These include: creating new knowledge through research and development; building partnerships and selecting Suppliers to bring in new knowledge; scheduling work to accommodate knowledge resource availability’s; limiting work and knowledge requirement scope; and no-bidding the work because the knowledge gap exposes the organization to unacceptable risk. Knowledge gap closure activities become part of the overall work-scope and are included by the PM in the baseline Project Plan, which might also be considered the What?, When?, Who?, and How? knowledge baseline of the Project . The Project Plan also provides the logical sequencing of the application of the required knowledge resources required delivering to the customer.

The Project Plan to this point is based on what is known, or at least assumed to be known. The PM must now lead a challenge the validity, completeness and stability of those “knowns” and assumptions with a risk assessment. The risk assessment addresses all potential plan element failures and knowledge uncertainties. It identifies and analyzes risks to the satisfactory execution of the plan and leads to the incorporation of risk mitigation task modifications to the basic Project Plan, as well as contingency plans, which can be executed if the risk is realized. It also provides for the application of schedule buffers and budget reserves to reflect this new knowledge. (I’ll address Risk Management in more detail in my third blog)

The Project Plan also defines a process by which information on project execution is gathered via performance metrics. That information is converted to actionable knowledge through an on-going management review and analysis process, which looks at variances to the plan, trends, and risks and implements corrective action plans where necessary.

Now that the “final” plan is base-lined, it can be priced using the business cost estimating knowledge base and proposed to the customer. If selected by the customer, the work-scope and Plan must be refreshed to reflect any new or changed knowledge of customer needs or constraints.

During project execution, the necessary design, analysis, procurement, manufacturing, test and logistics knowledge transactions are sequenced in, and performed by, the knowledgeable people, using their processes, tools and facilities.

Throughout the execution of the project and at project closure, the PM has the responsibility for ensuring that knowledge gained is captured and made available for sharing. Functional Manager are responsible for updating the appropriate business knowledge base resources, training materials, processes and tools and ensuring that learning from this project is available across the business and to future projects.

As you can see, there are a lot of bold italics in this blog. I’ve taken the risk here of being somewhat tedious in highlighting all of these KM activities, but I wanted to clearly illustrate just how pervasive they are in a project management environment and make my point that PM’s must be Knowledge Managers. I firmly believe that thinking about, and acting on, your Project Management responsibilities with a Knowledge Management context will make you and your team more successful.

Coming soon in the final blog in this series… “Project and Risk Management Across the Knowledge Domains”