The Selection Mandate

1.1 What “good” Looks Like: Outcomes, Not Features

Most teams start selection by building a long list of features. It feels rigorous, it is easy to delegate, and it produces a thick artifact that looks “complete.” The problem is that feature lists rarely create clarity. Mature enterprise vendors converge on feature parity over time, so a feature-by-feature comparison often separates vendors by marketing vocabulary, not real capability. Feature lists also invite a predictable dysfunction: stakeholders treat selection as their one chance to get a wishlist approved, so requirements expand until no product fits without customization, and customization quietly becomes the plan.

“Good” selection starts with outcomes. Outcomes are the business results you will be able to measure after the software is live, regardless of which vendor you pick. Outcomes force precision: if you cannot describe success in measurable terms, you will struggle to choose between two vendors that both look competent. Outcomes also create a shared language between business and technology leaders. Business leaders care about cycle time, revenue, margin, compliance, and customer experience. Technology leaders care about security, resiliency, integration, and operating cost. A good mandate translates both into a single scorecard.

In practice, define outcomes in three layers. First is the “why now” narrative that fits on one slide. Second is a small set of measurable targets. Third is a set of must-win scenarios—end-to-end workflows that must work because they are where value is created or risk is carried. When these layers agree, evaluation stays anchored. When they conflict, you will feel it later as demo disagreements, scope fights, and stalled decisions.

Start with the why-now narrative. It should be written in language a CFO would accept and a frontline manager would recognize. Avoid generic statements like “modernize” or “digitize.” Strong narratives typically combine an external pressure (competition, regulation, customer expectations), an internal pain (manual workarounds, data errors, slow reporting), and a strategic opportunity (new offers, faster scaling, partner ecosystem growth). If you cannot describe the narrative without naming a vendor, you are not writing an outcome; you are rationalizing a preference.

Next, translate the narrative into measurable targets. Don’t overdo it. A handful of targets the organization believes and can measure is better than a long list that no one trusts. A simple and complete set covers value, experience, risk, and agility:

• Value: economic impact such as revenue lift, margin improvement, cost-to-serve reduction, or working-capital benefits.
• Experience: improvements for customers, partners, and employees such as fewer steps, higher first-time-right rates, or better self-service.
• Risk: reductions in compliance exposure, audit findings, security incidents, or control failures.
• Agility: the ability to change products, pricing, workflows, or integrations faster and with less dependency on scarce experts.

For each target, define the metric, the baseline, the target, and the time horizon. If you do not know the baseline, write “baseline to be measured” and assign an owner. Ownership makes the metric real. A selection effort without metric owners is a signal the mandate is still more political than operational.

The third layer—must-win scenarios—is where outcomes become testable. Must-win scenarios are not “features.” They are cross-functional stories that connect users, data, rules, integrations, and exceptions. They expose differences between vendors because they force you to confront configuration depth, workflow flexibility, and edge-case handling. For example, “support complex pricing” is a feature. A must-win scenario is “a sales rep builds a quote with negotiated pricing, product eligibility rules, taxes, multi-currency, and partner discounts; the quote routes for approval under delegation-of-authority rules; it converts to an order; and it flows to billing and revenue recognition without rekeying.” The scenario is long because reality is long.

Write scenarios so they can be proven in a demo or proof of concept using your data. A scenario that cannot be tested becomes a debate. Every must-win scenario should include explicit success criteria: what must happen, what can be deferred, how long it can take, and what errors are unacceptable. Also include at least one “messy” step—an exception, an approval, a correction, or a partial failure—because that is where most systems reveal their true usability.

As you translate outcomes into evaluation criteria, differentiate among three capability types. Table stakes: capabilities every credible vendor has; they rarely decide the winner but can eliminate weak options. Differentiators: capabilities where vendor approaches genuinely vary and where your organization has a point of view (for example, how much workflow flexibility you need, or how deeply rules must be embedded). Tripwires: capabilities or constraints that, if not met, will cause failure regardless of everything else (for example, a required certification, data residency, or integration pattern). This separation prevents false precision: you stop spending energy “scoring” table stakes and focus instead on real decisions.

A common trap is assuming software alone delivers outcomes. Outcomes come from the combination of software, process choices, data quality, and adoption. If an outcome requires people to behave differently, then change management is part of the outcome. Treat adoption as a measurable target, not as a training event. In selection, this means you evaluate usability, role fit, and the vendor’s support for in-app guidance, analytics, and administrative controls that make adoption sustainable.

To keep the team from drifting back to feature counting, build a simple “Outcome-to-Evidence Map.” It can be a slide or a spreadsheet, but it should be visible and used. For each outcome, document the small set of evidence you will accept during selection:

• Outcome statement: the measurable result (for example, “reduce quote-to-cash cycle time by 30% within 12 months”).
• Must-win scenarios: the scenarios that prove the outcome is achievable.
• Evidence type: demo script, PoC test case, reference calls, security review, or architecture assessment.
• Owner: the executive accountable for realizing the outcome after go-live.

One practical move at this stage is to capture the mandate as a one-page “north star” that you can reuse in every meeting. People will forget what was agreed, new stakeholders will join, and vendors will try to reframe the conversation. A crisp one-pager prevents drift because it gives you a stable reference point. Keep it short enough that executives will actually read it, and specific enough that teams can act on it. A useful structure is:

• Problem statement: what is broken today and why it matters now.
• Outcomes and targets: three to six measurable results with owners.
• In scope: processes, user groups, geographies, and channels included in the decision.
• Out of scope: what will not be solved in this release (and why).
• Guardrails: non-negotiables on security, compliance, architecture, and timeline.
• Decision rights: who recommends, who decides, and how ties are broken.

Include one more element that teams often skip: the things you are intentionally not optimizing for. These “anti-goals” prevent later arguments. Examples include “we will not replicate every legacy report,” “we will not customize to preserve local variations unless required by law,” or “we will not trade auditability for speed.” Anti-goals are not negativity; they are focus.

Finally, make tradeoffs explicit. Selection always involves choosing between good options with different strengths. If you do not set priorities early, tradeoffs will be made implicitly during negotiation or implementation—usually by whoever is loudest or most time-constrained. A strong mandate contains a short priority statement, such as “time-to-value and adoption outweigh advanced customization,” or “security and auditability are non-negotiable even if it slows delivery.” This single sentence can save months later.

1.2 Typical Failure Modes (And How This Playbook Prevents Them)

Enterprise selection efforts fail in predictable ways. The patterns repeat because the underlying forces are the same: conflicting incentives, incomplete information, and the human tendency to substitute what is easy to measure (features, price per user) for what matters (fit to outcomes, implementation risk, adoption). Your goal is not to eliminate all risk—selection always involves uncertainty—but to prevent avoidable failure and to make the remaining risk visible and manageable.

Below are the failure modes I see most often. Each one includes the practical “tell” that it is happening and the preventive move that stops it early.

• Vendor-first decision: the organization starts with a preferred product and runs selection to justify it. Prevent: require at least two credible alternatives and force the preferred vendor to prove fit against must-win scenarios.
• Requirements theater: thousands of requirements appear, many vague and untestable, and vendors answer “yes” to everything. Prevent: keep early requirements lean, prioritize tripwires and scenarios, and define verification methods for high-weight criteria.
• Scope creep as inclusion: every geography and edge case becomes “mandatory,” and the decision never converges. Prevent: define scope boundaries for the selection decision and treat rollout sequencing as a separate, later decision.
• Demo as entertainment: vendors control demos, show the happy path, and stakeholders leave with different impressions. Prevent: script demos with your scenarios, insist on your data, score live, and treat “we can do that later” as risk.
• Implementation blindness: fit is judged on slides, while data migration, integration, and change are treated as “post-selection.” Prevent: evaluate implementation approach during selection, including configuration vs customization, resourcing, and a draft delivery plan.
• Operating model gap: the contract is signed without clarity on who owns the platform, data, releases, and support. Prevent: make post–go-live ownership and governance part of selection criteria and confirm staffing assumptions.
• Procurement too early: price optimization begins before fit is proven, leading to the “cheapest plausible” choice and expensive change orders later. Prevent: sequence decisions: validate fit and risk first, then compete commercials with a clear definition of what is being bought.
• False consensus: meetings end with apparent agreement, but objections reappear as vetoes or passive resistance. Prevent: use explicit scoring, document tradeoffs, and keep a decision log with dissent captured, not buried.
• Customization by default: stakeholders assume the new system will replicate every legacy nuance, including bad habits. Prevent: adopt a “configure before customize” principle and price customization honestly in the business case.
• Adoption ignored: selection focuses on features and commercials while usability, training burden, and manager visibility are afterthoughts. Prevent: include real users in scenario design, score usability, and require adoption-support capabilities (role UX, guidance, analytics).

Notice what these failures have in common: they are not caused by bad vendors. They are caused by teams losing control of the process and allowing easy signals to replace hard truths. This playbook prevents that by insisting on outcomes and evidence, not opinions; by separating elimination criteria from differentiators; by treating implementation and operating model readiness as selection criteria; and by producing auditable artifacts—scores, decision memos, and logs—so the final decision can be explained and defended.

Use the early-warning checklist below at the end of Week 1 and again before you issue an RFP. If you see more than two signals, stop and reset the mandate before you invest further:

• No accountable sponsor: everyone is “supporting,” but no one owns outcomes after go-live.
• Success defined as “go live”: the project is framed as delivery, not value realization.
• Requirements exploding: the list grows faster than it is clarified or prioritized.
• Unscripted demos: vendors control the narrative and stakeholders are not scoring consistently.
• Integrations deferred: critical upstream/downstream systems are not part of evaluation.
• Commercials before fit: negotiation starts while the team still can’t describe must-win scenarios.
• Preference-driven debate: people argue from past tool experience rather than agreed outcomes.

If a failure mode is already underway, the fix is rarely to “push harder.” The fix is to reset the process before sunk cost forces a bad decision. A reset does not mean starting over; it means restoring evidence and decision discipline. A simple reset protocol is:

• Reconfirm outcomes: restate the top outcomes and priorities in writing and get sponsor sign-off.
• Re-cut scope: separate what must be decided now from what can be phased, then stop debating the phased items.
• Rebuild evidence: tighten demo scripts, define what counts as proof, and convert vague criteria into test cases.
• Reestablish competition: ensure at least two viable options remain until late in the process.
• Re-log decisions: document tradeoffs and dissent so disagreements don’t reappear as surprises.

Resetting early can feel uncomfortable because it surfaces disagreement. In practice, it is cheaper than letting disagreement hide until contract signing or, worse, until implementation when changes are slow and expensive.

1.3 Choosing The Selection Approach: Shortlist-first Vs Requirements-first

There is no single best way to run a selection. The right approach depends on how mature your organization is, how clear your needs are, and how crowded and differentiated the vendor market is. Two archetypes dominate: requirements-first and shortlist-first. Most successful efforts combine elements of both, but choosing a primary approach keeps the team aligned on what to optimize.

In a requirements-first approach, you invest early in defining detailed requirements, evaluation criteria, and constraints, then use those artifacts to screen vendors through an RFP and structured demos. This approach works well when the domain is well understood, processes are stable, and constraints will eliminate many options (security, residency, regulatory, architecture). It is also appropriate when the decision will be audited. The risk is that stakeholders use requirements to negotiate scope rather than define outcomes, creating a bloated, untestable document that vendors can “yes” their way through.

In a shortlist-first approach, you start with a market scan, narrow quickly to a small number of credible vendors, and then deepen requirements and scenarios with those vendors through workshops, demos, and sometimes a proof of concept. This approach works well when the market is large or fast-changing, when your team is not sure what “good” looks like, or when time is constrained. The risk is vendor capture: early impressions harden into a choice before you have pressure-tested the hardest scenarios.

The practical decision comes down to what you need to learn first. If your uncertainty is about what the market can do, you should see products early (shortlist-first). If your uncertainty is about what the business is willing to standardize, you should do internal design work first (requirements-first). If uncertainty is both, run a hybrid: do a lightweight requirements pass focused on outcomes, tripwires, and must-win scenarios; use it to eliminate obvious mismatches; then deepen requirements only for two to three finalists while running tightly scripted scenario demos. The hybrid avoids the two classic traps: requirements theater and vendor capture.

When in doubt, decide what you need to learn first: market breadth, internal future-state alignment, constraint intensity, and reversibility. If the market is crowded, shortlist early. If constraints are hard, screen early. If switching later would be costly, invest more in proof.

Use a proof of concept only to resolve the hardest unknowns (scale, integration feasibility, data migration complexity, or role-specific usability). Time-box it, tie it to must-win pass/fail criteria, and staff it with your best people. If you can’t do that, skip the PoC and rely on scripted demos plus references.

Regardless of approach, two rules hold. First, keep the finalist set small enough that you can evaluate deeply—typically two or three. Second, never let vendors define your language. Vendors will naturally describe the world in terms of their product model. Your job is to describe the world in terms of your outcomes and scenarios, then test how each product supports them.

1.4 Deliverables Checklist (What You Will Produce By When)

A mandate becomes real when it produces artifacts that allow other people to act. In selection, that means documents, models, and decisions that are specific enough to guide evaluation and durable enough to survive leadership changes. The goal is not paperwork. The goal is the minimum set of deliverables that makes the decision defensible, the contract negotiable, and the implementation executable.

Think in five phases: frame, define, evaluate, decide, and mobilize.

To keep momentum, treat the selection as a set of gates rather than a continuous debate. Gates force smaller decisions on a schedule and prevent last-minute pileups. A practical rhythm is:

• Mandate gate (end of Week 1): outcomes, scope, and decision rights approved.
• Shortlist gate (Weeks 3–4): tripwires applied and finalists selected.
• Decision gate (Weeks 9–10): scorebook and business case approved; preferred vendor selected.
• Contract gate (Weeks 12–14): commercials finalized and mobilization plan ready.

Each gate needs a named owner and a written output to stop the team from relitigating decisions.

In smaller selections, phases overlap, but the deliverables remain largely the same. The checklist below fits a typical 10–14 week selection; scale up or down based on complexity and procurement rules.

• Selection mandate (Week 1): outcomes, scope boundaries, constraints, decision rights, and success metrics.
• Tripwires list (Week 2): non-negotiables across security, compliance, architecture, and operations.
• Must-win scenario pack (Weeks 2–3): two to five scripted scenarios with success criteria and a scoring rubric.
• Lean requirements pack (Weeks 2–4): prioritized functional and non-functional requirements with verification methods.
• Market scan and shortlist memo (Weeks 2–4): long list, elimination logic, finalists, and key risks.
• RFP/RFI package (Weeks 4–5): questions, response templates, and the scoring model.
• Scripted demos and scorecards (Weeks 5–7): agenda, roles, timing, and live scoring sheets tied to scenarios.
• Risk reviews (Weeks 5–8): security, architecture, and data/integration findings with required mitigations.
• Implementation plan draft (Weeks 6–9): assumptions, resourcing, configuration vs customization, and a first-release view.
• References summary (Weeks 7–9): structured notes and recurring themes across customers.
• TCO and final business case (Weeks 8–10): costs, benefits, ranges, and sensitivities.
• Final scorebook and decision memo (Weeks 9–10): consolidated scoring, tradeoffs, risks, and the recommendation.
• Negotiation issue log (Weeks 10–12): commercials, red flags, concessions, and open items tracking.
• Contract and SOW package (Weeks 12–14): signed agreements with deliverables and acceptance criteria.
• Mobilization plan (Weeks 12–14): governance, resourcing, and the first 90-day implementation plan.

Two deliverables prevent the most downstream pain. Decision memo: your insurance policy when people change roles or memories fade; it must state what you chose, why, what you gave up, and what you will do about key risks. Implementation plan draft: the sanity check that your choice can actually be delivered; you do not need a full project plan yet, but you do need a credible first release, resourcing view, and clarity on what is configuration versus custom build.

If you are under severe time pressure, don’t delete deliverables blindly. Reduce depth while preserving the spine. You can shorten the RFP, reduce the number of scenarios, or limit reference calls, but you should not skip the mandate, tripwires, scripted demos, risk reviews, and the decision memo. These are the artifacts that keep you in control when the process gets noisy.