A proposal scheduler needs more than the solicitation due date at kickoff. The scheduler needs the controlled request for proposal (RFP), schedule-related instructions, evaluation criteria, scope structure, contractual dates, technical assumptions, resource inputs, external dependencies and proposal review calendar.
The goal is to leave kickoff with enough information to build a compliant schedule architecture and a credible development plan. The proposal scheduler should also know who owns each missing input and when it must arrive. Without that foundation, the first schedule draft often becomes a collection of unsupported dates rather than an executable plan.
Proposal scheduler kickoff checklist
Use the following checklist before the kickoff meeting ends. Some items may not exist yet. However, every missing item should have an owner, required date and documented assumption.
- The complete RFP and all amendments received to date
- A controlled list of solicitation documents and attachments
- Section L proposal instructions or their equivalent
- Section M evaluation factors or their equivalent
- Statement of Work (SOW), Performance Work Statement (PWS) or Statement of Objectives (SOO)
- Contract Work Breakdown Structure (CWBS) and WBS dictionary, if provided
- Contract Line Item Number (CLIN) structure
- Contract Data Requirements List (CDRL) and Data Item Descriptions (DIDs)
- Required schedule format, software version, page limits and electronic submission rules
- Contract period of performance and required delivery dates
- Technical reviews, test events, decision points and customer approvals
- Government-furnished property, equipment, information and facilities
- Subcontractor, supplier and teammate scope
- Proposal technical approach and major make-or-buy assumptions
- Basis-of-estimate owners and resource assumptions
- Known risks, opportunities and schedule uncertainty
- Cost-volume and pricing-calendar interfaces
- Color-team review dates and proposal production deadlines
- Schedule file owner, configuration location and change process
- Open-question log with owners and due dates
1. Start with the controlled solicitation package
The scheduler should receive the complete RFP, not selected excerpts copied into an email. Establish a controlled index that identifies each document, revision date and amendment number. Then confirm which person maintains the authoritative proposal library.
Under the uniform contract format described in Federal Acquisition Regulation (FAR) 15.204, schedule information may appear across several sections. For example, Section B can define CLINs, Section C can contain the work statement, Section F can establish deliveries or performance dates, and Section J can contain attachments. Meanwhile, Section L provides proposal instructions and Section M identifies evaluation factors.
Not every solicitation uses that format. Commercial acquisitions, agency-specific solicitations and specially tailored RFPs may organize the information differently. Therefore, search the entire package for terms such as schedule, IMS, milestone, delivery, period of performance, critical path, risk and calendar.
Also establish an amendment process immediately. FAR 15.206 addresses solicitation amendments when the Government changes requirements or terms. The proposal team should assess every amendment for changes to dates, scope, deliverables, assumptions and submission instructions. A scheduler who works from an outdated attachment can invalidate days of planning.
2. Separate mandatory instructions from useful practices
A proposal integrated master schedule (IMS) is not a universal FAR deliverable. The solicitation must establish what the offeror has to submit. Requirements can vary by agency, acquisition strategy, contract type and program tailoring.
At kickoff, label each schedule expectation as one of the following:
- Explicit requirement: The solicitation directs the offeror to provide it.
- Evaluated content: The Government will assess it under an evaluation factor or subfactor.
- Proposal-team requirement: Internal leadership wants it to support solution development or pricing.
- Scheduling best practice: The item improves credibility but the RFP does not require it.
- Open interpretation: The team needs a formal question or documented assumption.
This distinction prevents the team from treating an internal convention as a contractual rule. It also keeps the schedule focused on what the customer requested. FAR 15.305 states that agencies evaluate competitive proposals solely against the factors and subfactors specified in the solicitation. Therefore, the scheduler should map schedule content to both the instructions and the evaluation criteria.
Build a schedule compliance matrix
Create a focused compliance matrix for every schedule-related requirement. At a minimum, record the RFP reference, requirement text, planned response location, schedule implementation, owner and status.
For example, Section L may require a native schedule file, a PDF milestone view and a narrative explaining the critical path. Section M may evaluate the realism of the proposed approach. Delivering the files satisfies the instruction, but the underlying logic, durations and assumptions must also support the evaluated claim.
3. Obtain the scope architecture before adding activities
The scheduler needs to understand how the proposal team intends to organize the work. Ask for the customer WBS, proposed contractor WBS, work statement, CLIN structure and product architecture. If the team has not established them, identify the decision owners and required completion dates.
The schedule should not become the unofficial location where unresolved scope is hidden. Instead, it should expose gaps between products, work scope, organizations and contractual commitments. The GAO Schedule Assessment Guide treats scope capture and WBS alignment as foundations of a reliable schedule.
For a practical explanation of that relationship, see how the WBS connects to the Statement of Work. If the proposal team is starting directly from solicitation documents, the process in building an IMS from an RFP provides the next level of detail.
4. Identify every date that can shape the network
Collect more than the contract start and finish dates. The proposal scheduler should identify all customer dates, proposed dates and planning boundaries that may affect the schedule network.
- Anticipated award and authorization-to-proceed dates
- Base and option periods
- Incremental funding assumptions when relevant
- Required delivery dates
- CDRL initial and recurring submissions
- Government review and approval periods
- Technical reviews and test windows
- Site access or facility availability dates
- Government-furnished equipment need dates
- Long-lead procurement dates
- Transition-in and transition-out periods
Document the source for each date. Also distinguish a required date from a team forecast or estimating assumption. If the period of performance appears inconsistent with required deliveries, raise the issue before the schedule absorbs the conflict. The discussion in how contract period of performance affects the IMS explains why those boundaries require careful treatment.
5. Get the technical execution story from the right people
The scheduler should not invent the technical approach. Instead, facilitate planning sessions with engineering, manufacturing, software, test, logistics, supply chain and program management. Each lead should explain the work sequence, entry criteria, exit criteria, dependencies, duration basis and responsible organization.
Ask direct questions:
- What product or decision does this activity produce?
- What must be complete before the work can start?
- What evidence shows that the activity is complete?
- Which customer action or external delivery can delay it?
- What resource or facility limits the duration?
- Which downstream event does this work support?
The DAU Integrated Master Plan and Integrated Master Schedule Preparation and Use Guide discusses using the IMP and IMS to represent program events, accomplishments, criteria, tasks and interfaces. Treat that document as guidance unless the solicitation incorporates specific requirements.
Confirm review and approval assumptions
Technical reviews need more than milestone symbols. Determine the preparation work, entrance criteria, review duration, action-item closure and approval logic. For example, a Critical Design Review (CDR) may depend on completed analyses, released drawings and customer-furnished inputs.
Do not assume standard review timing without technical-team agreement. If the proposed program includes System Requirements Review (SRR), Preliminary Design Review (PDR), CDR or test-readiness events, use the definitions in the guide to major technical reviews as a starting point, then tailor the network to the proposed solution.
6. Establish duration, resource and calendar ground rules
A kickoff schedule can begin with planning estimates. However, those estimates need owners and a path to validation. Define who provides durations, labor categories, staffing levels, productivity assumptions, material lead times and subcontractor dates.
Also decide which calendars the schedule will use. Identify working days, holidays, shifts, facility shutdowns and customer calendars. A five-day engineering calendar may not suit manufacturing, field installation or round-the-clock test operations.
If cost or Earned Value Management System (EVMS) integration applies, the scheduler also needs the proposed WBS, Organizational Breakdown Structure (OBS), control-account strategy, accounting periods and cost-volume calendar. The proposal schedule should support pricing rather than develop independently from it. See schedule-to-cost integration for the key handoffs.
7. Expose external dependencies and schedule risk
External dependencies often drive proposal schedules more than internal logic does. Ask specifically about Government-furnished equipment (GFE), customer approvals, security clearances, test ranges, permits, supplier deliveries, teammate data and predecessor contracts.
For each dependency, record the provider, need date, promised date, schedule treatment and contingency. Do not convert every uncertain delivery into a fixed constraint. Where possible, model the predecessor event and connect it to the dependent work.
Next, request the proposal risk register and align schedule assumptions with it. Determine which risks affect activity durations, logic, resource availability or event dates. If the team plans a schedule risk analysis, agree on uncertainty ranges, correlation assumptions, risk-event mapping and required outputs before building the model.
For GFE-specific planning considerations, see Government-furnished equipment and schedule risk.
8. Define proposal production and schedule review rules
The scheduler needs an internal delivery calendar as well as a contract execution schedule. Establish dates for the first logic network, initial critical-path review, pricing handoff, narrative freeze, color-team reviews, final validation and production submission.
Also define the review criteria. For example, the team may check missing logic, high durations, excessive constraints, leads, lags, negative float, duplicate names, inconsistent calendars and broken WBS coding. These are quality-control practices, not automatic solicitation requirements.
Finally, assign one person to control the native schedule file. Use version naming, a change log and a known storage location. Proposal teams lose traceability when several planners edit independent copies and later attempt to merge them.
Fictional kickoff example
Consider a fictional radar modernization proposal with a 36-month period of performance. The RFP requires a native IMS, a milestone PDF and a schedule narrative. It also provides a customer WBS, 18 CDRLs and Government-furnished test equipment scheduled to arrive in month 14.
At kickoff, the proposal scheduler discovers that the technical volume assumes qualification testing in month 13. The pricing team also plans test-labor costs in months 12 through 15. Rather than entering the equipment delivery as a hard date and moving on, the scheduler records the conflict, assigns the test lead to validate the sequence and asks contracts whether the GFE date needs clarification.
The team then revises the approach. It schedules test planning and procedure development before GFE delivery, places equipment checkout after delivery and moves qualification testing to month 16. As a result, the technical narrative, resource plan, risk register and pricing model now describe the same execution strategy.
What the scheduler should leave kickoff with
A productive kickoff produces decisions and assigned actions, not just meeting notes. Before closing, confirm that the proposal scheduler has:
- A controlled solicitation index and amendment process
- A schedule compliance and evaluation matrix
- An agreed preliminary WBS and coding structure
- A list of required dates and their sources
- Named planning leads for each major scope area
- Duration, resource and calendar ground rules
- An external-dependency and assumption log
- A risk-analysis approach, if required or planned
- Cost and schedule integration milestones
- A schedule development, review and freeze calendar
- An action register for every missing input
The scheduler does not need every activity defined on day one. However, the team must agree on the rules, inputs, ownership and deadlines that will produce a compliant schedule. That discipline turns proposal scheduling into execution planning rather than last-minute graphics production.
Frequently asked questions
Should the proposal scheduler wait for the technical approach to stabilize?
No. The scheduler should begin with the known scope, dates and interfaces while tracking open assumptions. Early schedule development often reveals gaps in the technical approach. However, the scheduler should not silently resolve those gaps without the responsible technical lead.
Does every government proposal require an IMS?
No. The applicable solicitation determines whether an IMS, milestone schedule, narrative or native file is required. Internal management may still request a schedule to validate the execution plan, but that does not make it a contractual submission requirement.
How detailed should the first proposal schedule be?
Use enough detail to demonstrate the proposed sequence, interfaces, major products, reviews, deliveries and schedule drivers. The appropriate level depends on the RFP, program complexity and proposal maturity. Avoid adding detail that the team cannot support with scope, logic or duration assumptions.