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.

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

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

• Peter DeJager and Technobility offers live webinars and a library of dozens (free, but donation requested)
• ITMPI offers several webinars per month. The webinars present high quality materials and are free, but they charge for the PDU codes unless you join. They also have a library with hundreds of recorded webinars for a fee.
• The Human Capital Institute 
• http://Reflektive.com 
• http://ModernAnalyst.com 
• http://ProjectTimes.com 
• http://ProjectManagement.com/ is associated with PMI.

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.

• Edward Designer's list of free mock exams
• Oliver Lehmann's list of thousands of free mock exam questions -- Scroll to the table at the bottom 
• 100 Online Questions from Oliver Lehmann -- Scroll to the bottom for a table listing thousands of free questions -- Some links may have outdated questions.
• 200 Offline Questions from Oliver Lehmann -- PDF
• Free PMP® Exam Simulator -- Cornelius Fitchner's free 200-question simulator, 7-day access
• PM Aspire PMP Simulator -- 2 free simulated exams X 200 practice questions, 5-day access; Singapore-based, so the English might not be the best

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

• The Project Manager Network -- 867,000 members; managed by Recruiter.com
• Project Manager Project Manager Community -- 366,000 members
• PMI Project, Program and Portfolio Management -- PMI's official LinkedIn group
• Project Management Professionals PMP
• Project Management Link - PMLink
• PRINCE2 & MSP - Project & Programme Management + Agile Scrum
• Project Management Group SP -- What does the SP stand for?)
• Construction Project Management 
• PM Community - Product/Portfolio/Program/Project Manager

Google Plus

• Project Management, PMI, PMP Certification -- The most active PM community
• Project Management Community -- Less active, but great posts
• Sensible Project Manager Hangout -- Discussions, with recordings available
• Project Management Masters -- Great posts, strict moderation

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.

• Professional Project Managers -- Joseph Phillips' group; Phillips has an exellent, low-cost exam prep course on Udemy.com 
• Project Management Café -- Elizabeth Harrin's group (author of Girl's Guide to PM)
• PMP Study Group - with Expert Professionals -- less than 1,000 members, but lots of mock exam questions and no spam
• PMP Tricks -- Based in Saudi Arabia; mixture of languages; 6,200 members
• Pmp Exam Preparation -- over 7,000 members, mostly exam questions
• PMP Study Group 
• Project Manager
• Project Management Professional (PMP) Study Group
• The Project Management PrepCast -- Cornelius Fitchner's promotional page offers occasional free content
• I want to be a PMP® - (PMI Project Management Professional Certification )
• Project Management -- Not sure this group is legit
• Free Project Management Books and Knowledge, Prince2 and PMP Exam Guidance -- Despite the title, I haven't actually seen much IP theft in this group
• Construction Project Management & Contracts Books 
• PMI - Project Management Professional PMP -- Does not appear to be PMI's page
• Project Management
• PMI / PMP Project Management Focus Group 
• Project Management Professional (PMP) -- Admin'd by Maples Project Management
• Project Management Library 
• PMP - A Project Manager's First Step -- 17,000 members
• Project Management Professional PMP study group- Progress PM -- 10,000 members
• PMP Egypt - Project Management Professionals in Egypt 
• Oil & Gas Project Management Group 
• Jobs for Project Managers: Career and Job Forum 
• Project Management and PMO: Courses, Training and Mentoring -- The blog of the Sheldon Institute of Project Management
• Professional Project Management -- 3,700 members
• Construction Project Management -- Based in Iraq; 12,000 members
• Your Dream Project Manager Job - Career Coaching For Professionals -- Sage words from Luis Peluffo
• Project Management Lets Share Tools and Ideas 
• Online Hub for Virtual Assistants & Project Managers 
• How to pass PMP exam? 
• PMP Exam Study Group 

Future Additions to This Page or New Pages

• Business Analysis Resources
• Continuous Improvement Resources

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

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.

• 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

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

Elevator Pitches: Tell Me A Little About Yourself

You Need an Elevator Pitch

When prospecting for jobs, I used to have two panic situations.

• You meet somebody, you ask them some questions to establish a bit of a relationship and to choose whether to put more time into the conversation. You learn that this person could be a lead to a job. Suddenly, you realize that it’s your turn to introduce yourself. What do you say?
  
  
• A hiring manager invites you to take a seat and begins the interview. “So, tell me a little about yourself.” What do you say?

As you can see, you need more than a good resume and a good cover letter.

The Elevator Pitch is the introduction you would give during an elevator ride. At the end of the ride, either you will watch the doors close as the listener walks away, or you will walk away with the listener because he or she wants to hear more.

You’ve got 30 seconds, and what you say will not only show whether you can solve the manager’s problem, it will also tell the manager whether, in your current occupation (Job Hunter), you are a diligent worker. The pressure is on!

Create Your Elevator Pitch

The Web has thousands of formulas for elevator pitches. I’ll give you the best formula I’ve seen, to get you started.

1. (Introduce yourself. By this point, you should already have introduced yourself. If you haven’t, do so now. Optionally, you can add something about yourself that sets up the next part.)
   
   Example: My name is Remy Therat (and some day, I’m going to own my own restaurant).
   
   
2. Get their attention. Not your attention. Theirs. What do they care about? What challenges do they face? Stories get a person’s attention. A story about me -- or about the problems I face -- gets my attention.
   
   Example:  The last place I ate, the server’s expression made me feel guilty for having to ask for a fork three times, and the cooks couldn’t even bother with centering the burger on the bun.
   
   
3. Tell them how you solve their problem. Remember, this is about their challenges, not about what you want. When you become the hiring manager, you can talk all you want about what you want. But for now, the hiring manager and his or her problems are the center of your universe.
   
   Example:  As an assistant manager, I always started the day with a huddle to get the staff to think about how we can make diners feel comfortable and important.
   
   
4. Call to action! You want them to help you, but you don’t want to put them on the spot. Asking directly for a job puts them on the spot, so be indirect. “Who* do you know that...” asks them to think of a specific answer that moves you closer to finding an employer, and if you’ve already found the right person, he or she will answer, “Me!”
   
   Example:  Who do you know who could use a caring, ambitious worker on their staff to increase customer loyalty and staff retention?
   Notice that the question reinforced the message of how Remy would be a great employee and how he would be good for the business.
   
   * The correct word is whom. In my line of work, I have to be a bit of a grammar cop, so I would use whom. However, if it would make you sound stuffy and unnatural in your line of work, who will do just fine. 

Let’s see how that flows:

• My name is Remy Therat (and someday, I’m going to own my own restaurant). The last place I ate, the server’s expression made me feel guilty for having to ask for a fork three times, and the cooks couldn’t even bother with centering the burger on the bun. As an assistant manager, I always started the day with a huddle to get the staff to think about how we could make diners feel comfortable and important. Who do you know who could use a caring, ambitious worker on their staff to increase customer loyalty and staff retention?  

Prepare Your Pitch, but Be Spontaneous

Here’s the catch: You want this to come from within. You don’t want to sound like you’re reading off a 3x5 card. Besides, no Elevator Pitch will fit every situation.

If somebody asks about the weather forecast, do you repeat what KCRA’s meteorologist said, word-for-word? Of course not.

You now know the three main parts of your Elevator Pitch:

1. What are their challenges?
   
2. How can you solve their challenges?
   
3. “Who do you know that could use (description of yourself) to (how you’d be good for the business)?”

You know your skills, your knowledge, your behaviors, your history. You are the expert on You, so you can be flexible.

Write out several possible answers for each of the pieces above. Think of how you would word the pieces for different types of jobs.

Then rehearse them. (Boring repetition and breaking things into pieces are the keys to memorizing.)

Imagine that you meet the hiring manager for one job and decide what the best pitch would be for her. Then imagine that you meet a manager for another job you could do, and decide what the best pitch would be for him.

A mechanic doesn’t use one tool for every job, he carries a whole toolkit. Be prepared, and you'll be able to be flexible and natural.


Copyright 2016, Rich Wheeler

Corrections to LinkedIn's Course, Business Analysis Fundamentals

LinkedIn's inLearning course (apparently they got it from Linda.com), Business Analysis Fundamentals, provides plenty of useable information. However, I was frustrated with a number of points. The most damaging were the course's confusion about Validation, Verification, Traceability, and Stakeholders.

• You validate requirements by confirming that they have authority, are necessary, and meet standards for quality. Validation looks upward.
  
  
• You verify that requirements are met either by lower-level requirements or by the product. Verification looks downward. Methods include Inspection, Analysis, Test, and Demonstration.
  
  
• The course reversed these distinctions and identified only Test as a method of verification.
  
  
• Traceability links each requirement to directly-related higher- and lower-level requirements. Traceability enables validating requirements' authority and verifying their satisfaction.
  
  
• The course's discussion of traceability focused on metadata about requirements' sources. While such information is useful, it is a very minor part of traceability.
  
  
• Stakeholders include everybody who "has a stake in" the project.  The course focused on external stakeholders. It should have included the project team and other internal relationships such as other projects.
  
  
• The course's definition of Functional Requirements includes activities that the project needs to do to deliver the product. It should also have included what the product does and how well it does it.
  
  
• Since the course only half understands what constitutes functional requirements, it classifies Performance among nonfunctional requirements. Project performance is nonfunctional, but product performance is functional.
  
  
• The course treats Transitional Requirements as a separate category. If the project performs a service, transitional requirements can be Functional requirements; and if the project creates a product, they are usually nonfunctional.
  
  
• The T in SMART stands for Time-bound. The course replaces this with Traceable. The substitution is a good one, but it is nonstandard, and it requires that you include temporal requirements in Specific.

As I said, the course provided plenty of actionable content. I would be proud to work with the instructor, and I would learn a lot more from him that he would learn from me. However, we'd have to work out some issues, first.

Steps to Avoid Becoming Another Samsung

"What should I focus on or watch out for in order to prevent a calamity from happening to my business?"

Asked at http://www.mosaichub.com/answers/question/what-should-i-focus-on-or-watch-out-for-in-order-t#57652

Study Risk Management

• I strongly suggest studying the Risk Management sections of Project Management Institute's (PMI's) Project Management Body of Knowledge Guide Guide (PMBOK). Add to that the corresponding chapter of a PMI-PMP (Project Management Professional) exam study guide such as the one by Rita Mulcahey.
• If your organization can bear the cost, consider hiring an employee or consultant with a strong background in risk management to help establish a risk management program or to review the program you establish.
• One such expert is Glen Alleman. I recommend the materials on his blog, Herding Cats.

Systematically Define Your Business and Identify Potential Risks

• In general, you need to systematically define and examine every facet of your business, processes, products, services, and business environment. (The whole of the PMBOK Guide will help you classify those areas for projects.) As you examine each facet, you compile a list of risks. Clarification: I'm not saying you have to do it all at once.

Evaluate Risks

• To evaluate the identified risks, you make a subjective, rough estimate of their effect and probability.
  
  Risk = Impact x Probability
  
  You then accept the low-risk items or place them on a watch list and make a more objective evaluation of high and medium risks.

Aleatory and Epistemic Risk

• One of the characteristics of risk that you need to consider is what you know about the risk. Epistemic risks can be reduced by learning more about them. Aleatory risks cannot be reduced because there's a random element. For example, knowing how many sides dice have lets you know the possible range of values, and testing them can tell you whether loading or poor workmanship make some results more likely. On the other hand, after that, you cannot reduce randomness. This is part of the information you use when evaluating strategies for managing the risks.

Identify Candidate Responses

• Identify possible responses (accept the risk, sidestep the risk (e.g., plan your road around the mountain instead of tunneling through it), reduce the effects, take steps to reduce the probability, transfer the risk to somebody else (outsourcing or insurance), or wait and see.

Evaluate, Select, and Implement Responses

• Evaluate and select responses based on their cost and probability of success. Note that risk responses become policies, changes to processes, or new requirements. 

Monitor Responses and Watch List

• Set up a risk monitoring system that tracks risks in the watch list as well as implementation of responses. This feeds into controlling performance and also into Lessons Learned (you have a Lessons Learned archive, don't you?) that save you work in the future.

Iterate and Integrate

• Risk identification is iterative because risk responses can create secondary risks, because everything eventually changes, and because . Many companies miss new risks because they perform risk identification and planning and never re-visit the subject.
• Many organizations delegate responses and leave them isolated from the . However, except for responses that are experimental (e.g., try it on a limited scale before rolling it out to the entire organization), they must be integrated into the business, project, product, etc.
• Like process improvement, risk management (RM) needs to be part of a company's culture. Some say that RM should dominate status meetings because it is more proactive and more actionable, and also because "status" is actually a facet of risk.

Copyright 2016, Richard Wheeler

Steps to Avoid Becoming Another Samsung

"What should I focus on or watch out for in order to prevent a calamity from happening to my business?"

Asked at http://www.mosaichub.com/answers/question/what-should-i-focus-on-or-watch-out-for-in-order-t#57652

Study Risk Management

• I strongly suggest studying the Risk Management sections of Project Management Institute's (PMI's) Project Management Body of Knowledge Guide Guide (PMBOK). Add to that the corresponding chapter of a PMI-PMP (Project Management Professional) exam study guide such as the one by Rita Mulcahey.
• If your organization can bear the cost, consider hiring an employee or consultant with a strong background in risk management to help establish a risk management program or to review the program you establish.
• One such expert is Glen Alleman. I recommend the materials on his blog, Herding Cats.

Systematically Define Your Business and Identify Potential Risks

• In general, you need to systematically define and examine every facet of your business, processes, products, services, and business environment. (The whole of the PMBOK Guide will help you classify those areas for projects.) As you examine each facet, you compile a list of risks. Clarification: I'm not saying you have to do it all at once.

Evaluate Risks

• To evaluate the identified risks, you make a subjective, rough estimate of their effect and probability.
  
  Risk = Impact x Probability
  
  You then accept the low-risk items or place them on a watch list and make a more objective evaluation of high and medium risks.

Aleatory and Epistemic Risk

• One of the characteristics of risk that you need to consider is what you know about the risk. Epistemic risks can be reduced by learning more about them. Aleatory risks cannot be reduced because there's a random element. For example, knowing how many sides dice have lets you know the possible range of values, and testing them can tell you whether loading or poor workmanship make some results more likely. On the other hand, after that, you cannot reduce randomness. This is part of the information you use when evaluating strategies for managing the risks.

Identify Candidate Responses

• Identify possible responses (accept the risk, sidestep the risk (e.g., plan your road around the mountain instead of tunneling through it), reduce the effects, take steps to reduce the probability, transfer the risk to somebody else (outsourcing or insurance), or wait and see.

Evaluate, Select, and Implement Responses

• Evaluate and select responses based on their cost and probability of success. Note that risk responses become policies, changes to processes, or new requirements. 

Monitor Responses and Watch List

• Set up a risk monitoring system that tracks risks in the watch list as well as implementation of responses. This feeds into controlling performance and also into Lessons Learned (you have a Lessons Learned archive, don't you?) that save you work in the future.

Iterate and Integrate

• Risk identification is iterative because risk responses can create secondary risks, because everything eventually changes, and because . Many companies miss new risks because they perform risk identification and planning and never re-visit the subject.
• Many organizations delegate responses and leave them isolated from the . However, except for responses that are experimental (e.g., try it on a limited scale before rolling it out to the entire organization), they must be integrated into the business, project, product, etc.
• Like process improvement, risk management (RM) needs to be part of a company's culture. Some say that RM should dominate status meetings because it is more proactive and more actionable, and also because "status" is actually a facet of risk.

Copyright 2016, Richard Wheeler

Managing an Aggressive, Disrespectful Employee

Question from Quora.com about a situation every manager eventually faces:

How can I be a strong leader of a company?

I’m the managing director of a company in a national competition. I appointed ‘Billy’, as we’ll call him, as deputy managing director. However he’s trying to take charge and criticising me as a public speaker, which I am actually very good at. How can I be strong and prove that I’m in charge?

Manage or Lead?

Mr. Asker is right to focus on leadership. A good manager guides the business whereas a good leader guides people. Success comes when you do both. 

One responder correctly stated that firing "Billy" is an option. However, since Mr. Asker saw value and ability in Billy, it’s probably better to help him grow, so firing him would be the last option. A manager would fire Billy first; a leader would fire him last. 

That having been said, let's consider some options. Everybody has a unique personality, motivations, and needs, so we no single response fits everybody. However, we can identify some common, general methods. 

Rise above the challenge

Mr. Asker should not focus on proving anything, although, after settling the problem, he may need to take steps to restore his stakeholders’ confidence in him. The following excellent advice is offered by Kim Bunting:

Prove that you’re in charge by taking charge.  The first thing about being in charge is to not get caught up in the emotion of the situation.

Criticism is only as impactful as you let it become.  Make sure you hear what he’s saying and look (without emotion) at it to make sure it isn’t feedback that might help you improve your already good presentation skills.  If it’s not, say “thanks for the feedback” and keep going.  If it is, work on changing.  A leader takes feedback and isn’t injured by people offering it.

If he’s trying to take charge of things you are doing, say “thanks for the help, I’ve got this” and move on.  Assign him something else to focus on, such as saying “rather than both of us spending time on this task I’m doing, we can get more done if you get the spreadsheet finished. Let me know when you’re done.” (or whatever)

The most powerful thing you can do to someone who is trying to upstage you or discredit your authority is to NOT react to them as if your authority could be taken away.

Confront the challenge

Containing the situation limits the damage to your reputation, to company morale, to business, and to Billy’s reputation, too. Jesus stated a rule about escalating an issue (Matthew 18:15-17). You start one-on-one, then bring in witnesses if you must, and then bring in the broadest authority; sanctions are the last resort. Some companies have Human Resources professionals who specialize in managing interpersonal conflicts, so involving them may be one of the routes for escalation.  Needless to say, the best option benefits everybody.

I recommend a two-pronged approach. One step is urgent while the other is important.

Feedback is urgent.

Billy needs immediate, private feedback. I suggest using the feedback model taught at Manager-Tools.com. (You can join to access their content or you can search their website or the iTunes store for their free podcasts on the feedback model.) The script goes something like this, and it should only take a minute or two:

1. Describe what Billy did. Focus strictly on one event, not on personalities or general behaviors.
2. Explain the result of what Billy did. Remember, this is about what’s good for the business. It’s not about judging Billy or defending yourself. However, you can describe the perceptions that his behavior causes and the feelings it triggers as they impact business. 
3. Explain your standards for profitable business behavior.
4. Ask Billy whether he can support those standards, and ask him what he will do to meet those standards. 
5. Thank Billy for his time and for the improvements you expect to see.
6. Move on. Don’t mention it again unless another feedback session is needed. 

Notice two things about the model: First, the model identifies the problem and its costs and then conveys a vision, a to condition, before seeking change. 

Second, if Billy agrees to take steps to correct his behavior, Mr. Asker now has a standard against which to hold him accountable. If Mr. Asker keeps thorough records, he now has a basis for future actions such as rewards for improvement, withholding rewards for failing to improve, or sanctions such as demotion or termination.

Treating the cause is vital.

Feedback is urgent, but identifying the root cause is important. Knowing root causes enables making a plan for how to will deal with the problem, just like a manager would make a plan for dealing with any other business problem. 

Toward that end, Mr. Asker should work on his relationship with Billy. He could take him to lunch. He could establish weekly one-on-ones (learn about those in the Manager-Tools podcasts, too). Determining what drives Billy him and his goals will help determine how to direct his energies and help him grow as a human being.

Manager-Tools’ also has a coaching model. Mr. Asker can also help Billy by assigning research or reading that would help correct his behaviors. Sometimes a bad behavior expresses some other frustration. Dealing with the root cause may mean helping Billy learn some technical skill rather than teaching him the social skill.

Leaders are learners. They prepare by collecting tools for dealing with issues and problems and by investigating to learn the root causes. Their plans for how to deal with issues may include a variety of approaches, and they may change approaches. Finally, the leader works for the benefit of everyone, including the offende

Copyright 2016, Richard Wheeler

When the Customer Holds You to the Rough Estimate

How can a project manager prevent rough estimates from becoming fixed project boundaries?

The answer depends partly on who sets the boundaries. Let's assume that both your company's management and an external customer are involved.

Understand the Estimate

For the purpose of explanation, let's assume that a rough estimate's required accuracy is +/- 50%. If we spell out the estimate, "The most likely cost, time, or availability of resources is X, the optimistic is X/2, and the pessimistic is 1.5X." 

If management approves that estimate, it implies that the company accepts three stipulations: 

• The project will be judged "successful" if the time or cost at completion is between 0.5X and 1.5X. 
• The company is ready to fund a cost of 1.5X. 
• The company schedules resources to be available when the project requires them. 

In summary, your budget is not X, but 1.5X.

Understand the Risks

When the company insists on running with the rough estimate, it creates several risks: 

• If the cost at completion turns out to be 0.5X, the the fees and interest on borrowing (1.5-0.5)X will have been wasted. 
• Your company will lose other business for which it could have used the funding and reserved resources ("opportunity cost"). 
• Since a rough estimate does not include a deep consideration of risks, risks exist that you would only discover through the processes associated with performing a more accurate estimate. 
• The high cost estimate (1.5X) creates a risk that the customer will go to another company that offers a more mature estimate.

Educate Stakeholders and Enforce Definitions

An explanation of the risks and responsibilities of using the rough estimate should convince your customer to allow a more accurate estimate. If you insist on the stipulations above and everybody accepts the risks and responsibilities, you should be able to live with the situation. 

Remember that, as you progressively elaborate your project plan, you will derive more accurate estimates anyway, and you will keep your stakeholders informed about your progress, allowing them to adjust affected plans.

Copyright 2016, Richard Wheeler

Name Your Files for the Readers — If You Care

Filenames — A Trivial Time-waster that Adds Up

How do you react when you see a filename like 500002p.pdf? 

Is this a file that you want to open? 

Do you think that the author of the file cares whether you open it? 

This one's a little better, but not much:  BBP3.0FactSheetFINAL.pdf.

What Do You Want to Know?

When I look at a filename, the first thing I want to know is what it is. After that, I want version information. 

Some people put their initials first.  In a team folder, the listing will group the Jim files, then the Joe files, then the John files, and so on.  (And then there's Jack who sometimes uses JB and sometimes JEB.)

Then you have to search up and down the screen to find all the versions of the same file.  The larger the team and the longer the project goes on, the more this wastes time and leads to mistakenly working with outdated versions.

A government website has a folder of presentation files in this format:  

2014_05_15-Draper-6th-AGNC-Welby-final.pdf

Placing the date first is redundant because you could always sort by date in the file explorer view.  Apparently, the Welby made the presentation and worked for Draper, and the topic was some cryptic initialism.  Now, how are we supposed to find presentations on risk management among 74 files with names like that?  Do you have an hour to spend opening all those files?  

There's another human element. When a filename starts with initials or has a serial number instead of a name, my eye says, "random, meaningless letters." Then my amygdala says, "look away!" 

Sometimes my amygdala wins, and sometimes my cerebral cortex wins. That contest creates stress. wastes time, and sometimes blocks communication completely. 

If you have a Content Management System (CMS) or Configuration Management System (also CMS) such as SharePoint, you have ways around this.  You can add fields for author, date, version, and subject.  

Often, however, we are stuck with filenames.  Even if your team has a CMS, you will still sometimes wish to download a file to your own drive.  If you don't remember what's in that cryptically named file three months from now, will you even bother to open it?

Since I read from left to right, and since an alphabetical sort proceeds from left to right, I recommend the following name format:

topic - [rev or yyyy-mm-dd [24-hour time if needed] ] - initials

example

meeting notes, team, 2015-08-01, rev A, rw.docx

Filenames should be in plain English. 

When I download files, I hate seeing files with names like BB097834.pdf.  I should not have to download and open a file in order to determine whether I want to download and open it. 

And by the way, who is JS, and does he or she even work here any more?  Does it feel professionalI to use your initials?  How professional will it seem to others, two years after you've taken that big promotion at another company and nobody here remembers whom JS was? Spell things out.

Some content management systems assign garbage names automatically.  We cannot do anything about that.  And some authors write only for their own vanity.  They do not care whether anybody reads what they wrote.  Try not to obsess over it; I've already done that for you.

A filename is like a headline or the title of an opus.  

A good author or editor knows that Job One is attracting an audience and, therefore, puts a lot of effort into creating a meaningful, eye-catching filename. Which would the classical music lover in your life rather listen to?

• PITop066.mp3

or

• Sleeping Beauty, Peter Ilyich Tchaikovsky, opus 66.mp3

It's about more than efficiency. It's about consideration.

Copyright 2015 Richard Wheeler

Lines of Communications

I created this figure for a survey about the routes of information needs within an engineering group.

Blogspot is not making this easy. 

You may have to right-click on the figure and save the file to your desktop to view it properly. 

Two Steps toward Making Stakeholder Management Manageable

Two Steps toward Making Stakeholder Management Manageable

The materials I've found about Stakeholder Analysis have not explained much more than the PMBOK Guide explains. What grids other than the Power/Interest grid tell me remains a mystery.

However, I have found two hints that simplify the whole Stakeholder Identification (and Analysis) process.

Divide Stakeholder Analysis 

PMBOK 4 describes Stakeholder Analysis as a single Tool/Technique. I would split off the elicitation of information as a separate technique and call it Stakeholder Survey.

Use a form as you visit around the office eliciting detailed stakeholder information. Transfer that information to the Stakeholder Register at the end of the day. If you put the register on a server and can access it register through Wi-Fi, you can save on data entry time.

Fill in what you can before bothering stakeholders. Then verify that information and elicit the rest, as much as you can, face-to-face. For what remains, you can use a questionnaire.

Simplify through Progressive Elaboration 

Consider an analog in Risk Management: First, you use Qualitative Analysis to identify the key risks. Then you use Quantitative methods to analyze only the key risks.

Now, take these lessons from that model:

• You don't need to perform full analyses for all stakeholders.
• You need only a small subset of the information to start.
• Decide what information you need in order to identify Key Stakeholders.
• Use the Power/Interest grid to identify Key Stakeholders.
• Collect further information and perform further analysis only on the Key Stakeholders.

Increase the degree of Stakeholder Analysis through progressive elaboration.

1. First iteration: Key Stakeholders
2. High Power/Low Interest stakeholders
3. High Interest/Low Power stakeholders
4. Low Interest/Low Power stakeholders

Remember, subsequent iterations should require less information and analysis.

This may be as much a delaying tactic as a simplification, which is what I really wanted. However, reducing, breaking up, and delaying the work relieves some of the stress of a potentially overwhelming process.

3 Factors in Risk Management: Probability, Impact, and Velocity

Risk Score

Qualitative and Quantitative Analyses in Project Risk Management both take into account Probability (P) and Impact (I). A Risk Score is the product of the two.
Qualitative Analyses use subjective estimates of probability and impact as a screening process that categorizes risks for management, monitoring, or ignoring. Risks placed in the management category go on to Quantitative Analysis and Risk Response Planning.

What about Urgency?

A third value should be considered: Velocity (V), which is the inverse of the time-to-impact.
Seldom can we deal with all risks at once. The value of considering Velocity lies in prioritizing further effort so you have enough time to respond to urgent risks. We would not consider Velocity when assigning risks to the three categories because we want to deal with the important things, not the urgent things. (Consider Pareto's 80/20 rule.)
If Probability times Impact describes an area, then to be consistent, we would add Velocity as a third dimension. That is,
Priority Score = Priority x Impact x Velocity

Another View of the Priority Score

Priority times Impact has another label, which is Expected Monetary Value (EMV). EMV is often used by itself for guiding decisions. If we express the Priority Score as
Priority Score = EMV x Velocity
then we give EMV a weight equal to the weight of Velocity.
The reason we would not consider the Velocity by itself goes back to the principle about the cost of rework. The later you deal with a problem, the more it costs because you have to repeat and fix work that came before. The previous effort becomes wasted, costs rise, schedule lags, and you have to use extra resources to get back on schedule.
Similarly, the longer you wait to deal with a risk, the more rework you have to do. Therefore, we need to factor both Velocity and EMV into prioritizing work: Velocity to deal with urgent risks, and EMV to control costs.

A New Step: Priority Analysis (when needed)

I recommend inserting a new step into Risk Management when there are risks with high velocity and you have to prioritize which risks to deal with first:

1. Qualitative Analysis with Risk Score = estimated Priority x estimated Impact
2. Priority Analysis with Priority Score = EMV x Velocity = Priority x Impact x Velocity
3. Quantitative Analysis with Risk Score plus other factors such as Velocity and Cost Effectiveness

I bring up Cost Effectiveness because you want to ensure that you don't spend $150 to prevent a risk whose EMV is only $100.

Reference

Hall, Harry, PMP, PMI-RMP. 30 Quick Risk Evaluation Tips. PM South. http://www.pmsouth.com/2015/07/18/30-tips/. Accessed 21 July 2015.

The Black Hole of the Agile World: Systems Thinking

Agile fanatics (excuse me: practitioners) love to do things in tiny increments.

That's OK for products where bite-sized deliveries have value, but it's fantasyland for many real-world projects.

Take, for example, the design of a new car. Sure, you can break the car into systems -- chassis, body, safety package, motor, and so on. Waterfall does that, too, but let's consider the airflow over the body. The airflow is affected by the whole assembly. Every part affects the whole. You can't just design a fender in isolation and say, "Looky, looky, I've delivered value!" No, you've delivered an irrelevant piece of scrap.

In any course on Business Analysis, the importance of a unit on Systems Thinking cannot be overemphasized because the Agile world has completely forgotten its value. 

Before the 1990's, there was a role called Systems Engineer.

That title is still around, but the job is not. At least, the job has become a rare grain of wheat a vast field of tares.

A Systems Engineer had many skills of a project manager, a BA, a Systems Thinker, and a cross-disciplinary engineer, all rolled into one.

Along come companies such as Microsoft and Cisco, dropping the qualifying word from titles such as Network Systems Engineer, Software Systems Engineer, and Server Systems Engineer. Suddenly, every engineer, analyst, and administrator is a Systems Engineer. I wish I had a paycheck for every time a recruiter has contacted me with a so-called Systems Engineer job that turned out to be for an IT admin or a software coder.

True Systems Engineering jobs have become needles in a field of haystacks, and systems thinking has almost been forgotten.

Thousands of Systems Engineers lost their jobs due to decimation of the US Defense sector in 2009. (I proud of myself for not pointing out the predictable political element of that.) They still find three strikes against them:

1. Transitioning to a different job category such as Project Management or Business Analysis
2. Getting a foot in the door of a different industry (other than fast food)
3. Living in a job market where all the growth is in part-time service jobs and has gone to low-skilled workers

Hiring managers would do well to consider bringing in experienced cross-disciplinary, systems thinkers. It would not take much training to bring them up to speed in new roles such as PM or BA.

Have you ever thought of a project as a system of people, or a product as a system of technologies? Systems Engineers do that instinctively, and such integrated systems thinking could prevent a lot of headaches for maturing companies.

Now, if you'll pardon me; I need to clean up a spill in aisle five.

Models versus Prototypes

What is the difference between models and prototypes?

Some people are confusing prototypes with models. Most of the examples given in other comments are engineering models (and they are valuable). A prototype is one type of model.

1. Before prototypes, you have engineering models. For example, a wireframe diagram just sits there. It's not a prototype, but it's still valuable. On the other hand, you might have a program with a generic GUI. It might be fully functional, but without the semi-final GUI, it's still not a prototype.

2. A prototype is the first (proto-) thing of its class (-type). Prototypes would include the Beta version of a software product or a widget built in a shop.

3. After the prototype, you have the production model. That's the model you sell in the store, the one you send out samples of, or the one that comes off the assembly line.

Off my soapbox and on to the questions:

1) Does prototyping have to be studied by external institution?

That depends on the product. Suppose you work in IT and designed a SharePoint site for the Engineering department. You will want Engineering to see models and then the prototype in order to identify the refinements that will take your product from "Gets the job done" to "Delights the customer." If your customers are other companies: Yes, you want it to be reviewed by them. And if you are subject to regulation by government agencies and licensing authorities, it's far less expensive to get their approval early than to get it later.

2) What information can we get from prototyping? Does the information we get show us the quality or preference or anything else?

Quality means, "how well the product meets the needs." If showing the prototype to the customer helps ensure that it meets the customer's needs and preferences, then the feedback helps to ensure quality.

For example, before converting Office from drop-down menus to ribbon bars, Microsoft probably let hundreds of users play with it. They would have found out preferences for how many icons to fit in a frame, which functions to place in the ribbon, which functions that were now hidden people would have to go hunting for, and how much they'd have to spend on marketing to convince people to accept the transition.

From a systems perspective, when Microsoft converted Office from the old file types (.doc, .xls, .ppt) to the new formats (.docx, .xlsx, .pptx), they used prototypes to investigate compatibility between programs.

 

For example, could you still import a section of an Excel spreadsheet into PowerPoint? Could you still save a Word document to Open Document Format or RTF files? Will Word and Excel compete for the same memory space and slow down or even crash the computer? Will the new version of MS Access have a reduced startup time?

 

Even after that, Microsoft still puts Beta versions in the hands of thousands of users to find the problems nobody thought to test for.

 

You can't answer such questions with confidence until you build working prototypes to test and experiment with.

Differences between Risks and Issues, Part 2

Differences between Risks and Issues, Part 2

Threats; and Another Side of Risk

 

Part 1 (click here) of this series defined issue.

Threat versus Risk

If a situation, such as a cause and its effect, is certain, then it is an issue. With risk, we deal with uncertainty. If the probability of something is zero, it has no uncertainty. If the probability is 100%, again, it has no uncertainty. The term Risk only applies when

0% < probability < 100%

In Risk Management, we avoid the term "threat" because in everyday discussion, "threat" could also mean "promise of harm" or "logical sequence resulting in harm."

For example, a bully "threatens" to call you a bad name. If we believe the bully, this type of threat would be an issue, not a risk, because there is no uncertainty. If we don't care what the bully says, there is no effect, so it is neither a risk nor an issue.

Another side of risk

Most explanations of risk concentrate on the probability of the event. What if the event is certain, but you don't know what the effects will be?

Risk has two real parts:

• Cause - A condition or possible change in conditions
• Result - The effect that may happen

Risk has a probabilistic part, too:

• Uncertainty

PMP study materials usually focus on uncertainty about whether the cause will happen. However, we can also have uncertainty about what effect a condition or change in conditions may cause.

Therefore, a condition (or change) may be certain, but you still have risk if you have uncertainty about the results.

As PMs, we are communicators. We listen. Others often use terms and definitions different from ours. So we ask people what they mean and negotiate a common vocabulary. We do this to control the risk of broken communications.

If we find that somebody says "the bully is a threat" and means "the bully poses a risk," then we could enter this in the Risk Log in one of three ways:

• There is x% chance that the bully will call another worker a bad name, causing that worker to quit.
• The bully will call another worker a bad name, and there is y% chance that the other worker will quit.
• There is x% chance that the bully will call another worker a bad name and y% chance that the other worker will quit.

If there is 100% probability that the bully has or will call the coworker a bad name and a 100% probability that the coworker will or has quit, then we have an issue.

And if you go around calling my coworkers bad names, we have an issue.

Further study: Use a search engine to learn more about "aleatory variability" and "epistemic uncertainty." However, please don't ask me about them because, the way other authors explain them, I do not understand at all.

(c) Copyright 2014, Richard Wheeler