I once spent the better part of a week on a proposal that ran to sixty-odd pages. Architecture diagrams, an assumptions log, a risk register, the lot. I was rather proud of it. The decision was made off the two-page summary at the front, which I'd written last and fastest, in the time I had left.
That stung enough to teach me something. The person who signs is not the person who reads the appendix. Senior decision-makers don't have a document problem, they have a time problem. They will give your proposal the attention it takes to answer three questions. What is this. Why should I believe you can do it. What does it cost me, in money and in risk.
Everything else in the document exists to survive scrutiny once those three are answered. It matters. The technical reviewer will go through it line by line and they should. But it isn't what wins the room. The summary wins the room, or loses it, and most of us spend our best hours on the part fewer people read.
The discipline I try to keep now is to write the one page they'll actually read as if it's the only page. Plain language. The outcome before the architecture. The number in clear view rather than buried where it looks like I'm hoping nobody finds it. If I can't make the case in a page, the longer version usually isn't strong, it's just longer.
The thick proposal is often a comfort blanket. It feels like effort, so it feels like value. The buyer is quietly measuring something else: can these people make a complicated thing simple. The proposal is the first proof, one way or the other.
Respect the reader's time and they tend to return the favour with theirs.