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




03 September 2017

Learning from Poor Writing

A wise person learns from others' mistakes. Any competent Business Analyst must master written communications. This flog post (flog + blog) presents lessons from unprofessional writing. I try not to pick on common people (e.g., Facebook posters). Instead, I focus on those who ought to know better: mainly, reporters and the news organizations that are too miserly to hire copy editors.

Bent-piped Gaffs

Reporters often accept news releases from companies or government agencies and then post them with minimal editing. That's probably what happened with this story. The text went in one end of the pipe and came out the other end, uncorrected. The quality doesn't speak well of the News Director who posted it under his name. He may be a great reporter or manager, but his proofreading is substandard, even by the news industry's rapidly deteriorating standards.

The USFS manager who probably provided the source text sits on the borderline of forgiveness. Managers reach their position because they can do one or two things well. One of two halo effects result. (a) Since they do something well, they think they can do all things well.  (b) Since they do something well, their managers expect them to do all things well (including writing) and withhold budget for hiring professional tech writers. Both situations can result in unprofessional writing. Most of the time, poor writing does not matter, but when the subject impacts profitability or safety, poor writing can cost jobs or even lives.

  • In the opening sentence, using the verb to be equates the fire with the area. That is a logical error. The fire covers 3,791 acres or has burned 3,791 acres, but we shouldn't say the fire is 3,791 acres.
  • You don't need to be a firefighter to know the difference between a [Name] Complex Fire and a fire complex. A wildfire complex forms when two or more fires merge. Complex may also be loosely applied to multiple wildfires close enough together to be treated as a single fire. 
    • In this case, two fires have merged, but the third remains separate, across the valley. Therefore, the Summit Complex Fire ought to be called Summit Complex Fires
    • The complex fire should simply be The complex. The complex of fires would be acceptable but wordy. 
  • Containment is not something you place on a fire. You don't have 9% containment on the fire, you have 9% containment of the fire. A better headline would state, Summit Complex Fires Containment at 9%.
  • 9% is a measurement. You don't spell out measurements.
  • Nine-percent should not be hyphenated. The focus of the sentence is on 9% (e.g., the containment has reached 9%). When the unit of measurement might otherwise require pluralizing, we hyphenate the number and the unit of measurement, and we keep the unit in the singular.
    • Example: The six-foot statue (not the six feet statue
    • Percent does not require pluralizing. For example, we would never say, nine percents.
  • In lightning caused incidents and heat related illness, the author commits the opposite error by failing to hyphenate. Where a pair of words form Correct: lightning-caused incidents and heat-related illness.
  • (Sarcasm Alert) I just love "The fire activity of the McCormick Fire has been especially active...." We wouldn't want to scare people by telling them that the McCormick Fire has been especially active. Let's tell them that the activity has been especially active. Great writing! 
  • Competing with the complex fire for best example of redundancy, we have dry fuel moistures. Low fuel moisture would be better. The technical people think in terms of the percentage moisture content in the materials that make up the fuels for wildfires. But a good writer would simply say dry fuels.
  • The problem with the final error lies in what it omits. Writing in passive voice commonly leads to ambiguity about who performs the action. 
    • A voluntary evacuation has been issued in conjunction with the Tuolumne County Sherriff's Office....
      • By the way, you don't issue an evacuation; you issue an evacuation notice or order.
      • And Sheriff has one 'r', not two.
      • The news release probably came from the US Forest Service spokesman, so I'll fill in the missing detail:
    • Corrected: The Forest Service, in conjunction with the Tuolumne County Sheriff's Office, has issued a voluntary evacuation notice....

Writing That Bites

The next grammatical atrocity has too many errors for a complete commentary. The points listed below will have to suffice.
Inattention to order of phrases
  • The past participle of bite is bitten. The woman bit the crew member. The crew member was bitten.
  • Grammatically, ...in Angels Camp that had wedged implies that Angels Camp did the wedging. 
  • The correct pronoun for a person is who, not that. That implies that the thing referred-to is not human.
  • Had wedged... and refused changes verb tenses in the middle of the sentence. Had wedged... and had refused adds parallelism.
  • The order of the phrases should reflect the importance of the information. The location should not interrupt the actions. A better version of the opening sentence would read,
    • An ambulance crew member was bitten while attempting to rescue a woman who refused police orders to come out after wedging herself between two boulders near Angels Creek in Angels Camp.
  • The sentence still uses a passive verb, which renders it boring. Splicing too much information into a single sentence makes it even worse. A best version would read,
    • A woman bit an ambulance crew member who was attempting to rescue her near Angels Creek in Angels Camp. She had refused police orders to come out after having wedged herself between two boulders.
  • The lack of a comma in referred to as the "Paradise" area for a female that... implies that the name refers to a woman. The resulting double entendre should bring a smile to dirty minds.  
  • The lack of a comma in a steep ravine who had lodged herself implies that the ravine is a person and that the ravine did the lodging. Again, the writer interrupts the action by inserting the location prematurely in the sentence. A better version of the sentence reads,
    • Once at the scene, they found a 21-year-old woman who had lodged herself in a crevasse between two large rocks near the creek at the bottom of a steep ravine about a half mile from the roadway.
The next sentence secured this article's place on my grammatical wall of shame.
  • Unable to sit still and while making animated, erratic movements, officers ordered....
Too much coffee, officers? 

The final paragraph opens with an equally awful (although not nearly as funny) mistake.
  • It took crews nearly two hours through heavy vegetation and rough terrain, to safely remove the women (sic) from the scene. First, vegetation and terrain are not units of time. Second, the writer blunders yet again by stating the location too early in the sentence. The corrected sentence reads as follows:
    • It took crews nearly two hours to safely remove the woman through heavy vegetation and rough terrain.
    • Notice that when the obstacles are correctly placed, it becomes clear that from the scene is redundant.

That's it for now. I'm happy with my vent. I hope you found this either amusing or edifying. If you see other examples of atrocious writing, feel free to leave a link in the comments, below.


More to come, later.

Copyright 2017 Richard Wheeler

20 June 2017

When Sales Promises Phantom Features

What should a Product Development or Project Manager do when Sales has sold the product with a feature that does not exist, Engineering does not plan to build it, and it is not in the SOW?

This is like bringing the boss home for dinner without telling your spouse.

In this case, the organization is broken. It is stovepiped, with Sales not considering other stakeholders within the organization.

Some would look at the Statement of Work (SOW) and draw a hard line, but that option often does not legally exist. The spoken word often binds the Seller.

My answer assumes traditional product development and project management. Agile developers have considerable flexibility with scope.

If you don't have a Change Management Process, create one. Your Product Roadmap, Project Management Plan, and product design may require significant rework that must be analyzed and documented. The presumptuous defenestration of all that planning incurs significant costs and delays because they have just altered your carefully optimized route.

Driving is a great metaphor, here. You invested significant creativity and expense in planning to add features and develop your market in a logical order. Now, you have to spend more budget and time on planning a new route that may take longer to get to the destination.

As a starting point for accountability, require Sales to submit a Change Request form that requires documenting the business case, costs, funding sources, risks, schedule impact, and technical impact and feasibility. This requires business analysis and coordinating efforts of many stakeholders such as the buyer, users, Product Development, Engineering, Production, Deployment, Scheduling, Contracts, Finance, Quality, and suppliers (through Purchasing). The change may be a "done deal," but Sales needs to stand before a Change Control Board (CCB) and gain an understanding of the consequences of their actions. When the borrowed experts from Engineering start charging against Sales' budget, even their managers will get the message.

Fulfilling the changes will require a combination of creative options.

  • Most people will compromise rather than spoil their relationship with your company by taking advantage of a loose-lipped salesman; so you may be able to negotiate a change to the contract based on re-prioritizing client needs.
  • Since the change may have value to other customers, management might accelerate investment in product development funding.
  • Consider dipping into Management Reserves and profits.
  • Bring in a Lean/Six Sigma team to find cost and schedule savings. (After that, have them help fix those stovepiped processes.)
  • If the Product Roadmap includes features not delivered to this customer, delay their development.
  • Look for features planned for the product but not promised to the Customer. They may be removed.
  • Sometimes, the penalties for breaking a contract cost less than fulfilling it. This is your worst option, but it is a valid option.

A well thought-out Change Request Form anticipates the areas that require investigation when instigating change. A well-designed Change Control process not only provides opportunity for characterizing changes, but also for creative thinking about the solutions to sticky problems. 

Copyright 2017 Richard Wheeler