Risk and Readiness: Assessing Whether the Customer Can Actually Succeed

Deals don't usually die from a single dramatic failure. They die slowly, from risks that were visible but unaddressed. The security review that surfaces in week 11 of a 12 week evaluation. The VP who wasn't included in discovery and raises fundamental objections during the final presentation. The integration requirement that "should be straightforward" but turns out to require six months of custom development.

These aren't surprises. They're risks that could have been identified, assessed, and retired weeks or months earlier. The presales teams that do this consistently win more deals and deliver better outcomes. The teams that don't spend their careers wondering why promising deals collapse at the finish line.

This is the R in VERTEX: Risk and Readiness. It follows Environment and Evidence because you need a thorough understanding of the customer's current state before you can assess what might go wrong. And it comes before the evaluation phases because the risks you identify here directly shape how you design the POV, structure the transformation roadmap, and prepare for late stage objections.

The Three Categories of Risk

Every enterprise deal carries risk in three dimensions. Most presales teams are reasonably good at identifying technical risks. Fewer are good at organizational risks. Almost nobody systematically addresses political risks.

Technical Risk

Can the solution actually work in this customer's environment?

Integration risk. Does the solution connect to the customer's existing systems? Are the APIs compatible? Do the data formats align? Is middleware required? How much custom development is needed?

Performance risk. Can the solution handle the customer's data volumes, transaction rates, and latency requirements? What happens at peak load? What happens when data scales 10x over the next three years?

Security and compliance risk. Does the solution meet the customer's security requirements? SOC 2, HIPAA, GDPR, FedRAMP, industry specific regulations? Does it support their authentication model, encryption standards, and data residency requirements?

Architecture risk. Does the solution fit the customer's deployment model? Cloud, on prem, hybrid? Does it work within their network architecture, their container orchestration, their CI/CD pipeline?

Data risk. Can the customer's data be migrated cleanly? Are there data quality issues that will affect the solution's performance? Are there data governance policies that restrict how data can be moved or processed?

Technical risks are the most straightforward to identify because they're concrete and testable. They're also the most straightforward to retire: you prove the integration works, you run performance benchmarks, you provide compliance documentation.

Organizational Risk

Is the customer's organization ready to adopt this solution?

Adoption risk. Will the end users actually use the new solution? Have they been consulted? Do they see the value? Is there training planned? What happens to the people whose current role is the manual process you're automating?

Change management risk. How much organizational change does this implementation require? New processes, new roles, new workflows? Does the organization have the capacity for this change, or are they already fatigued from other initiatives?

Resource risk. Does the customer have the internal resources to support implementation? Do they have the technical staff, the project management bandwidth, and the executive attention this initiative requires?

Timeline risk. Is the customer's expected timeline realistic given the scope of the implementation? Are there hard deadlines (regulatory, fiscal year, contractual) that create pressure, and is the timeline achievable?

Dependency risk. Does this initiative depend on other projects completing first? A cloud migration, a data warehouse implementation, a reorganization? If those dependencies slip, does your project slip too?

Organizational risks are harder to identify because they require understanding the customer's internal dynamics, not just their technology. They're also harder to retire because you can't solve them with a technical proof point. You address them through planning, communication, and partnership.

Political Risk

Do the people with power and influence support this initiative?

Sponsor risk. Does the executive sponsor have real authority? Can they actually approve the budget, or do they need someone else's sign off? How committed are they, and what would cause them to deprioritize this initiative?

Stakeholder alignment risk. Are all the key stakeholders aligned on the need, the approach, and the timeline? Or are there competing visions for how to solve this problem?

Competitive risk. Is there an internal champion for a competing solution, whether another vendor, a build option, or the status quo? How much influence do they have?

Budget risk. Is the budget allocated, or does it need to be requested? Is this budget at risk from other organizational priorities? What's the approval process, and who's involved?

Timing risk. Is there an organizational event that could derail the timeline? A leadership change, a reorganization, a merger, a hiring freeze, a budget cycle?

Political risks are the most dangerous because they're the least visible. Nobody tells you in a meeting that their boss doesn't actually support this initiative. Nobody announces that a competing project is about to absorb the budget. You discover political risks by asking uncomfortable questions and paying attention to signals.

The Risk Register

The practical output of Risk and Readiness is a risk register: a living document that tracks every identified risk and the plan to address it.

A simple risk register has five columns:

| Risk | Category | Likelihood | Impact | Mitigation Plan | |---|---|---|---|---| | Customer's LDAP system may not support our SSO integration | Technical | Medium | High | Schedule a technical deep dive with IT security team by Feb 15 | | CTO has not engaged in the evaluation | Political | High | High | Request an executive briefing through the champion; prepare a CTO specific value summary | | Implementation team is already committed to a data warehouse migration through Q2 | Organizational | High | Medium | Propose a phased rollout starting Q3; identify a quick win that can deploy independently | | Budget requires approval from a finance committee that meets quarterly | Political | High | High | Ensure champion has the business case materials two weeks before the next committee meeting | | End users have not been consulted and may resist a workflow change | Organizational | Medium | Medium | Include end user representatives in the POV; design a change management plan with the champion |

The register is a living document. It gets updated after every customer interaction. Risks get added as they're discovered, escalated as they become more urgent, and retired as they're addressed.

How to Identify Risks

Risks don't announce themselves. You have to actively look for them using three approaches.

Ask Directly

The simplest approach is often the most effective. In discovery sessions, explicitly ask:

"What could delay or derail this decision?"

"Have you tried to solve this before? What happened?"

"What concerns does your team have that we haven't addressed yet?"

"Is there anyone in the organization who might oppose this initiative?"

"What does your procurement and security review process look like, and how long does it typically take?"

These questions feel uncomfortable. That's the point. If you're not uncomfortable during discovery, you're probably not asking the right questions. The risks that kill deals are the ones nobody wanted to talk about.

Listen for Signals

Customers telegraph risks through language and behavior:

Vague timelines: "We'd like to have something in place by end of year... probably" signals low urgency or organizational uncertainty.

Single stakeholder engagement: If only one person is attending your meetings, the rest of the organization may not be engaged or aligned.

Deflected questions: "We'll figure out the budget later" or "Let's not worry about security right now" are red flags. These aren't deferred topics; they're risks being avoided.

Enthusiasm without authority: A technical champion who's incredibly excited but says "I'll need to run this by my VP" for every decision is signaling that the real decision maker isn't involved.

Competitor mentions: "We're also looking at [competitor]" is obvious. But "Our team has been really impressed with how [competitor] handles X" is a stronger signal because it reveals a specific preference forming.

Test Assumptions

Don't take anything at face value. When the champion says "Budget is approved," ask: "That's great. What was the approval process? Is it allocated to this specific initiative, or is it a general technology budget that could be redirected?"

When the technical lead says "Integration should be straightforward," ask: "Let's dig into that. Can you show me the API documentation for the system we'd need to connect to? Have you done similar integrations recently?"

When the project sponsor says "We're committed to a Q3 implementation," ask: "What else is competing for your team's attention in Q3? Do you have implementation resources allocated, or will we need to plan for that?"

These follow up questions aren't adversarial. They're thorough. And they regularly reveal risks that the initial statement obscured.

Retiring Risks

Identifying risks is only valuable if you actually address them. Each risk in the register needs a specific mitigation plan and an owner.

Technical Risk Retirement

Technical risks are retired through proof: conduct the integration test, run the performance benchmark, provide the compliance documentation, demonstrate the deployment in their architecture. The POV is your primary vehicle for retiring technical risks because it validates claims with evidence in the customer's own context.

Example: "The customer's security team is concerned about data residency. We'll schedule a 30 minute call with our security architect to walk through our data isolation model, provide our SOC 2 Type II report, and document the specific residency guarantees in writing."

Organizational Risk Retirement

Organizational risks are retired through planning and partnership: create a training plan, identify an implementation project manager, build a change management approach, propose a phased rollout that matches the customer's capacity.

Example: "The end user team hasn't been consulted and may resist the change. We'll include two end users in the POV as active participants, gather their feedback, and use their positive experience to build internal advocacy."

Political Risk Retirement

Political risks are retired through relationships and enablement: get the missing stakeholder into a meeting, enable your champion with the materials they need for the budget review, build a relationship directly with the skeptic, address the competitor concern head on.

Example: "The CTO hasn't engaged yet and has final approval authority. We'll prepare a 15 minute executive briefing focused on architecture scalability and total cost of ownership, which are the CTO's known priorities based on the champion's input. The champion will request the meeting for next week."

Common Mistakes

Assuming Silence Means No Risk

When the customer doesn't raise concerns, many SEs assume everything is fine. It's often the opposite. Silence means the customer hasn't thought about the risks yet, or they're avoiding a difficult conversation. Proactively surfacing risks is a sign of maturity and builds trust.

Treating Risk Assessment as a One Time Activity

The risk register isn't a document you create once and file away. New risks emerge throughout the deal. A stakeholder change in month two. A budget freeze in month three. A competitor demo that shifted perceptions in month four. The register needs to be reviewed and updated after every significant interaction.

Ignoring Risks You Can't Solve

Some risks are outside your control. You can't prevent a reorganization or a budget freeze. But you can acknowledge these risks, monitor them, and prepare contingency plans. "If the budget committee delays approval to Q2, here's our plan for maintaining momentum" is better than pretending the risk doesn't exist.

Over Indexing on Technical Risk

SEs naturally gravitate toward technical risks because that's their comfort zone. But in enterprise deals, political and organizational risks kill more deals than technical ones. Make sure your risk register has balanced coverage across all three categories.

Risk and Readiness in the VERTEX Sequence

Risk and Readiness takes the environmental understanding from Environment and Evidence and the objectives from Vision and Value and asks: "What could prevent this customer from achieving these outcomes in this environment?"

It feeds forward into:

Trajectory and Transformation uses the risk assessment to build a realistic roadmap. If you've identified resource constraints, the roadmap accounts for them. If you've identified political risks, the roadmap includes stakeholder management milestones.

Evaluation and Experiment uses the risk register to design a POV that retires the highest impact technical risks. The scenarios you test should map directly to the risks that need proof.

Execution and Expansion uses the risk register as part of the handoff. The implementation team needs to know which organizational and political risks are still active and how to manage them.

The discipline of Risk and Readiness transforms presales from an optimistic "let me show you what we can do" to a rigorous "let me make sure this actually succeeds." That shift in mindset is what separates SEs who close deals from SEs who close deals that actually deliver.

For a one page visual summary of all six VERTEX elements with key questions and outputs, download the free VERTEX Quick Reference Card. And for the complete Risk and Readiness methodology, check out Modern Presales. covers risk identification and retirement in depth.