6th Edition PMBOK® Guide–Process 4.6 Perform Integrated Change Control: Tools & Techniques


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.

 

Advertisements

6th Edition PMBOK® Guide–Process 4.6 Perform Integrated Change Control: Inputs


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.

 

 

 

6th Edition PMBOK® Guide–Process 4.5 Monitor and Control Project Work: Outputs


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.

 

 

6th Edition PMBOK® Guide–Process 4.5 Monitor and Control Project Work: Tools & Techniques


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…

6th Edition PMBOK® Guide–Process 4.5 Monitor and Control Project Work: Inputs


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.

 

 

 

 

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


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.

Tacit vs. Explicit Knowledge and the PMP exam


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.