Intro
Major systems integrator proposals often arrive as polished artefacts: confident timelines, recognised methodologies, named workstreams, and totals that fit the budget envelope leadership hoped for. The real risk usually sits in the assumptions, exclusions, dependencies, and appendices.
Signing without an independent read of those assumptions is how organisations inherit optimistic plans they cannot easily renegotiate once internal teams are committed, governance has approved the programme, and political capital has been spent. Before approving a major statement of work, CEOs and CFOs should know where the proposal transfers risk back to the business.
Executive summary
An SI proposal is not just a delivery plan. It is a risk allocation document. You are buying a story about certainty, while the SI is pricing uncertainty they can manage, exclude, or return later through change control.
Red flags are not reasons to reject a bidder automatically. They are prompts for questions that protect budget, delivery credibility, and executive reputation. One serious gap is enough to pause approval until the statement of work is clarified, re-cut, or competitively challenged.
The seven red flags
1. Timelines that ignore dependency reality
Single-phase programmes with parallel workstreams can look efficient on paper. They often assume third-party vendors, data owners, test environments, security teams, and business SMEs will all be ready at the same time. Ask which external parties are on the critical path and what happens to the date when they slip.
2. Milestones that sound precise but prove little
“Design complete” or “build complete” is not enough. Milestones should name deliverables the business can recognise: which processes, which sites, which integrations, which reports, which controls, and which acceptance criteria are included at each gate.
3. Integration detail deferred to later
Phrases such as “interfaces TBD”, “middleware assumed”, or “integration to be confirmed during design” are warning signs. The expensive work is rarely the connection itself. It is specifying ownership, payloads, error handling, reconciliation, monitoring, support, and exception management.
4. Data migration priced by object count only
A line item showing the number of data objects does not tell leadership whether the data is usable. If cleansing, enrichment, duplicate resolution, or ownership is described as “client responsibility”, the internal cost should be estimated before approval.
5. Testing compressed into the end of the plan
When build dominates the work breakdown structure and testing appears as a thin band near go-live, expect late discovery of process gaps, integration failures, and business readiness issues. Testing should be visible across the plan, not treated as a final inspection.
6. Change management reduced to training
Training is not adoption. A credible proposal should explain how process change, role impact, business engagement, cutover readiness, and adoption measures will be managed. If change management is a few slides and a training calendar, the business is carrying more risk than the proposal suggests.
7. Success criteria that cannot be measured at go-live
“Successful implementation” is not a measurable outcome. Leadership should expect clear acceptance criteria linked to operational readiness, process performance, business controls, data quality, integration stability, and support handover.
Practical leadership takeaway
Before signing a major SI proposal, do not ask only whether the price is affordable. Ask whether the assumptions are survivable.
Leadership teams should challenge five questions before approval:
1. What risks are explicitly included, excluded, or pushed back to the client?
2. Which dependencies could delay the programme, and who owns each one?
3. Where are integration, data, testing, and change management under-specified?
4. What would trigger change control, and how likely is that scenario?
5. What evidence will prove the programme is ready to go live?
Independent review of a statement of work typically pays for itself by surfacing one or two structural gaps before contract signature. It is far cheaper to challenge vague assumptions in the negotiation room than to discover them during delivery.