The Crumblestones Of Acquisition: Faulty Requirements Handoff (Part 5)

The Tragedy of the Requirements Handoff

Serialized from Contracting for Rapid Acquisition: A Practical and Personal Guide to Disrupting the Status Quo for a More Responsive Future
By Lorna E. Tedder

Of all the Crumblestones, faulty requirements handoffs might be the most tragic because they’re easily preventable but rarely prevented. In my personal experience, it’s the most prevalent failure after a poor Contracting Culture and definitely contributes to an entrenched and disagreeable culture.

It’s also the source of much of the hostility between Program Managers (PMs) and Contracting Officers, and one of the reasons “it’s Contracting’s fault” when lead times span years instead of months. Contracting Officers get blamed for a contract award being late when they’ve either just received what they need from the Program Manager to get started or they’ve had to rewrite the documents themselves after multiple sloppy attempts from the Program Manager. They give up, knowing that if the promised award date slips, they’ll be blamed. Contracting can be slow, yes, but it’s rarely all their fault. When they get stuck taking all the blame, they’re likely to cross their arms over their chests and not go out of their way to make life easier for their technical counterparts. Since it’s often the first interaction between a Contracting Officer and a Program Manager, it can set the stage for an awful working relationship.

Welcome to the Faulty Requirements Handoff: where promising efforts stall out not because the mission wasn’t worth doing, but because the transfer of workload to Contracting broke down.

And Contracting will end up being blamed because few outsiders understand the difference between the roles and responsibilities of Contracting versus the roles and responsibilities of Acquisition. The caboose gets blamed for the train being late.

The Last-Minute Lob: How It Really Plays Out

A brutal truth: during my 30-plus years as a Contracting Officer, I worked with over a thousand Program Managers, and of the ones who gave me a usable requirements package the first time around so that I could get started on the work I was responsible for, I can count them on one hand. After all these years, I can still name them, but most came from early in my career, which tells me that this problem has gotten worse.

Here’s how it typically plays out. A Program Manager (PM) takes 16 to 18 months to gather funding, define the need in a way that industry will understand, and pull together a requirements package. Then—often near fiscal year-end—they lob the requirements package over the fence to Contracting with a note that reads, “Expiring funds! Need awarded by 30 September!” Often, it’s the first time the Contracting Officer has even heard of the requirements, so they haven’t been able to plan ahead for which of their buyers will either be qualified or have time to work this unexpected requirements package into their end-of-year planning. If it’s classified, it’s an even bigger problem because not just anyone on their team can work it, and if it’s Top Secret, they may have only one overworked Contracting Officer with the right clearances.

But the Program Manager is adamant. They need it yesterday. Plus, the funds expire at the end of September. Why, they ask, are you being so difficult, and what do you mean it can’t be awarded in two weeks because laws and regulations dictate how long industry has to respond?

That’s when the Contracting Officer starts to look over the requirements package and sees that it’s taken 10 months to write the Statement of Work or Performance Work Statement—and it’s full of problems that mean it needs to be rewritten by someone with technical knowledge, not business knowledge. For some reason, the most common prep time in my personal experience ran 16 to 18 months, and most of that time, I didn’t even know it was coming so that I could check in on it. I could certainly help write it or rewrite it, even though it wasn’t my job, but did they really want an English major writing their technical requirements?

But 10 months? 18? Where’s it been all this time?

Granted, AI tools should help this recurring glitch, but someone still has to take the time and effort to create the document and ensure the AI output is accurate. That should be the Program Manager, not the Contracting Officer with a non-technical degree. I cringe to think that Program Managers will take AI output and drop it into the requirements package for Contracting without even reading it and expect the Contracting Officer to check it and fix any errors for them. This is why tools alone aren’t enough to fix this Crumblestone.

But I can hear it already: “We don’t need to make sure it’s right before we lob it over the fence to Contracting—AI will fix it for us.” Eventually, probably, but for right now, a human still needs to provide input to whatever AI tools you’re using to create that package. This is why I used to give my Program Managers a checklist to make sure they gave me a complete package and so they knew exactly what I needed from them for me to get started. This was a huge help for both of us, but one or two actually checked the boxes while omitting the documents they checked off.

What Happens When the Package Is Shoddy

Back to how this usually plays out.

So now the Contracting Officer is facing a very short timeline to get everything done that they are required by law or by regulation to do. In other words, they have no control over part of their timelines. They may also not have the right staffing for the incoming workload. They start reviewing the package and quickly discover that it’s shoddy—full of errors that can’t go out to industry—or it’s a partial package—missing things that the Contracting Officer needs to send it to industry or to award the contract.

The Unspoken Politics of Package Acceptance

Here’s the dilemma: does the Contracting Officer “accept” the package or send it back? Once they accept the package, even if it’s partial or needs a 90% revision, it becomes their problem now, their timeline. Plus, it’s off the PM’s desk, and the urgency to provide the complete package drops. This is when the chain of command hears “It’s with Contracting,” not “I sent a couple of documents to Contracting, but they can’t get that Request for Proposal out until I get them more technical information.” Even when the promised missing pieces don’t show up on time, Contracting is still getting hammered for not awarding on time.

I can’t tell you how many people I’ve upset by not staying quiet. Many Contracting Officers are trained not to complain or cause a fuss if they don’t have what they need to do their jobs, rather than embarrass a PM who told the General, “It’s with Contracting,” because they dropped it on my desk after close of business on a Friday, and at oh-eight-hundred on Monday, the General wants to know why I haven’t awarded it yet. To all my bosses’ chagrin, I refused to play that game.

It was always fun to get a call direct from my General in July, wanting to know why a contract hadn’t been awarded yet and reminding me that he was being held accountable for getting the award made before October. Anything after July meant the money might get pulled and sent to another contract that could be awarded on time. When I explained that I hadn’t seen anything yet from the PM, the full package always—always—showed up on my desk by the time I walked in the next morning. Funny how that works!

It’s not just a matter of a timely package, though. Even if it’s timely, it needs to be complete. Sending it back for correction is allowed, but in practice, it seldom works out well for Contracting.

Why Sending It Back Rarely Works

I remember the first time, as a young Contracting Officer, GS-12, when I complained to my boss that I had a requirements package on my desk that still had the name of another contractor in it, references to other technologies, and inconsistencies with security classifications. They had literally grabbed a Statement of Work from a similar contract and changed the title, but nothing else. I would have been embarrassed to turn in work that shoddy, but my Program Manager told me I could fix the problems if I needed to.

“If the document gets attached to the contract, isn’t fixing it your job?” and “Anything that goes into the official contract folder is the Contracting Officer’s job.”

My boss told me to tell my Program Manager that I was allowed to return the package with a request to bring it up to par and that no, it was his responsibility to give me usable technical documents that would become part of the contract. I relayed the message to my Program Manager, who merely shrugged. I guess he knew something I didn’t.

I returned the package with a letter that requested he make the changes, specifically technical information no one else had. Within 24 hours, his technical Colonel was yelling at my contracting Colonel, and within another 30 minutes, that contracting Colonel was yelling at my boss and me. Yes, we were allowed to return the package, but doing so was an act of war between our functional silos.

That hasn’t improved over the years.

I’ve spoken with Contracting Officers across many organizations, and it’s routine to hear that they return a package five times before giving up and accepting it. Each time they return the package, more time is lost. If they’ve accepted the package and the lead time ball is in their court, they are flagged as being slow and missing deadlines. If they haven’t accepted the package, they’re still watching their time to get on contract shrink.

The Hidden Timeline Almost No One Tracks

Because we tend to track the contract lead time from the time to get from requirements package to award or, depending on where you are, the time from solicitation to award, the focus is on how fast the Contracting Officer is moving. We do not tend to track how long it takes to get a complete, usable package to the Contracting Officer so they can perform their part in the acquisition process.

What we’ve managed to do in recent years is to train PMs that they don’t need to fix everything because Contracting will eventually give up on asking and do the best they can with what they know about the requirement and hope for the best. This is appalling but spoken of quietly as if the shame for this is the Contracting Officer’s. Even having seen shoddy packages for years myself, I still find it surprising how common this situation is, and especially how many times a package is returned as insufficient before giving up because “they’re never going to fix it in time anyway.” There’s no incentive for it to be corrected before being sent to Contracting, so it ends up being more workload for Contracting and for people who usually don’t have the technical expertise to know if the technical language being used to describe the need is adequate to attract the right solutions from industry.

Triage by Deadline: End-of-Year Strategies

One way Contracting tries to accommodate is by refusing to accept requirements packages after a certain date in the summer, whether that’s 60 days before the fiscal year end or four months before. Depending on the complexity of the procurement, it may take much longer than 60 days or four months. This helps to plan for workload management in the last quarter of the fiscal year and allows for enough time to fix what’s not ready to go on contract.

Contracting Officers often scramble to fix what they were never part of building. They try to make up for 18 months of delay in 30 days. They rework the strategy, rewrite documents, chase signatures, and answer questions from cost/price analysts, legal counsel, procurement analysts, and reviewers who should’ve been brought in months earlier. And when things inevitably slow down?

It’s Contracting’s fault.

Except it’s not. Or it is. But really—it’s all of our fault.

We’re All in This Together

Here’s my take on this lingering problem: it’s Contracting’s fault, and it’s not Contracting’s fault. Most of all, it’s not just Contracting’s fault.

We’re all in this together. And we have to fix it together.

That means each of us owning our piece. Fixing our own issues first. Then fixing them together. Then scaling those fixes beyond our individual teams to the broader acquisition community.

This problem won’t solve itself. It certainly won’t go away if we keep pretending it’s someone else’s job. And if you think AI will magically fix it all, then we have to be at the point where humans aren’t making any decisions. That may come or may not, but in 2025, we’re not there yet.

A Better Way: Early Conversations That Work

When the requirements package is finalized without input from Contracting, the whole strategy can go sideways. Sometimes, the PM’s plan is convoluted, unworkable, or overcomplicated—when a five-minute conversation weeks earlier could have saved months of effort. I’ve personally had five-minute conversations that each saved over a year of effort on the part of multiple full-time employees, not including our contractors.

A key lesson learned from an early conversation—yes, this overlaps with the Communications Crumblestone—is the many times I could have helped a PM leverage an existing contract, modify one already under negotiation, or use a different authority entirely. Instead of launching a full-blown source selection, they could’ve tapped into an IDIQ or a contracting vehicle I was days away from finalizing. But I didn’t know about their need. And they didn’t know I could help.

It doesn’t take a formal team-wide workshop. It doesn’t need a full-day meeting. Walk me to my car or to my next in-person meeting and tell me what you need. I’ll ask a few questions—like about funding, the customer, security requirements, and if there’s competition—and tell you in five minutes if there’s a faster, better way to get it.

I know some Contracting Officers who say they don’t have time for a meeting on something that might or might not end up on their desks. I hear PMs say they don’t even know who their Contracting Officer will be. Those early conversations do not need to take a lot of time, and it’s true that the likely Contracting Officer for the effort may change by the time the package is completed and ready to hand off, but a quick discussion with a Contracting supervisor or manager might be enough to lead to a faster strategy without all the extra work.

Here’s a helpful tip:

Contracting Officers, when you’re talking to your PMs and team, whether you’re a Contracting Officer for one huge program or a gazillion small contracts, ask what’s coming. If it’s June, ask your PM if there’s anything they might need by fiscal year-end that you don’t know about. Because if they do, they need to be sending you some information right away. Even if it’s just a possibility, you can keep it in the back of your mind as to how to handle staffing and workload, or you might need to know about something on the horizon so you can bump up the ceiling on a contract you’re trying to award in September that this PM might not know about.

Bonus tip: Once you know for certain that a requirement is coming to you, consider giving a heads-up to your procurement analysts and legal counsel so they can also manage their time and accommodate you in an end-of-year crunch. Just as Contracting Officers are held to a certain number of days to make an award and then get surprised with 10 projects at once in the same time frame, so do your policy and legal reviewers. They may have 3 or 5 days to complete a review, but that number is based on doing only that review, not 4 in the same week—which happens when no one plans ahead.

Program Managers and teams, loop in your Contracting Officer before you lock in your strategy.

You don’t need perfect documents in that first communication. You don’t need a day-long discussion. You need a conversation, and then you can go from there.

When a Five-Minute Walk Saves Five Months

Whether these tips seem obvious or impossible, I can tell you from experience: they work. Once my PMs understood what I needed from them in order to help them, we cut out a significant amount of wasted time.

If they couldn’t get on my overstuffed calendar, they’d walk me to my car—770 steps to the parking lot. By the time I opened my door, I had a heads-up on what was coming, and they had a better sense of how to start shaping their strategy.

Conversations like that turned both of us into rapid acquisition heroes. We’d realize the work was in scope of an existing contract or a solicitation already in the works—and suddenly, there was no need to start from scratch. No new source selection. No wasted months.

Just shared information. Shared planning. Shared success.

Why the Handoff Breaks

I’ve had some very idealistic contracting professionals tell me that I shouldn’t call it a “handoff” but a “handshake.” I love the idealism, and it’s something to aim for. Unfortunately, for now, it’s rarely a handshake. Let’s call that our goal, but we have to understand what’s broken so we can fix it.

This isn’t just about one broken step in the process. The root causes run deeper:

• Internal political pressure on Contracting Officers to accept incomplete packages, even when they know it’s setting everyone up for failure.
• Lack of early engagement, which means Contracting Officers are left to fix downstream what could have been prevented upstream.
• No system-level tracking from the time a need is identified to the point the package is ready to work. This is tracked in a few places by people trying to find where the disconnect is, but it’s not widespread or consistent.
• Misaligned incentives—because saying “no” to a flawed package isn’t rewarded, but making the deadline at any cost is.
• The myth of the clean handoff. Acquisition isn’t a relay race. It’s a team effort. You don’t just pass the baton and walk away. Hence, it really shouldn’t be a handoff, but a handshake.

Tracking the Right Things

One of the biggest enablers for improvement? Visibility.

If leadership started tracking not just how long Contracting takes from package receipt to award—but how long it took the package to become complete and acceptable in the first place—we’d see patterns emerge.

We’d see how many cycles it takes to get it right, where the bottlenecks are, who’s struggling to meet standards, and who’s quietly fixing other people’s work under pressure, without credit.

No one really wants to say, “Hey, I’m sending this back to you for the fifth time. Will you pretty please fix the technical stuff in Paragraph 4? And yes, I CC’d your entire chain of command in a last-ditch effort to avoid having to make this up myself.”

Leadership doesn’t need to micromanage, but they do need to monitor. Because when people know their packages are being tracked and evaluated for quality—not just speed—they tend to step up their game. You don’t need to issue another memo; just count what matters.

Bottom Line: Don’t Lob It. Collaborate. (And Follow Through!)

The Faulty Requirements Handoff isn’t just a procedural issue; it’s a visibility issue. Most of all, it’s a shared accountability issue that overlaps with the Culture and Communications Crumblestones.

If we want to move faster—and smarter—we need to stop treating Contracting like the cleanup crew. We need to treat them like strategic partners from the start.

That means early conversations, transparent tracking, shared responsibility, and a lot more walking-to-the-next-meeting moments.

The next time you’re tempted to hit send on a last-minute package and mark your part “complete,” ask yourself: Is it complete? Or am I just hoping someone else will fix it on their watch? Can I smartly prompt improvements to it with my Government-approved AI tools?

If it’s not ready, don’t lob it. Collaborate.

Tools, including AI, may bolster the Requirements Handoff Crumblestone, but it’s probably going to be relationship-building between Contracting Officers and Program Managers that has the biggest impact. After that, it’s the mindset to not take the easy way out in the hand-off. AI is just a tool—though a fabulous one—but for the foreseeable future, you still need more than just a tool.

So don’t lob it: collaborate—and then you must follow through.

Next up: Crumblestone #5—Lack of Appropriate Tracking Systems.
Because if you can’t measure it, you can’t manage it—and you definitely can’t fix it.