Preparing a proposal is a massive team effort, and it’s usually the case that at least some key team members—technical subject matter experts, for instance, or program managers with valuable customer insight but little proposal experience—won’t have a strong background in proposal management best practices. As a result, companies preparing proposals frequently fall into similar traps. Below, we discuss some of the most frequent mistakes, the problems they cause, and how to avoid them.

More time now means less time later. When a Proposal Manager makes a schedule for a series of document reviews, the timeline may seem arbitrary to the proposal writers. If the proposal isn’t due to the Government for three more weeks, why do we need to push so hard to get a draft ready for review by the end of this week? Writers will often request more time, and leaders are tempted to grant it—after all, the deadline is far away.

The problem is that more time now means less time later. Giving writers more time to prepare for the first review means less time to prepare for the second, for the third, for production, and so on. If companies don’t strictly adhere to the proposal schedule, more and more tasks get pushed to the end of the proposal development timeline, resulting in a last-minute scramble just to get the proposal out the door. Everyone is up late, no one is happy, and proposal quality suffers.

Emergencies do happen, and there may be situations in which such eleventh-hour efforts are unavoidable—but this should be the exception, never the rule. In a well-managed proposal, work will be distributed across the proposal development lifecycle in such a way that all-night writing sessions or panicked, all-hands-on-deck production efforts are unnecessary. To make it work, though, everyone on the team needs to understand and commit to the schedule—and resist the temptation to trade a little less stress now for a whole lot more stress later.

RFP requirements are absolute. Inexperienced proposal writers frequently want to organize proposals in the way that makes sense to them, not the way that the Government requires. Similarly, graphic designers or desktop publishers are often tempted to ignore a formatting requirement in order to make a graphic look better—Times New Roman is ugly, and really what’s the harm in using Garamond instead?

Undoubtedly, it’s possible to come up with better organizational schemes or layouts than what the RFP dictates. RFPs are often pieced together from recycled content by various authors who may not have subject matter expertise in your field. Your scheme probably is objectively better—but it’s not what the Government has asked for. If the Government can’t trust you to follow directions in the proposal, why would they trust you to do so during project execution, when mission success is at stake?

The customer, as the saying goes, is always right. It’s vital that companies treat RFP requirements as just that—requirements. No matter how ugly a required font may be, that’s the font you have to use. It may make no sense at all to discuss your Quality Assurance processes in the middle of a discussion of your proficiency in various programming languages—but if that’s where the customer thinks it should go, then that’s where it needs to be.

To ignore an RFP requirement—even if your approach really is better—is to signal to the Government that you won’t play by the rules. That gives the Government every right to throw out your proposal without reading any further—and odds are, that’s exactly what they’ll do.

Hope for the best and plan for the worst. If your proposal is due Friday, you should consider it due Thursday. Or better yet, Wednesday. That’s because things can and will go wrong: your email server will crash, or the customer’s will (and that’s still considered your responsibility), or your printer will break, or the courier will lose the package, or a storm will shut down the airport, or any number of other possible problems.

You need to plan for these contingencies and avoid creating any Single Point of Failure, that is, any one thing which, should it fail, jeopardizes the whole proposal. If you store your proposal on a remote server, for instance, what happens if the server’s network connection fails, leaving you unable to access the document? Do you have a backup copy on an on-site server? Or if you print your proposals in-house, what happens if your printer fails? Do you have a second one capable of the same task, or a trusted subcontractor who could take over production for you? And have you built enough time in the schedule to react?

There’s nothing worse than devoting your time and money to writing a winning proposal, only to be rejected for a late delivery that could’ve been avoided. Always allow for extra time, and always have a backup plan in place (“One is none and two is one,” as the adage goes). If you’re lucky, you won’t need it—but the success of your proposal is too important to trust to luck.