Who Owns What? Understanding the People Behind a Government Contract

One of the easiest mistakes to make in Government Contracting is thinking a contract belongs to the Contracts department.

It doesn't.

Successful contract performance can involve Contracts, the Program Manager, Program/Project Control, Accounting, Billing, HR, Procurement, Security, technical personnel, executive leadership, and several different people on the Government side. Even in a small business where one person may wear several of those hats, the responsibilities still exist.

The challenge isn't usually figuring out everyone's job title. It's understanding where responsibilities overlap, who needs what information, and when someone else needs to be brought into the conversation.

Over the years, two simple questions have saved me a lot of headaches:

Who needs to know this? Who does this impact?

Those questions matter because some of the biggest contract problems don't happen neatly inside one department. They happen in the spaces between them.

The Program Manager: What's Actually Happening?

The Program Manager is typically closest to execution. The PM knows what the team is doing, whether the work is progressing, what the customer needs, where staffing is struggling, whether milestones are being met, and what may interfere with successful performance.

That makes the PM an incredibly important source of information for everyone else supporting the contract.

It can also create risk.

Good PMs are problem solvers. When the customer asks for something, their natural instinct is often, “Sure, we can do that.”

Sometimes they absolutely can.

Other times, that little request affects scope, staffing, schedule, cost, funding, deliverables, or another contractual requirement. The PM doesn't need to become a Contracts expert, but they do need to recognize when a seemingly operational decision may have contractual implications.

My favorite PMs weren't the ones who never had contract issues. They were the ones who called before the little issue became a big one.

Contracts: What Did We Actually Agree To?

Contracts should understand the agreement between the company and the Government: what was promised, what is required, what has changed, what notices are required, and what the company is contractually obligated and authorized to do.

Contracts should also help the program distinguish between a customer request and contractual direction.

That doesn't mean Contracts should be the Department of No.

A good Contracts function helps the business accomplish what it needs to accomplish within the terms of the contract while protecting the company from unnecessary risk.

The earlier Contracts knows what's happening, the more options everyone usually has.

Finding out after the work was performed, the commitment was made, the deadline was missed, or the customer was promised something makes that job considerably harder.

Program/Project Control: What Are the Numbers Telling Us?

If Contracts understands what we agreed to do, Program/Project Control should understand what is happening financially while we're doing it.

PC should be watching budgets, actual costs, funding, staffing, forecasts, revenue, profit, and the other indicators that tell us whether the project is performing according to plan.

That puts PC in a unique position.

A PM may know the project is understaffed. PC sees what that is doing to the forecast.

Contracts may know additional funding was received. PC sees how long that funding is expected to last.

Accounting may know what costs have posted. PC sees whether those costs make sense compared with the budget and remaining work.

None of those functions has the complete picture by itself.

Contracts and PC Should Be Best Friends

I spent a significant portion of my career in Program/Project Control before moving into Contracts leadership, so I've had the benefit of seeing this relationship from both sides.

And I cannot overstate how important it is.

Contracts receives a funding modification? PC needs to know.

PC forecasts that funding may run short earlier than expected? Contracts needs to know.

Contracts learns that the customer is considering a change? PC may need to evaluate the financial impact.

PC notices that actual performance is significantly different from the assumptions used to price the work? The PM needs to understand why, and Contracts may need to know if there are contractual implications.

These aren't separate conversations.

If Contracts and PC only start talking when there's a problem, they're talking too late.

Accounting and Billing: What Actually Hit the Books—and What Are We Charging the Customer?

Accounting and Billing aren't downstream departments that everyone else can simply hand things to after decisions have already been made.

They need information too.

A modification may change billing requirements. New funding may require project setup changes. A new CLIN may need to be established correctly. A subcontractor can affect Accounts Payable. A rejected invoice may reveal a misunderstanding about how the contract is supposed to bill.

And the information needs to travel in both directions.

PC can't manage a project effectively without accurate actual costs. Contracts needs to know when an invoice rejection suggests a contractual interpretation problem. PMs need to understand when operational decisions are creating financial consequences.

Sometimes the first indication that something went wrong upstream appears in Accounting.

Don't shoot the messenger. Ask why the number looks weird. 😂

HR, Procurement, Security and Everyone Else We Remember Five Minutes Too Late

The core contract team isn't the only group affected by contract decisions.

Hiring someone may involve labor-category qualifications, work-location restrictions, security requirements, compensation considerations, funding, and the project budget.

Adding a subcontractor may involve Procurement, Contracts, PC, Accounting, Security, Small Business requirements, consent requirements, flowdowns, and other considerations.

Travel can involve contract terms, funding, company policy, Government approvals, billing requirements, and allowability.

Not every decision needs a twelve-person committee meeting. Please don't create one because of this blog. 😂

The point is simply to recognize when a decision that appears to belong to one department has consequences somewhere else.

“The Government” Isn't One Person Either

The contractor isn't the only organization with multiple stakeholders.

Depending on your contract, you may interact with a Contracting Officer, Contract Specialist, Contracting Officer's Representative (COR), Government Program Manager, technical monitors or technical points of contact, end users, finance personnel, property personnel, and others.

You may speak with some of them every day. You may have an excellent working relationship with them. You may even refer to one of them simply as “the customer.”

They do not all have the same authority.

That distinction matters.

The Contracting Officer

The Contracting Officer is the Government official with authority to enter into, administer, and/or terminate contracts and make related determinations and findings within the limits of their authority.

For the contractor, the practical lesson is straightforward: know who your Contracting Officer is and understand when something requires CO involvement.

The COR and Other Government Representatives

A COR may have delegated responsibilities involving technical monitoring, deliverables, surveillance, coordination, or other aspects of performance. Government PMs and technical personnel may work even more closely with your team.

But working closely with the contractor does not automatically give someone authority to change the contract.

That's why one sentence should make every Contracts person ask a follow-up question:

“The Government told us to do it.”

Okay.

Who at the Government?

If someone is asking for additional work, changing a requirement, affecting schedule, directing resources, or doing something else that could affect the contract, knowing who made the request and what authority they have is important.

Being helpful to your customer is a good thing.

Performing work based on an assumption about someone's authority can become a very expensive way to be helpful.

The Real Problems Happen Between the Boxes

You can create the most beautiful responsibility matrix in the world and still have poor contract management.

Why?

Because the problems usually aren't sitting neatly inside the box labeled “Contracts” or “Program Management.”

They happen between the boxes.

The Government PM asks your PM for something that sounds like a minor change. Does Contracts know?

PC sees that funding is going to run short before the remaining work is complete. Do the PM and Contracts know?

Contracts receives a modification changing funding or requirements. Does PC know? Does Accounting? Does Billing?

A new employee starts charging to the project. Does PC know? Has someone verified the appropriate labor category and contractual requirements?

A subcontractor invoice arrives substantially higher than forecast. Does Accounting simply pay it, or does someone ask what happened?

The answer to every situation isn't “call Contracts.”

The answer is to understand who owns each piece of the issue and who else may be affected by it.

Beware of Surely

There's another member of the contract team who causes more communication problems than almost anyone else.

Surely.

Surely Contracts told the PM.

Surely the PM told PC.

Surely PC told Accounting.

Surely someone told Billing.

Surely HR knows.

And then three weeks later, everyone is sitting in a meeting discovering that nobody actually told anybody.

Assumptions are not a communication plan.

Before you move on from something important, ask:

Who needs to know this? Who does this impact?

Then tell them.

When in Doubt, I'm on Team Overshare

No, that doesn't mean copying 47 people on every email. Nobody deserves that inbox.

It means I'd rather receive information I already know than discover weeks later that everyone assumed someone else had told me.

Strong contract management isn't created by one exceptional Contracts Manager, PM, PC analyst, or Controller. It happens when the people responsible for different pieces of the contract understand how their work connects and communicate early enough to actually do something with the information.

Know your stakeholders. Understand their roles. Understand their authority. Know where responsibilities overlap.

And whenever something changes, make those two questions a habit:

Who needs to know this? Who does this impact?

Because “I thought someone told them” is a terrible way to find out that nobody did.