MediumLength Is Not Understanding. How to read an SAP proposal for what it… | by Daniil Blinov | Medium
Sitemap

Length Is Not Understanding

5 min readMar 20, 2026

--

How to read an SAP proposal for what it actually says — and what it deliberately avoids.

YouTube: https://youtube.com/shorts/OYo8zQbjegs

A 300-page proposal feels reassuring. It looks detailed and professional. The weight of it — physical or digital — signals effort, commitment, and capability. Leadership teams receive it, circulate it, and feel that due diligence is being done.

It rarely is.

Length is one of the oldest proxies for quality in vendor proposals. It is also one of the least reliable. A proposal can be long because the problem is complex and the vendor understands it deeply. Or it can be long because nobody on the vendor side made the hard choices about what to include and what to cut — and padding is easier than precision.

The question is not how much the vendor wrote. The question is whether they wrote the right things.

What long proposals hide

The relationship between length and insight is not linear. In practice, it often runs in the opposite direction. The proposals that have made me most uncomfortable are not the short ones that missed things. They are the long ones where I read 300 pages and still could not answer basic questions.

Who is responsible when the data migration fails? What happens to the timeline if business stakeholders are unavailable for two weeks? Which elements of scope are genuinely fixed and which are subject to change request? How much of this plan depends on assumptions the client has not yet validated?

These questions have nothing to do with word count. A vendor can answer all of them in twenty pages or avoid all of them in three hundred. The length is not the signal. The evasion is.

The four things that actually matter

In reviewing SAP proposals over more than two decades, the signal-to-noise ratio consistently comes down to four categories. Everything else — methodology descriptions, team CVs, reference client logos, and certification listings — is context at best and filler at worst.

  • Assumptions. Whether assumptions are explicit, numbered, and owned. Not embedded in footnotes. Not implied by phrases like “subject to” or “as discussed.” Named assumptions with named owners and stated consequences when they fail.
  • Responsibilities. Whether responsibilities are unambiguous. Not “the client will support” or “in collaboration with the business” — but a named function, a defined deliverable, and a clear handover point. Shared responsibility in a proposal usually means no responsibility in delivery.
  • Decision points. Whether decision points are identified. Every program has moments where a choice must be made that affects cost, scope, or timeline. A proposal that does not name those moments has not thought through the program. It has thought through the sales process.
  • Risks. Whether risks are real or performative. A risk register that lists “resource availability” and “change management” with a mitigation of “proactive communication” is decoration. A risk register that names the specific failure modes from comparable programmes and explains how this plan addresses them is useful.

If a proposal avoids hard topics, its length is irrelevant. Complexity explained clearly is valuable. Complexity hidden behind words is dangerous.

Short proposals that demonstrated deep insight

Some of the strongest proposals I have reviewed were short. Not thin — short. There is a difference. A thin proposal avoids depth because the vendor does not have it. A short proposal earns its brevity by having made precise choices about what the client actually needs to know.

Get Daniil Blinov’s stories in your inbox

Join Medium for free to get updates from this writer.

The markers of a genuinely insightful short proposal are consistent. The vendor has read the RFP, but more importantly they have read between the lines of the RFP — they understand what the client is worried about, not just what was asked. They name the two or three things that will determine success and explain their thinking on each. They flag the uncertainties rather than resolve them with confident language. They use specific language where others use general language.

When a vendor writes, “Based on our experience with similar programs in the Gulf energy sector, the primary risk in a migration of this type is not technical — it is the speed of master data governance decisions on the client side,” they are demonstrating insight. When a vendor writes “we will leverage our proven methodology to ensure a seamless transformation journey,” they are demonstrating fluency. These are not the same thing.

Long proposals that repeated generic text

The tell for a generic long proposal is not any individual section. It is the cumulative sense, after reading it, that you could substitute the client’s name from another proposal and nothing material would change.

Generic long proposals share structural features. They open with a capabilities section that is indistinguishable from the vendor’s website. They include a methodology section that has not been adapted to the specific programme. They have a risk register with risks that apply to every SAP implementation ever undertaken. They reference clients whose relevance is never explained. They close with a commercial section where the pricing is clear and everything that might affect the pricing is not.

None of this is accidental. Generic proposals are efficient to produce. They reuse content. They avoid the internal debates that come with taking a specific position. They do not require the senior people on the vendor side to engage deeply with the client’s actual situation. They are optimised for the sales process, not for the delivery that follows it.

The burden falls on the reader

The implication is uncomfortable but clear. You cannot wait for a proposal to demonstrate clarity. You have to create the conditions that make clarity visible — or expose its absence.

That means asking questions that cannot be answered with generic language. Not “describe your project management methodology” but “on the last two programmes of comparable complexity, what caused the first major schedule slip and how was it resolved?” Not “confirm your experience with S/4HANA migrations” but “which elements of our stated scope fall outside your standard migration playbook and how will you approach them?”

It means rewarding specificity in evaluation. A short, precise answer that names a risk and explains a mitigation should score higher than a long, confident answer that describes a process. If your scoring model cannot distinguish between them, the scoring model is the problem.

And it means reading the assumptions and exclusions with the same attention you give the executive summary. The executive summary tells you what the vendor wants you to believe. The assumptions and exclusions tell you what the vendor is protecting themselves against. The second document is more revealing than the first.

The test to apply before shortlisting

After reading any proposal, ask three questions:

  • Can I name the three things most likely to cause this programme to fail, based on what this document says? If the answer is no, the proposal has not engaged with risk.
  • Can I explain to a colleague who is not in the room what this vendor will do — and not do — for the stated price? If the answer requires the colleague to also read the document, the proposal has not achieved clarity.
  • If every assumption in this proposal fails simultaneously, what is our total exposure? If nobody has calculated that number, it has not been read carefully enough.

A proposal that cannot survive these three questions should not survive shortlisting — regardless of how many pages it contains.

#SAP #SAPS4HANA #ERPImplementation #ITLeadership #DigitalTransformation #VendorSelection #SAPLeadershipSeries

If you have any questions for me, please ask any time. Email: bdaniil@gmail.com

--

--