4squareviews

Oksy, you now have been given a change request as an input to this process.   How do you actually go about evaluating the request so you can either accept or reject it?   The following blog post lists the tools & techniques you will need to use in order to do this.

4.6.2 Perform Integrated Change Control:  Tools & Techniques

4.6.2.1  Expert Judgment

Any time you have a decision-making process, like this one, PMI is going to at minimum recommend two tools:  Expert Judgment and Meetings.   Expert judgment because you want the best inputs into the decision, and Meetings (see paragraph below) because you want the best forum to make that decision.

4.6.2.2  Change Control Tools

Change Control Tools in this context does not mean the Change Control Board alone, but also the tools used, let’s say, if a change request is approved.  (If the change is rejected, it gets recorded in the project document called the change log.)

If a request is approved, that means there will have to be changes in the project management plan.   How can you make sure that everybody working on the project or stakeholders monitoring the project use the “new and improved” version of the project management plan, and don’t up using one of the older, obsolete versions instead?   That is where the configuration management plan comes in.    The details of these activities are contained in the PMBOK Guide.

The other tools used are for managing the change request and the resulting decisions, including action items to implement the change.   These tools have to be accessible to all those who responsible for implementing those changes.

4.6.3.3  Data Analysis

Cost-benefit analysis helps analyze the requested change in terms of costs and benefits:  will the costs of the change be more than the benefits it will create?

Alternatives analysis uses criteria to evaluate the change requests so that they may not only be accepted or rejected, but perhaps modified by alternatives.

4.6.2.4  Decision Making

These techniques include the following:

• Voting–get take the form of unanimity, majority, or plurality (the most votes even if no one block of votes gets a clear majority)
• Autocratic decision making–one individual takes the responsibility for making the decision for the entire group
• Multicriteria decision analysis–a systematic analytical approach to evaluate requested changes according to a set of predefined criteria

4.6.2.5  Meetings

Change control meetings are held by the change control board.   Remember the main work of this meeting is to analyze the impact the proposed change will have on constraints on the project such as time, cost, resources, or risks.    Then the requested changes are discussed along with any alternatives using the data analysis techniques outlined in paragraph 4.6.2.3.   Finally, a decision is made using the decision making techniques outlined in paragraph 4.6.2.4 and the results are communicated to the stakeholders, and the change is managed using change control tools outlined in paragraph 4.6.2.2.

The next post will cover the outputs of this process.

Filed under: Uncategorized | 2 Comments »

In the last process, 4.5 Monitor and Control Project Work, one of the main outputs that can occur as a result of that process are change requests, in the form of

• Defect repair–an activity that modifies a nonconforming product or product component
• Corrective action–an activity that realigns the performance of the project work with the project management plan
• Preventive action–an activity that ensures the future performance of the project work is aligned with the project management plan.

There is a fourth type of change requests as well.   Let’s say that in analyzing the variance between the project work and the project management plan, that it was discovered that the project management plan was unrealistic because of information uncovered during the process 4.5 Monitor and Control Project Work.   Then the change request might be to change a component of the project management plan to fit a more realistic estimate.   So instead of changing the work to fit the plan as in the three categories above, you might have to change the plan to fit the work…

Now at this point, a change request is simply that, a request.   The decision as to whether  it gets implemented or not is the purpose of this process.   The change can be a change to the product scope (i.e., changes to the features and functions of the product being created by the project) or to the project scope (i.e., changes to the work performed to deliver a product).

An orderly approach to this process is essential to avoid the bane of a project manager’s existence called scope creep.   In a study group session, I once joking gave a definition of that term as when some creep starts messing with your scope.    Well, that may be how it feels as a project manager, but the actual definition is the “uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.”   So you and your project team are expected to do more and more with the same resources, putting more and more pressure on your team.   When you are the project manager responsible for the success of the project, that puts you in a difficult position.

One way to spread the responsibility is to have a Change Control Board, which reviews the change requests and analyzes their impact on the various constraints of the project such as time, cost, and resources, and accepts or rejects them based on criteria established in the change management plan.

Let’s go over are the inputs to this process:

4.6.1  Project Management Plan

The components of the project management plan that are inputs to this process include:

• Change management plan–this provides the instructions for managing the change control process, including the roles and responsibilities of the Change Control Board (CCB).
• Configuration management plan–if a change request is accepted, then the project management plan will be altered and perhaps the product scope as well.   The configuration management plan establishes a system to distinguish the various versions of the product/project scope so that everyone is literally on the same page working on the current configuration and not mistakenly working off of a version that is obsolete.
• Scope/cost/schedule baselines–these baselines are used to assess the impact of the changes to the product/project scope on the project cost and/or schedule.

4.6.1.2 Project Documents

The following project documents may be used to help analyze the impact of change requests.

• Basis of estimates–this shows how the duration, cost, and resources estimates were derived and can be used to calculate the impact of the proposed change of product/project scope will have on the project schedule, budget, or resources.
• Requirements traceability matrix–this helps assess the impact of the proposed change on the project scope
• Risk report–this helps show the impact of the proposed change on overall and individual project risks.

4.6.1.3 Work Performance Reports

These are the outputs of process 4.5 Monitor and Control Project Work.   This contains not only schedule/ cost data, and earned value analysis, but also an analysis of the causes of variation.

4.6.1.4 Change Requests

Change requests are the outputs of the last process 4.5 Monitor and Control Project Work but may be an output of the Executing process 4.3 Direct and Manage Project Work as well.   These are the requests that the Change Control Board or other mechanism described in the Change Management Plan will evaluate and either approve or reject.

4.6.1.5  Enterprise Environmental Factors

The following EEFs may influence this process:

• Legal restrictions, legal and regulatory requirements and/or constraints
• Government or industry standards
• Organizational governance framework
• Contracting and purchasing constraints

4.6.1.6  Organizational Process Assets

The following OPAs may influence this process:

• Change control procedures (spelled out in the Change Management Plan component of the Project Management Plan), including procedures for approving and issuing change authorizations (e.g., different levels of authorization may be required for changes that exceed certain thresholds in terms of their impact on the schedule and/or budget)
• Configuration management knowledge base–contains organizational standards regarding how configurations of a project and/or product are to be organized

The next post will cover the actual tools and techniques of this process.

Filed under: Uncategorized | Leave a comment »

This process includes monitoring the actual work done on the project and comparing it to what is in the project management plan.   If there are variances from the plan, then the process analyzes the cause of the problem and a solution to the problem is recommended in the form of change requests which can include changes to the project management plan itself as well as to project documents.   Another important part of this process is letting the stakeholders know the status of the project, and this is done through work performance reports.

Let’s go throughout the outputs of this process in more detail.

4.5.3 Monitor and Control Project Work:  Outputs

4.5.3.1 Work Performance Reports

Let’s take the work performance data that is generated during the process 4.3 Direct and Manage Project Work.   This is then compared to the project management plan in the control processes of the various knowledge areas.   For example, with regard to Schedule Management, let’s say the work performance data is that “during the past week, John worked on the project 20 hours, and Mary worked on the project 20 hours.”   In the process 6.6 Control Schedule you would compare these actual hours worked with what was supposed to have been done according to the schedule.   Let’s say the schedule shows that John was supposed to work 30 hours, and Mary was supposed to work 20 hours.   Then we know that someone John worked 10 hours less than he was scheduled to.   This can even be put into a schedule performance index or SPI by calculating 40 hours (actual)/50 hours (scheduled) or 0.80.

This SPI of 0.80 is work performance information that is now input into this process 4.5 Monitor and Control Project Work.   Here an analysis is done as to WHY John worked only 20 hours rather than 30 as scheduled.   If John says, “hey, my operational manager told me I had to work on something else”, then the question becomes is this a temporary problem, i.e., was this request for John’s time something that won’t happen the following week?   If so, then John can make up the lost hours next week and the project will be back on track.   However, if John’s operational manager says there will be ongoing duties that John has to take care which will prevent him from doing more than 20 hours of work on the project, then the project manager will have to discuss with the operational manager what kind of accommodation can be done in the future.   This kind of analysis of what kind of action will be taken to solve a problem is something that goes in the work performance report.   It is sent to the stakeholders, therefore, because their help may be needed to take action that will solve the problem.

4.5.3.2  Change Requests

As a result of the data analysis techniques done during this process, change requests may be generated, such as:

• Defect repair–activity to modify a nonconforming product
• Corrective action–activity that realigns the performance of the project work with the project management plan.
• Preventive action–activity that ensures that future performance of the project work is aligned with the project management plan

4.5.3.3.  Project Management Plan

Let’s say a variance is discovered between the actual project work done and what is in the project management plan.   It is possible that in analyzing the reason for the variance that the cause will not be a problem with the work done, but with the project management plan itself, in that it was unrealistic to begin with.  In which case, a component of the project management plan may need to be changed so that the plan is made to fit the work rather than the situation above with the change requests, where the work is made to fit the plan.

4.5.3.4  Project Documents

In addition to  the project management plan, the following documents may need to be updated as a result of this process.

• Issue log–new issued raised as a result of this process are recorded in the issue log
• Lessons learned register–effective responses to variances, including corrective and preventive actions, are updated to this register
• Cost/schedule forecasts–changes in cost or schedule forecasts resulting from this process are recorded
• Risk register–new risk identified during this process are recorded

If there are any change requests, these are processed in the next process 4.6 Perform Integrated Change Control, which will be the subject of the next post.

Filed under: Uncategorized | Leave a comment »

The tools and techniques used for monitoring and controlling the project work are pretty general:   expert judgment, decision making, and meetings.   These are just generically described below.  But there is one set of tools that is very specific and those are data analysis techniques.   These will be described in more detail.

4.5.2 Monitor and Control Project Work:  Tools & Techniques

4.5.2.1 Expert Judgment

This is judgment provided by individuals who have expertise in the data analysis techniques that are described in the next paragraph.

4.5.2.2 Data Analysis Techniques

These techniques that can be used include the following:

1.Detection

First of all, there are the techniques that are used to detect whether there is a variation or not.

Earned value analysis–provides an integrated perspective on scope, schedule, and cost performance.

Variance analysis–reviews the differences between planned and actual performance.

Trend analysis–used to forecast future performance based on past results.

2. Diagnosis

Once a variation is detected, then you diagnosis the source of the variation.

Root cause analysis–identifies the main reasons for a problem that is causing a variation.

3.Corrective and/or Preventive Actions

Once the root cause of a problem that is causing a variation is identified, the various possibilities for a solution are investigated and the best solution is chosen to correct the problem.

Alternatives analysis–used to select the combination of corrective actions and/or preventive actions to implement

Cost-benefit analysis–helps determine the best corrective action in terms of cost in case of project deviations.

These techniques are designed to generate a change request which, when implemented, will solve the problems identified.

4.5.2.3  Decision Making

If there are several alternatives suggested to solving a particular problem, then the data analysis techniques listed above of alternatives analysis and cost-benefit analysis are used to help the project team decide on the best solution.   Decision-making techniques can include voting and the outcome can be based on unanimity, majority, or plurality (the greatest number of votes gathered even if not a majority).

4.5.2.4  Meetings

Meetings are tools where project team members gather to use the data analysis techniques and expert judgment to make a decision regarding the best course of action to take in order to solve problems discovered during the monitoring of the project.

The outputs of this process are discussed in the next post…

Filed under: Uncategorized | Leave a comment »

With this process, we are moving in to the Monitoring & Controlling Process group.   The work that is being done in the process 4.3 Direct and Manage Project Work is tracked and reviewed to see if it is meeting with the performance objectives defined in the project management plan.   The results of this analysis are then reported to various stakeholders.   If the analysis shows that there is a variance from the project plan,  then corrective action in the form of change requests may be recommended.

Let’s take a look at the inputs to this process.

4.5.1..1 Project Management Plan

We need to have the project management plan and all its components to compare it to the actual results that have been accomplished.

4.5.1.2  Project Documents

Besides the project management plan, several project documents may be inputs to this process.   Rather than simply list the bullet points listed in the PMBOK® Guide, let me divide the documents by knowledge area:

Integration Management

Assumption log–contains information about assumptions and constraints affecting the project.

Issue log–used to document and monitor who is responsible for specific issues by a target date.

Lessons learned register–may have information on effective responses for variances, and corrective and preventive actions.

Scope Management

Schedule Management

Basis of estimates–indicates how estimates were derived and can be used to make a decision on how to respond to variances.

Milestone list–shows the scheduled dates for specific milestones and is used to check if the planned milestones have been met.

Schedule forecasts–used to determine if the project is within defined tolerance ranges for schedule and to identify necessary change requests.

Cost Management

Cost forecasts–used to determine if the project is within defined tolerance ranges for budget and to identify any necessary change requests.

Quality Management

Quality reports–includes

• quality management issues
• recommendations for process, project, and product improements
• corrective actions recommendations (rework, defect/bugs repair, 100% inspection, and more)
• summary of findings of the Control Quality process

Risk Management

Risk register–provides information on threats and opportunities that have occurred during project execution.

Risk report–provides information on the overall project risks as well as information that have occurred during project execution

Procurements Management

Agreements (see paragraph 4.5.1.4 below)

4.5.1.3  Work Performance Information

Work performance data is gathered from the process 4.3 Direct and Manage Project Work and is passed to the controlling processes for the various knowledge areas (Control Scope, Control Schedule, Control Costs, etc.).   In these control processes, the work performance data is compared with the corresponding component of the Project Management Plan (input 4.5.1.1) and Project Documents (input 4.5.1.2).   The results of this comparison are turned into work performance information which is useful to the project team when doing the process 4.5 Monitor and Control Project Work.   This information may include metrics that measure performance with regards to cost and schedule and can tell a project manager whether the project is on schedule, on budget, or whether there is a variance.

4.5.1.4  Agreements

If there is a procurement agreement with a contractor, then the project manager may need to monitor the contractor’s work to compare it with the agreements (i.e. contracts) made with that contractor.

4.5.1.5  Enterprise Environmental Factors

The EEFs that can influence the process 4.5 Monitor and Control Project Work are:

• Project management information system (PMIS) such as Microsoft Project
• Infrastructure (facilities, equipment, telecommunications channels)
• Stakeholders’ expectations and risk thresholds
• Government or industry standards

4.5.1.6  Organization Process Assets

The OPAs that can influence the process 4.5 Monitor and Control Project Work are:

• Organizational standard policies, processes, and procedures
• Financial controls procedures (required expenditure and disbursement reviews, accounting codes, standard contract provisions)
• Monitoring and reporting methods
• Issue management procedures (issue controls, issue identification, resolution and item tracking)
• Defect management procedures (defect controls, defect identification, resolution and action item tracking)
• Organizational knowledge base (process measurement, lessons learned repository)

The next post will cover the actual tools and techniques used in this process.

Filed under: Uncategorized | Leave a comment »

Today I am concluding my series of posts are this process by talking about the outputs of the process.    When looking at the outputs, don’t just look at what the output is, but look at where it is going–outputs of one process become the inputs to another process, and it is helpful to know what process that output is going to feed into.

4.4.3  Manage Project Knowledge:  Outputs

4.4.3.1 Lessons Learned Register

Well, this is the whole focal point of the process, to create this project document.   In the past (i.e., in the 5th Edition of the PMBOK® Guide, this document was created at the end of a project, and the insights gained were meant to help project managers who are in charge of similar projects in the future.   But in agile project management methodologies such as Scrum, the discussion of lessons learned is not done at the end of the project, but at the end of each sprint or iteration (it is part of what is called a Sprint Retrospective).   The benefits of this lessons learned discussion now benefited not just some future project, but the current project itself.    PMI thought that this benefit should be realized in the more traditional or waterfall project management methodologies as well, so the process 4.4 Manage Project Knowledge was added in the 6th Edition of the PMBOK® Guide.

Okay, what kind of things are in a lessons learned register?

• Challenges or problems faced by the project team
• Realized risks and opportunities, that is, risks that actually occurred and became issues, and what the risk response was that dealt with them

Who creates the lessons learned register?   The members of the project team, because it is their experience on the project that creates the raw material for the lessons learned.

This document is created early in the project and is updated periodically.   The lessons can be captured in the written document called the lessons learned register, but there are additional ways of capturing knowledge gained, such as audios (podcasts), videos (e.g. YouTube), etc.

At the end of the project, the lessons learned on a project are transferred to the organizational process asset called the lessons learned register (see paragraph 4.4.3.3 below)

4.4.3.2  Project Management Plan Updates

The lessons learned on a project usually have to do not with the product of the project, but the process of doing the project.   However, one of the lessons that can be learned on a project is that the original project management plan is unrealistic given new information or new conditions that occur on a project.   In that case, one of the project management plan components may need to be updated (after the change request is approved through the process 4.6 Perform Integrated Change Request).

4.4.3.3 Organizational Process Assets Updates

The new knowledge created on a project and codified in the lessons learned register can be transferred to the organization as a whole through the organizational process asset known as the lessons learned repository.    It is possible that an idea for a new procedure is created as a result of one of these lessons learned, and the project then serve as a “pilot” for that procedure.

This is important, because it is important to have projects serve as incubators for change within the organization.  At the discussion had at the Project Management Institute’s Executive Council, where I was the director in 2016-2017, centered around this theme, and one of the members of the council said that sometimes there would be a great breakthrough created on a project due to the creative collaboration that existed on the project team.   The members of the team would leave the project in an evangelical mood trying to convince others to use this breakthrough on their project.   However, if the organization at large did not have a way to incubate these new ideas, then as he put it “the corporate antibodies” would attack the new idea and make sure it never got implemented outside of that project.    The antibodies he referred to were people who liked the status quo and who were therefore resistant to change.   But if management can create an atmosphere conducive to change, and create structures in place to encourage change (such as the creation of a lessons learned repository), then the organization will permanently benefit by the results created on temporary projects.

Now, the next process takes us from the Executing process group to the Monitoring and Controlling process group with the process 4.5 Monitor and Control Project Work.

Filed under: Uncategorized | 2 Comments »

I was going to do a post on the outputs of the Process 4.4 Manage Project Knowledge which I have blogging about over the past few days. However, my laptop computer has decided to start a seemingly interminable series of software updates, so I thought I would take advantage of my smartphone and write a relatively shorter post.

I discussed in a previous post about the distinction between explicit knowledge, the kind you can get from reading a book or watching a video, and tacit knowledge, the kind you can get only from experience. How do you share this kind of knowledge? Through conversations and interactions with people. As a Toastmaster, I can tell you the best way I have found to convey this kind of information is through a story or anecdote.

The first level of certification for project management is called Certified Associate in Project Management. This requires explicit knowledge about project management processes as laid out in the PMBOK Guide. However, you can pass the exam without having any actual experience on a project, just explicit or “book” knowledge.

However, the higher level of certification, the Project Management Professional or PMP, does require tacit knowledge or actual experience as a project manager. This requirement is in he form of a certain number of hours of experience required.

But the written exam also tries to test for tacit knowledge, which is harder than testing for explicit knowledge. How do you write a question that tests whether you have internalized the lessons of being a good manager through hard-won experience?

This is where the scenario question comes into play. This is a question that describes a situation through explicit details about a hypothetical project you are on as a project manager. Then it will ask you what to do next, or what is the best course of action? Of course this is not a free-form answer like an essay question–it is a multiple-choice question so you are given four possibilities to choose from.

What you are expected to know is tacit knowledge about project knowledge in the form of assumptions informally called “PMI-isms”. For example, in the area of change management:

• Avoid unnecessary changes to the project scope
• When you receive a change request from upper management, your next task is analyze the impacts of that change on the project’s constraints (usually time and cost).

These are assumptions, and if you know them then you can answer such a scenario question even if you have not had the particular experience described in that scenario.

However, assumptions such as the first one may not be true in certain situations–avoiding unnecessary changes is a mindset that is definitely NOT present in agile project management. An additional assumption in agile project management is that you need to prioritize the various constraints in terms of there importance to the customer at the beginning of the project to help guide the decision process after the analysis listed on the second bullet point above is complete.

That is why I liked studying with the Rita Mulcahy PMP Exam Prep study guide when I was helping our study group prepare for the exam back in 2012. It had an entire section devoted to these PMI-isms because understanding them will help you pass the exam. Whatever textbook you use, make sure it spends some time on these assumptions, because they contain the tacit knowledge PMI wants you to have as a project manager!

Well, assuming my computer updates itself in the next 24 hours, I will return to my regularly scheduled post, outputs of the process 4.4 Manage Project Management, tomorrow.

Filed under: Uncategorized | Leave a comment »

The Process I am describing today has its origins in the “lessons learned” exercise traditionally done in project management at the end of a project.   However, due to the influence of agile project management methodologies, the project management community gradually created the new “best practice” of creating a lessons learned register during the course of a project.   That is what this process is about, although it is not limited to the production of a lessons learned register.   Let’s see what tools and techniques can be used to take the knowledge, both

• explicit knowledge in the form of things learned on a project that can be written down in places like the lessons learned register
• tacit knowledge in the form of experience and insights gained

This latter form of knowledge is internal to the person holding it and it can only be shared through conversations and interactions with people.    The way these two types of knowledge are managed are different, as can be seen in the paragraphs below.

4.4.2 Manage Project Knowledge:  Tools & Techniques

4.4.2.1 Expert Judgment

You should consider gaining knowledge from individuals or groups with specialized training or expertise, such as those with training in knowledge management, information management, organization  learning, or other topics.

4.4.2.2 Knowledge Management

You need to connect people so that they can share tacit knowledge and then integrate the knowledge of diverse team members.   Here are some examples of ways to share tacit knowledge gained on a project.

• Networking–in particular social networking on an intranet system like Sharepoint
• Communities of practice–like monthly meetings of the local chapter of the Project Management Institute
• Discussion forms such as focus groups–like “lunch and learn” forums held by many companies

There are many other examples given on p. 103 of the PMBOK Guide.

4.4.2.3  Information Management

Information management tools (such as a Project Management Information System or PMIS like Microsoft Project) can be used to create documents that can share more explicit forms of knowledge gained on a project.

These documents can codify explicit knowledge so that a person trying to solve a particular problem can type in a search word or phrase to find relevant entries in the documents.

4.4.2.4  Interpersonal and team skills

The sharing of knowledge first requires setting up a relationship of trust between the people sharing that knowledge.   That is why interpersonal and team-building skills are useful because they can help create and nurture those relationships based on trust.   Some of these skills are:

• Active listening–acknowledging, clarifying and confirming, understanding, and removing barriers that adversely affect comprehension
• Facilitation–effectively guiding a group event to a successful decision, solution, or conclusion.    A facilitator ensures
  • effective participation
  • mutual understanding between participants
  • consideration of all contributions
  • the achievement of full buy-in or consensus regarding any conclusions or results achieved by the group, and
  • the taking of appropriate actions to follow-up on those conclusions or results
• Leadership–because a project is done by people, a leader demonstrates skills that guide, motivate and direct the people on a project team.  Such skills include:
  • Negotiation
  • Resilience
  • Communication
  • Problem solving
  • Critical thinking
  • Interpersonal skills
• Networking–interacting with others to exchange information and develop contacts in order to solve problems, influence actions of stakeholders, and to increase stakeholder support for the project
• Political awareness–engaging stakeholders appropriate in order to maintain their support throughout the project

So you can see that, where the origin of this process is the lessons learned register (and indeed that is one of the main outputs of the process), it is much larger and includes the larger set of relationships the people on a team have to their organization , their industry, their profession, and to society itself.

The next post will cover the outputs of this process.

Filed under: Uncategorized | 1 Comment »

Before I list the tools and techniques involved in this process in the next post, let me first make some distinctions that PMI makes in its discussion of Manage Project Knowledge.

• Work performance data, work performance information, and work performance reports–work data is generated during the process 4.3 Direct and Manage Project Work.   For example, John worked 20 hours last week on the project and so did Mary.   Work information would take that data, and then make it meaningful to the project team by comparing it to the plan.  If they both were supposed to work that many hours, then fine, the Schedule Performance Index for that work period will be 1.00.   However, if John was supposed to work 40 hours, then only 40 (20 for John plus 20 for Mary) out of 60 scheduled hours were actually done, and the Schedule Performance Index is now, 40/60 or 0.67.   This is work performance information, because it is useful to the team:   it tells them they’re behind schedule!  If they go back to John and find out this is just a temporary problem, and that he will able to make up the time either on the weekend or the following week, then fine.   However, if John says that going forward he is going to only be able to work 20 hours on the project because of other work his functional manager has him doing, then that may be a problem.   The problem uncovered by the work performance information and its solution might be contained in a work performance report, that goes to selected stakeholders.
• Information vs. knowledge–this is not explicitly as stated in the PMBOK® Guide as I would like.   However, it seems that work performance information is related to a specific project, but knowledge has a more general context, and is therefore transferable from project to project.   That is why knowledge from previous projects is incorporated in Organizational Process Assets such as company guidelines, processes, and procedures, so it can be used on future projects.   However, this body of knowledge is not static; there are lessons learned on a project which could help future projects and that is why the lessons learned register is created by this process, to help transfer new knowledge back to the organization at large.
• Explicit knowledge vs. implicit knowledge–Explicit knowledge is something that can be written down and codified, whereas implicit knowledge is the skills, experience and expertise that people gain during a project.    Explicit knowledge can be shared using information management systems (see next paragraph), but implicit knowledge is not external but internal, and is only transferable by sharing that experience through conversations and interactions with people.
• Information management vs. knowledge management–systems for information management include a Project Management Information System such as Microsoft Project, and of course the lessons learned register itself that is compiled during the course of a project.   However, knowledge management techniques are many, because you can share with someone in your company, in discussion forums or meetings, or with someone in your industry, at meetings of communities of practice like the dinner meetings that are held chapters of the Project Management Institute.

The fact that knowledge is shared by conversations and interactions with people means that people who are introverted, like myself, who find these activities more difficult than people who are extroverted, will find themselves potentially at a disadvantage.   This is why I recommend Toastmasters International for anybody who is a project manager; many Project Management Institute chapters have their own Toastmasters club (like the Chicagoland club I belong to), and here you can practice on interactions with people in a supportive atmosphere which will allow you to develop the confidence you need to be able interact with others and transfer knowledge back and forth about project management.

With these distinctions in mind, then, let’s turn to the tools and techniques of this process Manage Project Knowledge in the next post…

Filed under: Uncategorized | Leave a comment »

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

4.4.1.1 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.

4.4.1.2  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.

4.4.1.3  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.

4.4.1.4   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.

The Integral Model

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.

4.4.1.5 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.

Filed under: Uncategorized | 2 Comments »