Building a Tender Preparation Schedule That Survives Reality

Most tender schedules fail for the same reason project schedules fail: they are built forward from today instead of backward from the deadline. A team starts with good intentions, works through the scope, then discovers on the final two days that the guarantee needs a bank approval, the director is travelling, the printer cannot bind the document and the courier cut-off has passed.

A working tender schedule starts with the submission time and works backward through every dependency. It names owners, defines review gates, and protects a buffer that is large enough to absorb a real problem. This article sets out the method and a 21-day worked example.

Start From the Deadline, Not From Today

The closing date in the tender data is a hard constraint. Everything else is movable. Write the deadline at the top of the schedule, then place the fixed events that cannot move:

• Compulsory briefing or site inspection date.
• Question cut-off and the date clarification answers are expected.
• Any sample submission date.
• The bank's cut-off for a guarantee or confirmation letter.
• The printer and courier cut-off for a physical submission.
• The portal upload cut-off for an electronic submission.

Once those are fixed, schedule the work backwards. The final internal deadline should be at least 24 hours before the official deadline, and 48 hours for a large or physical submission.

"

The Work Breakdown

The workstreams are not sequential. Compliance and technical can run in parallel; pricing depends on the technical scope; legal depends on the commercial structure; submission depends on everything. The schedule must show those dependencies explicitly.

Working Days Versus Calendar Days

South African public holidays and weekends can remove a third of the available days from a short bid window. A schedule that counts calendar days will be wrong. Count working days, then mark the public holidays and any known leave.

1. Count the calendar days from document download to closing.
2. Remove weekends and public holidays.
3. Remove any team leave or travel already booked.
4. Reserve at least 20% of the remaining working days as buffer.
5. Recheck the calculation against the official closing time, not only the date.

The Tenders-SA preparation planner

calculates working days and key dates, and the existing guide to the preparation planner

explains its inputs. Use it as the arithmetic layer, then build the dependency plan around it.

The Review Gates

A schedule without gates is a list of tasks. Gates force a decision: proceed, fix or stop.

G1 is the most important gate. A team that proceeds on a bid it cannot win has already lost the time it could have spent on a better opportunity. The existing guide to why bids get disqualified

explains the administrative gate, and the guide to quality assurance and review

explains the final QA.

A 21-Day Worked Schedule

Assume a tender closes at 11:00 on day 21. The team has one bid lead, one compliance officer, one technical writer, one pricing analyst and one reviewer. There is a compulsory briefing on day 3 and a question cut-off on day 6.

The schedule deliberately submits on day 20, not day 21. That buffer absorbs a courier delay, a signature problem or a portal failure. If everything goes smoothly, the team has a day to respond to an unexpected clarification.

Protecting the Buffer

Buffers disappear when they are treated as free time. Protect them with three rules:

• Do not schedule work into the buffer. If a task slips, escalate; do not silently borrow the buffer.
• Make the buffer visible. Show it on the schedule so the team knows it is intentional.
• Use the earliest possible submission. Submitting on day 20 is better than submitting on day 21 at 10:58.

The Dependencies That Usually Slip

Team Roles and Hand-Offs

A schedule only works if each workstream has one accountable owner. Shared ownership usually means no ownership. Define the hand-offs explicitly:

1. The bid lead owns the schedule, the gates and the submission decision.
2. Compliance owns the returnable matrix and the evidence pack.
3. Technical owns the methodology, scope response and CVs.
4. Commercial owns the pricing schedule and margin sign-off.
5. The reviewer owns independent QA and has the authority to stop submission.
6. The bid administrator owns formatting, signatures, copies and proof of submission.

The application workspace

can hold the schedule, documents and status, and the companion article on managing tender submissions as a team

explains the operating rhythm. For a broader view of the preparation process, see quality assurance and review

.

Common Scheduling Mistakes

• Planning forward. Starting from today always produces a late finish.
• Counting calendar days. Weekends and public holidays are not working time.
• No buffer. A schedule with no slack is a schedule that fails on the first surprise.
• No owner per task. Tasks without an owner are not scheduled; they are hoped for.
• Reviewing at the end. QA on the final day cannot fix a missing certificate.
• Submitting at the last minute. The last hour is when portals fail and printers jam.

The Bid Calendar Entry

Every tender should create one calendar entry with the full set of dates, not just the closing date. A closing date alone hides the briefing, the question cut-off, the sample deadline and the internal gates.

Set reminders for the day before each gate, not only on the gate. A reminder at 16:00 the day before gives the owner time to prepare; a reminder at the gate is already late.

When the Deadline Moves

Deadlines can change through an addendum, a clarification or a buyer extension. The schedule must treat a change as a formal event, not as good news.

1. Confirm the change in writing through the official channel.
2. Re-baseline the schedule from the new deadline, including the buffer.
3. Check whether the change affects any other requirement, such as a briefing or sample date.
4. Tell the whole team, not only the bid lead.
5. Do not relax the internal deadline simply because the external one moved; use the extra time for quality, not delay.

A moved deadline can be a trap. A team that treats an extension as permission to start later often ends up with the same last-minute scramble, plus a false sense of security. Re-baseline, then protect the new buffer.

Treat the schedule as a living document. Update it at every gate, record why a date moved and keep the history. A schedule that is revised silently is not a control; a schedule with a visible change log is how a team learns where its estimates are weak and which dependencies consistently slip.

The schedule also protects the team's non-bid work. A bid that consumes every hour for two weeks damages delivery on live contracts. Planning the bid properly makes the cost visible and lets the team decide whether the opportunity is worth the disruption.

Conclusion: A Schedule Is a Risk Control

A tender schedule is not administrative decoration. It is the control that prevents a good bid from being lost to a preventable failure. Build it backwards, make dependencies visible, put a named owner on every task, and protect the buffer.

For your next bid, start with the closing time and work backward through the six gates. Use the preparation planner

for the working-day maths, then put the plan into the application workspace

so the team works from one schedule, not five versions.