The award is the start of the clock
A purchase order arrives by email on a Tuesday afternoon, usually with a short note from the contracting officer and a PDF that runs from four pages to forty. The team that wrote the quote celebrates and goes back to other work. The period of performance has already started. Every deliverable date in the order is counting from a day that has already passed, and the first month decides whether the rest of the contract runs on rails or on apologies.
The work in the first thirty days is not glamorous. It is reading, scheduling, enrolling, requesting access and writing things down. None of it is optional, and almost all of it takes longer than people expect because it depends on someone else's calendar. The contractors who look effortless in month six are the ones who started every slow process in week one.
What follows is the sequence we use. It assumes a services order, such as analysis, software, research or technical review, issued by a civilian agency. The specifics shift by agency and by order type, but the shape holds.
The First Thirty Days, in Order
Days one to three: acknowledge the order and read all of it
Start by confirming receipt. If the order asks for a signed acceptance, sign and return it the same day. If it does not, reply to the contracting officer anyway: thank them, confirm you received the order, name your point of contact for contract matters, and say you will send any questions within a few days. That email establishes the channel every later contract conversation will run through.
Then read the whole document, including the parts that look like boilerplate. On a federal order the boilerplate is where the obligations live. Most clauses are incorporated by reference, which means the order lists a clause number and title and the full text sits in the regulation. Pull the full text of every clause you do not already know. A forty-clause list usually contains five or six that change how you work: the payment clause, the invoicing instructions, any clause on access to government systems or information, any privacy or records clause, the inspection and acceptance terms, and anything the agency added itself.
Agency-specific clauses deserve a slower read than the standard ones. They are where you find requirements for background investigations, security training, restrictions on where data may be stored, rules about who may publish results, and the agency's own invoicing instructions.
As you read, keep a running list of questions. Ambiguity found on day two is a short email. The same ambiguity found in month four, after the team has built the wrong thing, is a dispute about scope. Send the list to the contracting officer in one message, numbered, with the clause or section each question refers to.
Read the line items the way the finance office will
The schedule of line items is the part of the order the payment office reads, and it should be the part you read most carefully. Each line item has a number, a description, a quantity, a unit, a unit price and an amount. Your invoices will be checked against those exact fields, and an invoice that does not match is returned.
Look for four things. First, the pricing arrangement on each line: firm fixed price, labor hour or time and materials. It decides what you bill and what support you attach. Second, how each fixed-price line is meant to be billed: on delivery of a named deliverable, in monthly increments, or at the end. Third, whether every line is funded, and how much is obligated against it now; an order can carry option lines or partial funding, and you cannot bill beyond what is obligated. Fourth, whether the deliverables in the statement of work map cleanly to the line items. When they do not, raise it now, because the mismatch becomes a rejected invoice later.
Write a one-page billing map: each line item, what triggers billing, what support goes with the invoice, and the first date you expect to bill it. That page becomes the invoicing playbook for whoever on your side sends invoices.
Who does what, before anyone needs to know
The most common source of trouble on a new contract is not a technical problem. It is a well-meaning instruction from the wrong person. The contracting officer is the only government official who can change the contract: its scope, price, schedule or terms. The contracting officer's representative, the COR, is designated in writing to monitor technical performance, review deliverables and serve as the day-to-day technical contact. The COR cannot change scope, and neither can the program staff who will be in your working sessions.
| Role | Owns | Cannot do |
|---|---|---|
| Contracting officer | The contract itself: modifications, scope, price, schedule, funding, options, formal notices and final acceptance where the order assigns it | Is rarely the person who knows the technical work in detail, so relies on the COR for performance information |
| Contracting officer's representative | Technical monitoring, deliverable review, inspection and acceptance recommendations, invoice review where assigned, the working relationship | Change scope, price or schedule, authorize extra work, or direct the contractor to do anything outside the order |
| Program staff and end users | Subject matter, data, requirements detail, feedback on drafts | Give contractual direction of any kind |
| Contractor project lead | Delivery, staffing, schedule, quality, reporting, the risk log, raising issues early | Accept direction that changes scope without a modification from the contracting officer |
| Contractor contracts and finance | Invoicing, registration, clause compliance, formal correspondence with the contracting officer | Commit technical work or dates without the project lead |
Ask for a copy of the COR designation letter, or at least confirm the COR's name and the limits of their authority at the kickoff. The letter states what the COR may and may not do on this contract, and it is the document you point to, politely, when someone asks for work that is not in the order.
When a request outside scope does arrive, and it will, the answer is never a flat no and never a quiet yes. Say that it sounds useful, note that it falls outside the current statement of work, and offer to write it up so the contracting officer can decide whether to add it. Doing extra work on a verbal request feels helpful, and it leaves you with work nobody can pay for and a precedent that the scope is soft.
The kickoff is a contract meeting as much as a technical one
Request the kickoff in your first email and try to hold it within the first ten days. Invite the contracting officer and the COR. The contracting officer may decline, but invite them anyway; when they attend, decisions about interpretation get made in the room rather than through a chain of emails. Some agencies run a formal post-award orientation for larger orders. On smaller ones you are usually the one who proposes the meeting and writes the agenda.
A useful agenda fits on one page:
- Roles and contacts. Who is the COR, who on the program side answers technical questions, who on your side handles contract and invoicing matters.
- Objectives in plain terms. What decision or outcome the program office needs at the end, in its own words.
- The deliverable schedule. Every deliverable, its due date, its format and who reviews it.
- Acceptance. How drafts are reviewed, how long the government takes to comment, and what counts as accepted.
- Access and data. Which systems and datasets the team needs, the path to each, and the person who can approve it.
- Reporting and meetings. Status report format and date, standing meeting cadence, and where documents live.
- Invoicing. The system, the cadence and any agency-specific support requirements.
- Open questions. Your numbered list from the clause read, worked through one by one.
Send minutes within one business day. List every decision, every action with an owner and a date, and every question still open. Ask the COR to confirm the minutes are accurate. Minutes that nobody corrected become the shared record of what was agreed, and on a contract that record matters more than anyone's memory.
Confirm the deliverable schedule in writing
Dates in a statement of work are often written relative to something: thirty days after award, two weeks after kickoff, sixty days after receipt of data. Convert every one of those into a calendar date and send the list to the COR for confirmation. Relative dates hide disagreements. If the order says the analysis plan is due thirty days after award and the data arrives on day twenty-five, you want to have settled what that means before day thirty, not on it.
Flag dependencies explicitly. A deliverable that depends on government data, government review or government access should say so on the schedule, with the date you need the input. When the input is late, the schedule moves by agreement and in writing, through the contracting officer if the change touches the contract dates. That is not a defensive posture. It is how both sides keep an accurate picture of where the work stands.
Ask how long the government's review periods are. A draft report delivered on time and returned with comments six weeks later can push the final past the end of the period of performance if nobody planned for it. Build the review windows into the schedule you send.
Set up invoicing before the first invoice is due
The order names how you invoice. For most civilian agencies that is the Treasury's Invoice Processing Platform, or an agency system the contract identifies. Defense agencies use a different system. Whatever the order names, enrollment takes time and often requires a step from the agency, so start in the first week rather than the week the first invoice is due.
Confirm three things. Your registration in SAM.gov is active and the banking information there is current, because payment is made to the account on file. The invoicing system shows your order and its line items. Your billing map matches what the system shows. If the order appears with different line items than the PDF, tell the contracting officer immediately; it means the order was entered differently in the agency's financial system, and every invoice will fail until it is fixed.
Onboard people and request access in week one
Access to government systems is the longest pole in most first months. A contractor staff member who needs a government account, a government laptop or a building badge may need a background investigation, security and privacy training, signed rules of behavior and sometimes a personal identity verification card. Each step involves someone at the agency with their own queue.
Submit every request in the first week, for every person who will need it, even if that person does not start for a month. Track each request with its date submitted, the agency contact and the current status. When something stalls, the record lets the COR chase it with specifics. If access will not be in place before work has to start, agree with the COR on what the team can do without it, such as working with documentation, synthetic or public data, or a sandbox, so the schedule does not stop.
On your side, onboarding means more than accounts. Every person on the team should read the statement of work, the clauses that govern their behavior, the kickoff minutes and the schedule. They should know who the COR is and that no one but the contracting officer can change scope. Ten minutes on that point in week one prevents a great deal of trouble.
Put data agreements in place before anyone touches data
If the work uses agency data, the terms for using it need to be written down before the data moves. Depending on the data and the agency, that might be a data use agreement, a set of rules of behavior, a privacy review, an interconnection agreement for a system-to-system link, or simply a written statement in the order of where the data may be stored and who may see it. Data covered by privacy law, health information and anything containing personal identifiers will carry more steps and longer reviews.
Ask four questions at the kickoff. Which datasets, in what form? Where may the data be stored and processed, and does it have to stay inside a government environment? Who on the contractor side may access it? What happens to the data at the end of the contract? The answers determine your environment setup, and getting them in writing early protects both sides.
Start the slow approvals now: human subjects and the Paperwork Reduction Act
Two kinds of approval routinely take months, and both are often discovered late. If the work involves research with people, such as interviews, surveys, focus groups or the use of identifiable data about individuals, it may require review under the federal rules for the protection of human subjects. That means an institutional review board determination, sometimes the agency's own board, sometimes an exemption determination that is still a formal step.
A federal survey of ten or more people usually needs OMB clearance
Under the Paperwork Reduction Act, when a federal agency collects the same information from ten or more members of the public, including through a contractor, the collection generally needs approval from the Office of Management and Budget before it starts. The process involves public comment notices in the Federal Register and review at OMB, and it commonly takes several months. Some collections fit under an existing generic clearance the agency already holds, which is much faster. Ask the COR on day one whether any planned survey, interview guide or form is covered, and build the answer into the schedule.
Both processes are owned by the agency, not the contractor, but the contractor usually drafts much of the material: the protocol, the instrument, the burden estimate, the consent language. Offer to draft early. The schedule in the statement of work may have been written without accounting for either approval, and if so, the time to raise it with the contracting officer is week one.
The first monthly report sets the standard
Most services orders require a monthly status report. The first one sets expectations for every one after it, so make it useful rather than long. Two pages is plenty. The COR reads it to answer a simple question for their own management: is this contract on track, and is there anything I need to do?
A good first report covers work completed against the schedule, work planned for the next month, deliverables submitted and their review status, hours or costs against the funded amount where the order is labor hour or time and materials, open risks and issues, and anything the contractor needs from the government with a date. That last item is the one that earns its place. A report that says "we need read access to the claims extract by the 12th to hold the analysis plan date" gives the COR something specific to act on.
Open the risk log on the first day
A risk log is a simple table: the risk, its likelihood and impact, its owner, the response, and the date it was last reviewed. It earns its keep in month two, when you can show the COR that the data delay was flagged on day eight with a proposed workaround. Without the log, the same delay reads as a surprise.
Seed it with the risks you already know about on day one: access timelines, data availability, approvals that depend on other offices, staff onboarding, government review windows and any ambiguity left open after the kickoff. Review it weekly with your team and monthly with the COR. Close risks when they are resolved, and keep the closed ones in the log; they are the record of what was handled.
Where you should be on day thirty
By the end of the first month, the contract should be running on its own routines. Use this list as the day-thirty test.
- Order acknowledged and every clause read, including the full text of clauses incorporated by reference
- Questions sent to the contracting officer and answered in writing
- Kickoff held, minutes sent and confirmed by the COR
- COR named, with their authority limits understood by everyone on the team
- Every deliverable on a calendar date, with government dependencies and review windows shown
- Billing map written; invoicing system enrollment done and line items matching the order
- Access requests submitted for every person, with status tracked
- Data terms in writing before any data moved
- Human-subjects and Paperwork Reduction Act questions answered, and any approvals started
- Risk log open and reviewed; first monthly report and first invoice delivered
If every line is checked, the next eleven months are about the work. If several are open, they will compete with the work for attention, and the work usually loses.
Frequently asked questions
No. Only the contracting officer can change the contract, including its scope, price, schedule or terms. The COR monitors technical performance and reviews deliverables. When a COR or program staff member asks for something outside the order, write it up and route it to the contracting officer for a decision before doing the work.
Confirm roles and contacts, restate the objectives, walk the deliverable schedule and acceptance process, list the systems and data the team needs, agree on reporting and meeting cadence, confirm invoicing, and work through open questions. Send minutes within one business day and ask the COR to confirm them.
On the date the order states, which is often the award date itself rather than the kickoff date. Read the order to confirm, and convert every relative deadline in the statement of work into a calendar date counted from that start.
If the survey is conducted for a federal agency and asks the same questions of ten or more members of the public, it generally does, even when a contractor runs it. Some collections fall under a generic clearance the agency already holds. Ask the COR early, because full clearance commonly takes months.