Identifying Obstacles and Building Mitigation Strategies in Your V2MOM Example
This skill teaches you how to systematically surface the risks, blockers, and dependencies hiding inside your V2MOM and convert each one into a concrete contingency plan with clear owners, triggers, and countermeasures.
Start by listing every assumption behind your Methods section, then stress-test each one by asking what happens if it fails. Categorize the resulting risks by likelihood and severity. For each high-priority obstacle, write a concrete mitigation plan with a trigger condition, an owner, and a specific countermeasure. Revisit the obstacle list quarterly or when conditions shift. This process transforms the Obstacles section from a vague worry list into an actionable risk register.
Outcome: You produce a prioritized obstacle register where every high-severity risk has a named owner, a defined trigger condition, and a documented mitigation plan, so your team can respond to setbacks without losing momentum on the V2MOM's Methods.
Prerequisites
- A drafted V2MOM with at least a working Vision, Values, and Methods section
- Familiarity with the V2MOM Framework structure and how the five elements relate
- Access to stakeholders or teammates who can pressure-test assumptions
- Basic understanding of risk assessment concepts like likelihood and severity
Overview
The Obstacles section is the most underused part of the V2MOM Framework. Teams invest serious energy writing a compelling Vision, debating Values, and mapping Methods, then rush through Obstacles with a few generic phrases like "limited budget" or "competing priorities." The result is a plan that looks strong on paper but fractures at the first real challenge. Identifying obstacles is not about pessimism. It is about building a plan that survives contact with reality.
This skill teaches you how to move from vague risk awareness to a structured obstacle register. You will learn to extract hidden assumptions from your Methods, convert those assumptions into testable risks, score each risk for likelihood and severity, and then build specific mitigation strategies for the ones that matter most. The concrete artifact you produce is a prioritized obstacle table: each row contains the obstacle name, its likelihood and severity scores, the trigger condition that tells you the risk is materializing, an owner responsible for the response, and the specific countermeasure they will execute. This table lives alongside your V2MOM and gets reviewed at every check-in.
In any real v2mom example, the Obstacles section is what separates a strategy document from a wishful thinking exercise. When Marc Benioff introduced V2MOM at Salesforce, the framework's power came from forcing leaders to name what could go wrong before it went wrong. If your Methods are the engine of execution, your Obstacles section is the early warning system. Done well, it lets your team pre-commit to contingency actions so that when a blocker surfaces, the response is a calm pivot rather than a panicked scramble. This skill sits between defining your Methods and setting your Measures, because you cannot set realistic success criteria until you have accounted for what might slow you down.
How It Works
The core mental model is assumption extraction followed by structured risk scoring. Every Method in your V2MOM rests on a set of assumptions. "Launch the new onboarding flow by Q3" assumes you have enough engineering capacity, that the design is finalized, that the API dependency ships on time, and that no regulatory change blocks the feature. Most of these assumptions are invisible until someone deliberately surfaces them. The obstacle identification process works by making every assumption explicit, then asking a simple question for each one: "What happens to this Method if this assumption turns out to be false?"
The reason this works better than brainstorming a generic risk list is specificity. When you anchor obstacles to specific Methods and specific assumptions, you get risks that are concrete enough to mitigate. "Hiring is slow" is not actionable. "If we cannot hire a senior data engineer by week 8, the analytics pipeline required for Method 3 will not ship before the Q3 deadline" is actionable, because it tells you the trigger condition (week 8 hiring status), the impact surface (Method 3, Q3 deadline), and the severity (the pipeline does not ship at all, not just late).
Once you have a list of concrete obstacles, you score each one on two dimensions: likelihood (how probable is this, given what you know today?) and severity (if this happens, how much does it damage the V2MOM's Vision?). A simple 1-3 scale for each dimension is sufficient for most teams. Multiply the two scores to get a priority number between 1 and 9. Anything scoring 6 or above gets a full mitigation plan. Scores of 3-5 get a monitoring plan with a named watcher. Scores of 1-2 get documented but not actively managed.
Mitigation strategies themselves follow a pattern borrowed from contingency planning. Each mitigation has four parts: the trigger (what observable event tells you the risk is materializing), the owner (who is accountable for executing the response), the countermeasure (the specific action they will take), and the residual impact (what outcome you accept even after mitigation). This last piece is important because it forces honesty. Not every risk can be eliminated. Sometimes the best mitigation reduces a catastrophic outcome to a painful but survivable one. Documenting that residual impact up front prevents surprise and lets leadership adjust Measures accordingly.
The framework works across scales. A company-level V2MOM might surface market risks and competitive threats. A team-level V2MOM might surface dependency risks and capacity constraints. An individual contributor's V2MOM might surface skill gaps and conflicting priorities. The technique is the same: extract assumptions, convert to testable risks, score, and mitigate.
Step-by-Step
Step 1: Gather Your Drafted V2MOM and Assemble the Right People
Pull together your working V2MOM document with at least a draft Vision, Values, and Methods section. If this is a team or organizational V2MOM, invite 3-6 people who have direct knowledge of execution realities: the people who will actually do the work, manage the dependencies, or interact with external partners. Individual V2MOMs still benefit from a second perspective, so consider inviting a manager or a peer who understands your workload. Print or share the Methods section prominently, because that is where you will anchor the obstacle identification.
Block 90-120 minutes for a team session, or 30-45 minutes if working solo. Have a shared document or whiteboard ready to capture obstacles in real time.
Tip: Do not invite only senior leaders. The people closest to the execution, engineers, designers, account managers, see risks that leadership systematically underestimates. Include at least one person who will be hands-on for each major Method.
Step 2: Extract Assumptions from Each Method
Go through your Methods one at a time. " Write down every answer. These are your assumptions. Common categories include resource availability (people, budget, tools), external dependencies (vendor deliveries, API launches, partner agreements), organizational conditions (executive sponsorship, cross-team cooperation, no reorgs), market conditions (customer demand holds, competitor does not undercut), and technical feasibility (the architecture supports this, performance targets are reachable).
Aim for 3-7 assumptions per Method. If a Method has fewer than 3, probe harder. If you are drafting a v2mom example for practice, use realistic constraints from your actual work context so the assumptions feel concrete rather than hypothetical.
Tip: Use the phrase "what has to be true" rather than "what could go wrong." The former surfaces hidden dependencies and conditions. The latter tends to produce generic anxiety items like "things take longer than expected."
Step 3: Convert Assumptions into Obstacle Statements
Take each assumption and invert it into an obstacle statement using the format: "If [assumption fails], then [specific consequence to Method]." For example, the assumption "The design team finalizes the new checkout flow by March 15" becomes the obstacle "If the design team does not finalize the new checkout flow by March 15, the engineering sprint for Method 2 slips by at least two weeks, pushing the launch past the Q2 target." This format forces specificity on both the condition and the impact. Avoid vague obstacle statements like "Design delays." Every obstacle should name the assumption it inverts, the Method it threatens, and the nature of the damage. Work through the full assumption list and produce one obstacle statement per assumption. You will typically end up with 15-30 raw obstacles for a team V2MOM.
Tip: If an obstacle statement does not reference a specific Method by name or number, rewrite it until it does. Untethered obstacles are almost impossible to mitigate because nobody can see the blast radius.
Step 4: Score Each Obstacle for Likelihood and Severity
Create a simple scoring table with columns for Obstacle, Likelihood (1-3), Severity (1-3), and Priority Score (Likelihood x Severity). Score likelihood based on current evidence: 1 means unlikely given what you know today, 2 means possible and you have seen early signals, 3 means probable or already beginning to materialize. Score severity based on impact to the Vision: 1 means the obstacle slows a Method but the Vision is achievable, 2 means a Method is significantly degraded and the Vision outcome is reduced, 3 means a Method fails entirely and the Vision is threatened. Have each participant score independently before discussing as a group to avoid anchoring.
After individual scoring, discuss and converge on a consensus score. Multiply to get the priority number. Sort the table by priority score descending.
Tip: When the group disagrees on a likelihood score, that disagreement is itself a signal. It usually means someone has information others lack. Pause and share that information before converging, because the goal is not consensus for its own sake but shared understanding of the risk landscape.
Step 5: Triage Obstacles into Action Tiers
Divide your scored obstacles into three tiers. Tier 1 (priority score 6-9) gets a full mitigation plan. These are your critical obstacles, the ones most likely to derail your V2MOM. Expect 3-6 Tier 1 obstacles for a typical team V2MOM.
Tier 2 (priority score 3-5) gets a monitoring plan: name a watcher, define what signal they look for, and set a review cadence (usually monthly or at each V2MOM check-in). Tier 3 (priority score 1-2) gets documented in your obstacle register but requires no active management. Simply knowing they exist is sufficient. This triage prevents the common failure mode of trying to mitigate everything, which dilutes attention and creates a false sense of security.
Tip: If you have more than 6 Tier 1 obstacles, your Methods section may be overloaded. Consider whether some Methods should be descoped, deferred, or broken into phases. A V2MOM with too many critical obstacles is a plan that does not actually believe in itself.
Step 6: Build Mitigation Plans for Tier 1 Obstacles
For each Tier 1 obstacle, document four elements. First, the trigger: the specific, observable event that tells you this risk is materializing. "The design team has not delivered final mocks by March 1" is a good trigger. "Things seem behind" is not.
Second, the owner: the single person accountable for executing the mitigation response. This should be someone with the authority and capability to act, not necessarily the most senior person. Third, the countermeasure: the specific action the owner will take when the trigger fires. Examples include reallocating budget, activating a backup vendor, descoping a feature, extending a timeline, or escalating to a specific decision-maker.
Fourth, the residual impact: what outcome you accept even after the mitigation executes. " Write all four elements in your obstacle register. Each mitigation plan should be 3-5 sentences total, precise enough that someone unfamiliar with the context could execute it.
Tip: Test each countermeasure with the question: "Could someone execute this on a Friday afternoon without calling a meeting?" If the answer is no, the countermeasure is too vague. Break it into smaller, pre-authorized actions.
Step 7: Assign Monitoring Plans for Tier 2 Obstacles
For each Tier 2 obstacle, assign a watcher, the person responsible for monitoring the risk. Define the signal they are watching for, something more specific than "things getting worse." For example, "Customer churn exceeds 5% in any single month" or "The partner has not responded to our integration spec by April 15." Set the review cadence, which is typically your V2MOM check-in rhythm (monthly or quarterly). The watcher reports a simple status at each check-in: green (no signals), yellow (early signals detected, recommend re-scoring), or red (trigger fired, recommend elevating to Tier 1 and building a full mitigation plan). Document these monitoring assignments in the same obstacle register so everything lives in one place.
Tip: Rotate watchers quarterly if your V2MOM runs for a full year. Fresh eyes catch signals that familiarity normalizes. The person who has been watching a risk for three months starts to rationalize away early warning signs.
Step 8: Integrate the Obstacle Register into Your V2MOM Document
Place the completed obstacle register directly into the Obstacles section of your V2MOM. Do not keep it as a separate document, because separate documents get forgotten. The format should be a table or structured list that any reader of the V2MOM can scan quickly. Include the obstacle name, the Method it threatens, the priority score, and for Tier 1 items the trigger and countermeasure summary.
Link the obstacle register to your Measures section by noting which measures might need adjustment if specific obstacles materialize. If your organization uses cascading V2MOMs, share your obstacle register with teams whose V2MOMs depend on your Methods, because your obstacles may become their obstacles.
Tip: Add a "Last Reviewed" date to the obstacle register header. This creates social pressure to keep the register current and makes it immediately obvious if the section has gone stale.
Step 9: Schedule Obstacle Register Reviews
Set a recurring review cadence for the obstacle register. Monthly reviews work well for quarterly V2MOMs. Quarterly reviews work for annual V2MOMs. At each review, re-score every Tier 1 and Tier 2 obstacle based on current information.
Promote Tier 2 obstacles to Tier 1 if their scores increase. Demote Tier 1 obstacles to Tier 2 or Tier 3 if the risk has diminished. Add new obstacles that have emerged since the last review, because the risk landscape changes as execution progresses. Remove obstacles that are no longer relevant, but move them to a "Retired" section rather than deleting them, so you preserve the institutional learning.
Each review should take 15-30 minutes if the register is well-maintained.
Tip: The most valuable review question is not "has anything changed?" but "what do we know now that we did not know last month?" New information is the input that changes scores. Without it, reviews become rubber-stamp exercises.
Examples
Example: B2B SaaS Product Team Launching a New Integration
A 12-person product team at a mid-stage B2B SaaS company is building a V2MOM for Q3-Q4. Their Vision is to become the default workflow tool for marketing teams. One of their key Methods is launching a native integration with a major CRM platform by October 1. The team has 4 engineers, a dependency on the CRM vendor's API team, and a tight holiday code freeze starting November 15.
The team runs assumption extraction on the CRM integration Method and surfaces seven assumptions: the CRM vendor's API documentation is accurate, the vendor's sandbox environment is available by August 1, two senior engineers remain allocated full-time through October, the security review takes no more than two weeks, the design team delivers the integration UX by July 15, no critical bugs from the Q2 release divert engineering capacity, and the partner agreement is signed by July 1. They invert each assumption into obstacle statements. " The mitigation plan assigns the engineering lead as owner, defines the trigger as "no sandbox access confirmed by July 25" (giving a one-week buffer), and specifies the countermeasure: switch to mock API testing for the first two sprints using the existing documentation, which allows development to proceed while sandbox access is resolved. The residual impact is that mock-based development may require a refactoring sprint once real sandbox access arrives, potentially pushing the launch to October 15.
The team documents this in their V2MOM and notifies the partner manager to escalate sandbox access immediately.
Example: Early-Stage Startup Founder Writing a Personal V2MOM
A solo founder with two contractors is writing a personal V2MOM for the next 6 months. Her Vision is to reach $10K MRR with her developer tools product. Her Methods include shipping three key features, building a content marketing engine, and closing two enterprise pilot customers. She has limited runway (8 months of cash) and no dedicated marketing person.
Working alone, she extracts assumptions from each Method by writing them on index cards. The content marketing Method assumes she can write 2 blog posts per week while also doing product work, that organic search traffic will begin compounding within 3 months, and that she can learn basic SEO without hiring a consultant. She scores "content output drops below 1 post per week due to product demands" as Likelihood 3, Severity 2, Priority 6, making it Tier 1. " The countermeasure is pre-authorized: she will batch-write 8 posts over one weekend per month and schedule them, switching from a continuous writing model to a batch model.
The residual impact is that posts may feel less timely, but volume is preserved. For the enterprise pilot Method, she scores "both target companies enter budget freeze in Q4" as Likelihood 2, Severity 3, Priority 6. Her countermeasure is to expand the pilot prospect list from 2 to 5 companies by July 15, increasing the probability that at least 2 close even if some freeze budgets. She documents both mitigations directly in her V2MOM and reviews them biweekly during her solo planning sessions.
Example: Enterprise Engineering Organization Cascading Obstacle Registers
A 200-person engineering division at an enterprise company uses cascading V2MOMs. The VP of Engineering has an organizational V2MOM with a Method to migrate the core platform from a legacy monolith to microservices within 18 months. Four teams each have their own V2MOMs with Methods that depend on the migration timeline. The company has a hiring freeze and a simultaneous compliance deadline in Q2.
The VP's planning session surfaces 22 raw obstacles, which they score and triage into 5 Tier 1, 8 Tier 2, and 9 Tier 3 items. " The mitigation plan assigns the Director of Platform as owner. The trigger is "compliance work exceeds 30% of senior engineer allocation in any sprint" (set at 30% rather than 40% to allow response time). The countermeasure is to bring in a pre-vetted compliance consulting firm for the audit preparation work, freeing internal engineers to stay on migration.
This countermeasure was pre-negotiated with the CFO during planning and has budget approval conditional on the trigger firing. The VP shares this obstacle register with all four downstream teams. " Their countermeasure is to begin the adapter layer design in parallel as a contingency. This cross-team obstacle visibility prevents the situation where Team 3 discovers the slip in Q3 with no backup plan.
Example: Marketing Team V2MOM with Budget and Headcount Constraints
A 6-person marketing team at a Series B company has a V2MOM with a Vision of becoming the category-defining brand in their space. Methods include launching a podcast, running 4 virtual events, and publishing an annual industry report. The team recently lost their content lead, budget is frozen until the next funding round, and two other teams are competing for the same design resources.
The team runs assumption extraction and identifies 18 obstacles across their three Methods. The industry report Method scores highest for risk: "If we cannot hire a replacement content lead by month 3 and design resources remain contested, the industry report timeline pushes past the industry conference in November, eliminating the primary distribution moment" (Likelihood 3, Severity 3, Priority 9). Rather than listing "hire content lead" as the countermeasure (since the hiring freeze makes that unlikely), the team builds a realistic mitigation. " The owner is the marketing director.
The countermeasure is to restructure the report from an 80-page designed PDF to a 20-page data brief with 5 companion blog posts, reducing design dependency by 70% and writing load by 50%. The residual impact is a less visually polished deliverable, but the data and insights, which are the actual value, ship on time for the conference. The team also scores their podcast Method obstacle: "If the team lead who volunteered to host leaves the company, the podcast has no host and no backup" (Likelihood 2, Severity 2, Priority 4, Tier 2). The monitoring plan assigns a team member to check in monthly on the host's engagement and to begin training a backup host by month 2 regardless, converting a monitoring plan into a preventive action.
Best Practices
Anchor every obstacle to a specific Method by name or number. Unanchored obstacles like "market uncertainty" cannot be mitigated because nobody can see which part of the plan they threaten. When an obstacle references a specific Method, the blast radius is visible and the countermeasure can be proportional. Unanchored obstacles accumulate into a vague cloud of worry that paralyzes rather than prepares.
Score likelihood and severity independently before group discussion. When scores are discussed openly first, the most senior or most confident voice anchors the group. Independent scoring surfaces genuine disagreement, which is where the most valuable risk information lives. Use silent sticky notes, a shared spreadsheet with hidden columns, or anonymous polling before the discussion round.
Write trigger conditions as observable events, not subjective judgments. "The project feels behind schedule" is not a trigger. "The engineering team has not merged the authentication PR by sprint 6" is a trigger. Observable triggers prevent the two most common failures: triggering too late because everyone rationalized away soft signals, and triggering too early because someone panicked over normal variance.
Limit Tier 1 obstacles to 3-6 per V2MOM. If everything is critical, nothing is. More than 6 Tier 1 items usually means the Methods section is overloaded or the scoring criteria are too loose. Force-rank the top obstacles and push the rest to Tier 2. The discipline of limiting Tier 1 also forces honest conversations about which risks the organization is willing to accept.
Make mitigation countermeasures pre-authorized. The value of a mitigation plan collapses if executing it requires three levels of approval when the trigger fires. During the planning session, get explicit agreement from the relevant decision-makers that the countermeasure can be executed when the trigger fires without additional sign-off. Document that authorization in the obstacle register.
Review and re-score the obstacle register at every V2MOM check-in. A static obstacle list is a historical artifact, not a risk management tool. Conditions change, new information arrives, and some risks resolve while new ones emerge. The review cadence should match your V2MOM check-in rhythm. If you check in monthly, review obstacles monthly.
Share obstacle registers across cascading V2MOMs. Your Tier 1 obstacle may be an unrecognized risk for a downstream team whose Methods depend on your deliverables. When organizations use cascading V2MOMs, obstacle transparency prevents the situation where Team A quietly mitigates a risk by descoping a feature that Team B was counting on.
Common Mistakes
Listing obstacles as vague categories instead of specific, testable risks
Correction
"Limited resources" and "competing priorities" appear in almost every V2MOM obstacle section, and they are useless because they cannot be mitigated. This happens because teams brainstorm risks without anchoring them to specific Methods and assumptions. The signal that you have fallen into this trap is an obstacle that could be copy-pasted into any team's V2MOM without modification. Fix it by rewriting each obstacle using the "If [assumption fails], then [specific consequence to Method]" format.
If you cannot name the Method it threatens, the obstacle is too vague to keep.
Treating the obstacle section as a one-time exercise completed during planning and never revisited
Correction
This is the most common failure mode. Teams spend two hours building a thoughtful obstacle register, then never look at it again. It happens because obstacle reviews are not built into the V2MOM check-in agenda. The signal is that six months into execution, the obstacle register still shows the original scores with no updates.
Fix it by adding a standing 15-minute obstacle review to every V2MOM check-in. Ask three questions: what new information do we have, which scores have changed, and are any triggers close to firing.
Writing mitigation plans that are actually just escalation paths
Correction
"Escalate to VP of Engineering" is not a mitigation plan. It is a way of punting the decision to someone else under pressure. This happens because the team does not feel empowered to pre-commit to a specific countermeasure. The signal is a mitigation plan that contains the word "escalate" or "discuss" as its primary action.
" Document that decision as the countermeasure and get pre-authorization during the planning session.
Scoring every obstacle as high likelihood and high severity
Correction
When every obstacle is a 9 out of 9, the scoring system provides no differentiation and the team cannot prioritize. " The signal is a priority column where more than half the items score 6 or above. Fix it by calibrating the scales before scoring. Give a concrete anchor for each level: for likelihood, define what "unlikely" and "probable" mean in your context with examples.
For severity, define what "slows a Method" versus "threatens the Vision" looks like for your specific V2MOM.
Identifying only external obstacles and ignoring internal ones
Correction
Teams are comfortable naming market risks, competitor threats, and vendor dependencies, but they resist naming internal obstacles like skill gaps, political resistance, or team burnout. This happens because internal obstacles feel like admissions of weakness. The signal is an obstacle register where every item references an external entity. Fix it by explicitly prompting for internal categories during Step 2: ask about capacity constraints, skill gaps, organizational alignment, competing internal priorities, and technical debt.
Frame internal obstacles as planning intelligence, not blame.
Creating mitigation plans that require the same constrained resources the obstacle threatens
Correction
If the obstacle is "insufficient engineering capacity for Method 3" and the mitigation is "hire a contractor to cover the gap," you have created a circular dependency if the hiring process is itself constrained. This happens because teams default to the most obvious fix without checking whether the fix is actually available. The signal is a countermeasure that implicitly assumes a resource or condition that the obstacle itself puts in doubt. Fix it by asking: "Does this countermeasure depend on any of the same assumptions that the obstacle challenges?" If yes, find an alternative path that uses different resources or accepts a different trade-off.
Other Skills in This Method
Comparing V2MOM with OKRs and Other Goal-Setting Frameworks
How to evaluate when to use V2MOM versus OKRs, balanced scorecards, or other strategic planning frameworks based on organizational needs.
Facilitating Collaborative V2MOM Planning Sessions
How to run effective workshops and meetings to collaboratively develop, review, and refine V2MOMs with leadership teams and cross-functional stakeholders.
Building V2MOM Templates and Worksheets
How to design reusable V2MOM templates, worksheets, and documents that standardize the planning process across your organization.
Writing Compelling Vision and Values Statements
How to craft clear, inspiring vision statements and define the core values that guide decision-making within the V2MOM framework.
Cascading V2MOMs from Leadership to Individual Contributors
How to align organizational V2MOMs by cascading them from company-level down through departments, teams, and individual contributors for full strategic alignment.
Defining Methods and Actionable Steps in V2MOM
How to translate your vision and values into specific, executable methods and tactical action plans that drive results.
Setting Measurable Success Criteria for V2MOM
How to define quantifiable measures and key metrics that track progress and determine whether your V2MOM goals have been achieved.
Frequently Asked Questions
How many obstacles should a typical V2MOM have?
A well-constructed V2MOM typically surfaces 15-30 raw obstacles during the assumption extraction process. After scoring and triaging, expect 3-6 Tier 1 obstacles with full mitigation plans, 5-10 Tier 2 obstacles with monitoring assignments, and the rest as documented Tier 3 items. If you have fewer than 10 total, you probably have not probed your assumptions deeply enough. If you have more than 6 Tier 1 items, either your scoring is inflated or your Methods section is overloaded. A v2mom example with 4-5 Tier 1 obstacles and clear mitigation plans is stronger than one with 15 undifferentiated risks.
Should I identify obstacles before or after defining my Measures?
Identify obstacles after Methods but before finalizing Measures. Your obstacle register directly informs what success looks like, because realistic measures must account for the risks you have identified. If a Tier 1 obstacle has a residual impact of "feature launches 3 weeks late," your Measures should reflect that possibility rather than assuming a best-case timeline. Some teams iterate, drafting preliminary measures, then adjusting them after the obstacle analysis reveals which Methods are most at risk. Either sequence works, but never finalize Measures without reviewing your obstacle register first.
How do I handle obstacles that span multiple V2MOMs in a cascading structure?
When one team's obstacle is another team's dependency, both teams should document the obstacle in their own registers with cross-references. The upstream team (the one whose Method creates the dependency) owns the primary mitigation. The downstream team (the one waiting on the deliverable) should build a contingency countermeasure they can execute independently if the upstream mitigation fails. Share obstacle registers across cascading V2MOMs at every check-in so that score changes propagate. If the upstream team re-scores a risk from Tier 2 to Tier 1, the downstream team needs to know immediately.
What if my team resists naming internal obstacles like skill gaps or political resistance?
This resistance is normal and predictable. Internal obstacles feel like admissions of weakness, especially in organizations where vulnerability is not safe. Three techniques help. " Second, start with external obstacles to build momentum and trust in the process before turning to internal categories. Third, the facilitator should model vulnerability by naming an internal obstacle themselves first. If resistance persists, try anonymous input: have people submit internal obstacles on index cards or in a shared document without names, then discuss the themes rather than attributing specific concerns to individuals.
How often should I revisit and re-score my obstacle register?
Match your obstacle review cadence to your V2MOM check-in cadence. For quarterly V2MOMs, review obstacles monthly. For annual V2MOMs, review quarterly at minimum and monthly during high-execution periods. The review should take 15-30 minutes if the register is well-maintained. Beyond the regular cadence, trigger an ad-hoc review whenever a significant change occurs: a key person leaves, a budget shifts, a competitor makes a major move, or a dependency delivers early or late. Stale obstacle registers are worse than no register at all, because they create a false sense of preparedness.
Can I use this obstacle identification process for a personal or individual contributor V2MOM?
Yes, and it is simpler but equally valuable. For an individual V2MOM, extract assumptions from your personal Methods the same way, but the obstacle categories shift toward skill gaps, time conflicts, dependency on others' decisions, and energy management. You can skip the group scoring process and score on your own, but still write trigger conditions and countermeasures for your Tier 1 items. The discipline of pre-committing to a countermeasure is even more valuable for individuals, because when a solo contributor hits a blocker, there is no team to absorb the shock. Having a pre-decided pivot reduces decision fatigue at the worst possible moment.
Why does my obstacle register keep growing instead of shrinking over time?
A growing register usually means one of two things. First, you may not be retiring resolved obstacles. At each review, explicitly ask which obstacles have been resolved or are no longer relevant, and move them to a Retired section. Second, execution naturally surfaces new risks that were not visible at planning time, which is healthy and expected. The total number of active obstacles should fluctuate but not trend upward indefinitely. If it does, check whether your Methods have expanded in scope without a corresponding V2MOM revision. Scope creep in Methods creates a cascade of new obstacles that the original plan did not anticipate.