The date is fixed: the start of an academic year, an institution's opening or a programme launch. Now you need a supplier willing to meet it. Before asking for that promise, map the work on both sides.
A supplier can build a form, but it needs approved fields. It can migrate content, but someone must identify the current material. Writing a date into a document does not remove those dependencies.
Work backwards from launch
List launch, final checks, fixes, acceptance, testing, implementation and scope preparation. Add the points where data, access or decisions are required. Allow separately for arranging the purchase itself.
Some activities can overlap, but confirm that with the people doing the work. Parallel activity helps only when teams are not building on conflicting assumptions.
Give each decision an owner
“Client approval” is too broad. Who approves content, who approves design and who checks system behaviour? Will those people be available at the right time? Who resolves conflicting feedback?
Reserve time for editors and test users as well. One demonstration meeting does not replace checking how their own tasks work in the system. If reviewers are busy elsewhere, the schedule needs to reflect that reality.
Ask what makes the deadline achievable
Instead of only asking “can you finish in time?”, ask: “What must we provide, and by when, for this schedule to work?” Request a clear view of the activities whose delay would move the launch date.
If the plan does not fit, discuss a smaller first release, earlier preparation of materials or a different date. An explicit scope decision is more useful than a schedule that has quietly removed all time for fixes and acceptance.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database