You’ve got three SI proposals in front of you. One is $500K. One is $800K. One is $1.2M. They’re all supposed to deliver roughly the same thing.
The $700K spread isn’t random. It reflects differences in how each vendor is defining scope, what assumptions they’re making about your environment, and sometimes how aggressive they’re being about keeping the initial number low while planning to recover margin through change orders.
Without understanding these differences, you’re guessing. And if you guess wrong, you’re looking at a project that costs significantly more than you signed up for, takes longer than estimated, and delivers less than you expected.
Here’s how to evaluate proposals with enough sophistication to make a good decision.
Why Estimates Blow Up
Most overruns fall into predictable categories.
Hidden integrations. “Integrate with your ERP” is a four-word phrase that hides months of work. Does the ERP API exist and is it documented? Is it real-time or batch? Bidirectional or one-way? What happens when records fail validation? Has the SI actually integrated with your specific ERP version before? If a vendor can’t answer these questions in detail, they haven’t actually estimated the integration, they’ve guessed and assumed it goes smoothly.
Data migration underestimation. Your data is messier than anyone on your team will admit upfront. Product records have inconsistent naming conventions. Price book entries have duplicates. Customer data has been maintained differently across regions. Data remediation (cleaning, deduplicating, standardizing) is always more work than initial estimates account for. A “two-week data migration” that starts with an unaudited data set is a fiction.
Change orders for “out of scope” items. The scope says “three CPQ workflows.” You need five. The scope says “basic reporting.” You need custom dashboards. The scope says “team training.” You have 30 people across three regions. These additions are predictable to anyone who’s done this before. A vendor who doesn’t call them out in the proposal is either planning to price them as change orders or hasn’t thought them through.
Underqualified teams. The partner who pitches you has fifteen years of Revenue Cloud experience. The team assigned after contract signing has never done a Revenue Cloud implementation. This happens more than it should. You bought a firm’s reputation; you got their bench.
Change management underinvestment. Real change management, not just training sessions but the organizational work of building adoption across sales, finance, and operations, is 20-30% of project effort. If a proposal allocates 10% to “training and adoption,” either they’re planning to cut corners or they’re planning a change order when reality sets in.
How to Evaluate Proposals
Give every vendor access to your actual environment, not just your description of it. Estimates built on assumptions are less reliable than estimates built on observed reality. Give bidders a few hours with your actual data, your actual systems, and your actual subject matter experts. The vendors who do real discovery will give you better estimates. The vendors who rely on your summary description will give you optimistic ones.
Require detailed scope statements with explicit assumptions. For every major workstream, ask: what specifically is delivered, what assumptions are you making, what’s explicitly not included, and what would trigger a change order? The best proposals will say things like: “We are assuming your product catalog contains fewer than 500 SKUs in a clean hierarchy. If not, data remediation will be a change order.” That’s honesty. It protects both parties.
Compare proposals feature-by-feature, not just bottom-line. Build a spreadsheet. List every deliverable you expect. Check each proposal against it. Some vendors will include things others don’t. Some will scope things more narrowly. Understanding the differences is how you evaluate whether a lower price is real savings or hidden risk.
Ask directly about change order exposure. For every item that isn’t crystal clear in the scope, ask: “Is this included or would it be a change order?” Don’t accept vague answers. If a vendor treats this question as negotiation rather than clarification, that’s a signal about how they’ll handle ambiguity once you’ve signed.
Check references from comparable implementations. Ask for clients with similar business model, similar complexity, and similar timeline. Call them. Ask: did they stay on budget? If not, what drove the overrun? Would they hire this vendor again? What surprised them? A vendor with consistently happy clients has earned that reputation. A vendor whose references are hard to contact or guarded in their responses hasn’t.
Get team member commitments in writing. Ask for the specific people who will work on your project. Review their experience. Make continuity a contract term, if key team members change, you have the right to renegotiate. You’re not hiring a company name; you’re hiring specific people.
Structuring a Contract That Protects You
Fixed-price with explicit change order discipline. Fixed-price contracts give you cost certainty and make the vendor accountable for their estimates. But they only work if scope is defined precisely enough that both parties know what’s in and what’s out. Vague scope plus fixed price is a recipe for disputes. Precise scope plus fixed price is how you manage a project.
Define “done” with specificity. Your contract should specify what each deliverable looks like, how you’ll evaluate whether it’s complete, what performance benchmarks apply, and what support the vendor provides post-launch if something doesn’t work as designed. “Implementation complete” is not a definition. “Revenue Cloud configured per approved design document, all user acceptance tests passed, go-live support provided for 30 days” is a definition.
Tie payment to milestones. Don’t pay 50% upfront and 50% at the end. Create a milestone schedule tied to specific deliverables, design sign-off, configuration complete, UAT complete, go-live, post-launch support period end. This creates accountability and gives you leverage if the project underperforms.
Allocate risk explicitly. Your contract should distinguish between risks the SI owns (effort underestimation, team quality, delivery approach), risks you own (requirements delays, incomplete data, unavailable stakeholders), and shared risks (third-party system integration complexity, scope discovered during implementation). Explicit risk allocation prevents disputes later about why the project cost more than expected.
Include a post-launch performance guarantee. Require 30-60 days of included support after go-live. Specify that the vendor will fix, at no additional charge, any defects where the system doesn’t perform as designed. This creates an incentive to design and test carefully before launch, not to fix problems after you’ve already paid in full.
Red Flags to Walk Away From
An overly aggressive timeline. If the estimate is 12 months and the vendor promises 8, someone isn’t being realistic. A vague answer when you ask what’s in scope. Pressure to sign quickly. Unwillingness to name the team before contract signing. References who can’t speak enthusiastically and specifically about their experience.
The right vendor is one who’s been honest with you throughout the sales process, about complexity, about risk, about what they don’t know yet. That’s the vendor who’ll be honest with you when the project hits inevitable challenges.
The upfront work of rigorous proposal evaluation is tedious. It’s also what determines whether you spend the right amount or twice as much.
I work on Revenue Cloud and Q2C implementations at Slalom. Connect with me on LinkedIn if you want a frank conversation about evaluating implementation proposals.