Search This Blog

22 November 2018

Difference between Change Control and Configuration Management

Project Management Professional (PMP) students often confuse Integrated Change Control (ICC) and Configuration Management (CM). To put this very simply, ICC controls change whereas CM controls the records of all approved work.

Configuration Management


There are two types of changes. One moves forward whereas the other move backward or sideways. (The are not PMI terms. I use them just to help you picture the differences.)

Forward change is normal work as it happens according to plan. You submit the Project Management Plan and ongoing work to CM when they are done and approved by reviewers. The main purpose of CM is to make sure everybody bases new work on the latest, approved plans and work.

CM also provides and controls the repository for work history, process assets, and lessons learned. Once work has been approved and entered into CM, it becomes subject to change control.

Integrated Change Control 


Backward changes revise work already done. Sideways work requires changing the Project Management Plan or design plans before moving forward. All changes to the plan or to previous work go through ICC. The ICC procedure ensures that you consider the alternative measures and the effects that a change can have. Passing the change through the ICC Board ensures that people with various perspectives can identify stakeholders and impacts you did not think of. This procedure enables making informed decisions.

The change request and the ICC Board's decision are stored by CM. If the change is approved, the change has to be implemented, and the records of the change (for example, approved, revised documents) are stored by CM. CM usually has responsibility for notifying the stakeholders in accordance with the communications plan.

Think of the ICC as the process for making sure changes to existing plans and work are done the right way. Think of CM as the library where all approved plans and work, including changes, are stored.

21 August 2018

The Plausibility Trap

Have you ever accepted a perfectly good explanation for an issue or solution to a problem and then learned later that it was wrong or less than best? You may have stepped in a Plausibility Trap.

You might be looking for the cause of a problem, the way to fix a problem, or an inconsistency that discredits a book. You find an explanation or solution and commit to it. Later, the solution does not fix the problem. Or somebody offers a different explanation that's infuriating because you cannot find any flaws with it and it makes your explanation sound stupid (even though you just know you're right). 

Plausibility Traps Everywhere

Root Cause Analysis helps overcome cognitive bias and plausibility traps by teaching you to look at different facets of a problem before making any decisions. We might want to blame the input to a process, but the environment, another input to the process, the purpose itself, a detailed step in the process, or even a recipient of the product might contribute to the problem. 

We get rushed, however. We fail to discipline ourselves, and seize upon the first solution we think of. We don't weigh possible causes against each other or look into the cause-behind-the cause. 

Tools for Avoiding the Traps

The most critical attribute in decision-making the ability to balance openness to more evidence and possibilities against the pressure to make the decision.

One solution is to use a graphical method such as mind-mapping or fishbone ("Ishikawa") diagrams. They force us to think about different types of influences, and then for each type, what secondary influences could go wrong. 

You can start with a standard list or create your own. For example, manufacturing has the Eight Ms:

  • Machine (Technology)
  • Material
  • Measurement (Inspection)
  • Management (Money power)
  • Maintenance
  • Mother nature (Environment)
  • Man power (Brain work)
  • Method (Process)

Business Management has PEST Analysis:

  • Political
  • Economic 
  • Social 
  • Technological

Each of category above has multiple sub-categories that are outside the scope of this article.

Another tool is the Five Whys. Get an answer to Why? and then ask Why? again. And again. And gain and again, until you arrive at a cause that is not under your control. "Five Whys" is the Americanized version of a Japanese expression, why-why. You go as far back as the first cause that is not under your control, and then respond to the first step that is under your control. 

The beauty of Five Whys is that things that go wrong tend to cause multiple problems. So if you prevent or mitigate that root cause, may you fix other problems you didn't eve know about.

Once you've identified several solutions (or causes, explanations, or steps), you may find that more than one are needed. Here's where you evaluate how likely each solution will help and how much it will help, and then choose not just one solution, but as many as it takes to address most of the challenge. Here, tools such as decision trees, the 80/20 rule, Pareto diagrams, and Tornado diagrams can be useful. 

Examples

Here are two examples from outside business where the people fall into plausibility traps. 

1. The news carries an account of a police officer shooting a suspect. One group leaps to the conclusion that the incident exemplified a racist America and incites people to riot. Later, it turns out that none of the objective facts supported the first group's conclusion. 

2. Somebody reads two accounts of an event or policy in a holy book and concludes that the differences prove the event never happened. Another person considers several ways the two accounts might be reconciled, and one of those ways rationalizes all discrepancies. The first person fell into the plausibility trap by accepting the first explanation that came to mind instead of searching for ways to merge the accounts. The second person realizes that, if the two accounts can be rationalized, then you cannot say they are untrue.

We don't want to fall into "analysis paralysis," but we don't want to fall into the trap of  simplistically accepting the first "plausible" explanation or solution, either. The more important the issue, the more facets and layers you should consider.


Copyright 2018 Richard Wheeler

20 August 2018

Difference between Iterative and Incremental Projects

Incremental and iterative are so close in meaning, a lot of people confuse incremental project life cycles with iterative project life cycles.

In general, iterations identify and build value, using progressive elaboration, in interdependent layers whereas each increment delivers independent value. Projects that iterate through phases of progressive elaboration are called Waterfall. Project that deliver value in increments are commonly called Agile.

The Project Management Institute, in the Guide to the Project Management Body of Knowledge, Sixth edition, has wisely taken to calling Agile methods adaptive. Agile is a philosophy whereas the methodologies have names such as Scrum.

Contrary to what Agile fanatics say...

Each has its place.

Have you ever watched a cooking competition? Suppose two chefs compete to invent a new recipe.

Iterative

Chef A decides to make a cake. The oven temperature is unreliable, so the selection of each component depends on how the last component turned out.

  1. Designs the cake's architecture.
  2. Chooses ingredients and makes the base layer. 
  3. Chooses ingredients and makes the top layer. 
  4. Chooses ingredients and adds filling on top of the base layer.
  5. Places the top layer onto the base layer.
  6. Chooses ingredients and applies the external frosting.
  7. Places the cake on the table before the judges.

Incremental

Chef B decides to make a fruit platter.

  1. Chooses to include cantaloupe and covers 1/4 of a platter with cantaloupe balls.
  2. Chooses to include grapes and covers 1/4 of the platter with grapes.
  3. Chooses to include apple slices and covers 1/4 of the platter with apple slices.
  4. Chooses to include oranges and covers 1/4 of the platter with orange sections.
  5. Places the platter on the table before the judges.
  6. Boast about how Agile is superior to Waterfall. 😈

The iterative method builds layer-by-layer, where the choice about the next step depends on the results of the previous step. In a hardware product development environment, you might develop a material, then a technology that uses the material, then a system that uses the technology, then manufacturing processes to affordably produce the material and system. No value can be produced until you've gone through all the phases.

The incremental method doesn't depend on sequence. Each fruit has value by itself. An example from software development might be adding Bold, Italic, Underline, and Crossout functions to a word processor. Each new function adds value even if the other three functions are not added.



Copyright 2018 Richard Wheeler

Project Manager and PMP Candidate Resources

I will add resources to this list as I come across them or as you identify them in your comments.  With my budget, the emphasis will be on free resources.

Webinars

Podcasts

  • Elise Stevens @ElisethePm
  • Lean Blog
  • People & Projects
  • Gemba Academy
  • Mastering Business Analysis
  • PM for the Masses
  • http://Manager-Tools.com

Sample Questions and Mock Exams

- Beware outdated content. Don't waste your time with any mock exam whose site does not clearly identify it as based on PMBOK 6.

PM Social Media Communities

- The lists below are in no particular order, and my listing of any group does not necessarily constitute a recommendation.
- Study tip: When studying sample questions posted online, look up the answers in the PMBOK and explain why the best answers are best and the other answers are less than best. Having to form complete thoughts helps you internalize the material and helps others learn, too.

LinkedIn
Google Plus
Facebook
- Requests for stolen IP are rampant in some of the Facebook groups. Please join me in discouraging it.
- Some sellers of test materials post the same sample questions in many PMP study groups, and their questions dominate the less-active groups; so many of the groups add little unique value.

Future Additions to This Page or New Pages

  • Business Analysis Resources
  • Continuous Improvement Resources

19 April 2018

Have Time-Scaled Logic Diagrams Replaced Gantt Charts?

I wondered what Time Scaled Logic Diagrams (TSLDs) were after seeing references to them in online PM discussions. One context was a mock exam question that should have mentioned Gantt charts and did not.

Then I recalled reading that PMI dropped Gantt charts from the PMBOK. That turns out to be fractionally true.

The PMBOK has added a mention of TSLDs in its discussion of project scheduling. However, the accompanying figure contains a picture of a Gantt chart. The text calls the Gantt chart a project scheduling linked bar chart diagram.

The rest of the details are in the following slides. (Click on the graphics to see a larger view.)