Why Your Incrementally Funded Program Keeps Missing Milestones

The probability is high that no one will say this to you directly, so we will.

Your program isn't missing milestones because the team is slow. It's missing milestones because of systemic issues, not personnel issues. Especially if your funding is arriving in chunks too small to sustain continuous progress. Because there is a high likelihood your schedule was built as if that wasn't going to happen.

That's not your team's failure. That's system problem… an architecture failure. And it was baked in before the first task order was signed.

How Incremental Funding Actually Works in Practice

In theory, incremental funding is a budgeting mechanism. The government obligates money in pieces as it becomes available, rather than all at once at contract award. Makes sense from an appropriations standpoint. The problem is that the schedule (and the performance expectations attached to it) doesn't adjust to reflect how the money actually arrives.

So, here's what happens in practice:

Funding arrives. Work accelerates. The team makes real progress. Then funding runs out before the next increment is authorized. Work slows or stops. The team shifts to other things, or just waits. Three weeks later the next increment arrives and the team has to rebuild momentum — context has been lost, threads have been dropped, and the schedule clock kept running the entire time.

Repeat this cycle four or five times over the course of a year and you have a program that looks chronically behind, a team that looks like it can't execute, and a contracting officer who is frustrated that milestones keep slipping.

Nobody in that picture is wrong, exactly. But nobody is naming the actual cause either.

What The Contracting Office Won't Tell You

The funding gaps are a known variable on their end. They understand the appropriations cycle. They know when increments are likely to be authorized. What they often don't do is connect that knowledge to your schedule in any explicit way — because that would require acknowledging that the schedule as written isn't executable given the funding pattern as planned.

That's an uncomfortable conversation. So, it usually doesn't happen!

What happens instead is that your program gets evaluated against a schedule that was built assuming continuous funding, while operating on funding that is anything but continuous. The gaps are invisible in the performance data because nobody coded them as funding gaps — they just show up as slippage.

And slippage, in most government programs, gets attributed to the contractor.

What You Can Do About It

You can't control when funding arrives. But you can control how your program is structured to absorb the gaps — and how clearly you're documenting the relationship between funding events and schedule performance.

Try to build funding contingencies into the schedule explicitly. Every increment authorization is a schedule event. Treat it that way. When an increment is delayed by two weeks, the schedule impact of that delay should be visible, documented, and communicated — not absorbed silently and blamed on execution later.

Work to establish a clear record of work authorization dates versus schedule baseline. If your contract says a milestone is due on a specific date and the funding that enables that milestone didn't arrive until three weeks before — that's not a missed milestone, that's a schedule that needed to be adjusted. Document it at the time, not after the fact.

Push to have the funding conversation with your prime and your KO/COR at program kickoff, not after the first gap. Ask directly: what is the anticipated funding profile? How does that align with the schedule? What is the process for adjusting the schedule if funding is delayed? Getting those answers on record changes the dynamic when gaps inevitably happen.

Incremental funding isn't going away. It's structural to how the government spends money and there's nothing you can do about that.

What you can do is stop building programs as if it isn't happening — and stop accepting schedule evaluations that don't account for it.

Your program isn't behind. Your schedule just wasn't built for the reality it was going to operate in.

That's fixable. But only if someone is willing to say it out loud.

‍ ‍

At Leitwolf, we help technical teams build the right structure for the environment they're actually operating in — not the idealized version. If your program keeps slipping for reasons that feel outside your control, let's talk.

‍ ‍

You Didn’t Ask for It. That’s Not the Point.

Think about the last time you sat across from a doctor, an accountant, or a lawyer.

Did you hand them a checklist? Did you specify every standard they were expected to meet or every protection you were expecting them to apply? Because you are a normal human, we’ll just assume that you trusted them to do their job in the way a normal human would... Not blindly — but reasonably. Because the entire basis of that type of relationship is that the person providing the service knows things you don’t, and that their level of professional knowledge comes with an obligation to act in your interest.

Nobody tells their doctor “please wash your hands before you examine me.” The doctor just does it because it is good for his/her patient. Nobody tells their accountant “don’t share my financial records.” The accountant just protects their clients information to prevent strangers from getting it. Those things don’t get stated because they don’t need to be stated. They are so fundamental to the relationship that requiring them to be explicitly requested would be absurd.

That is what an implied requirement looks like when it works.

The question worth asking is what it looks like when it doesn’t.

When the Knowledge Gap Becomes a Shield

In technical program work, there is a defense that shows up with uncomfortable regularity. It sounds like this: “You didn’t ask for that.”

This stunning gem of professional failure is typically deployed at delivery time (a.k.a. the end of the project). When the gap between what was needed and what was built becomes impossible to ignore or hide in performance metrics. And it is technically true often enough to be very dangerous. The EXACT requirement wasn’t written down. It wasn’t in the contract. It wasn’t specified in language that could be pointed to.

What this BS argument leaves out is the reason WHY it wasn’t specified. The person who needed it didn’t have the technical knowledge to specify it in the first place. They came to a specialist. They trusted that the specialist would apply their expertise in the interest of the person they were serving, not just to the exact boundary of what was written down.

They trusted the implied requirement that you would build it the way that it should be built. Using that knowledge gap as a contractual defense is not a neutral act. It is a betrayal of the relationship that created the gap in the first place.

A doctor who says “you didn’t ask me to wash my hands” is not making a legal argument. They’re admitting they understood they had an obligation and chose not to honor it. The excuse doesn’t save them. It condemns them.

The same logic applies to all these types of situations. It just gets applied less consistently outside of medicine and law.

Security Is Where This Cuts Deepest

Of all the places implied requirements live, security is a field where the consequences of not meeting them are the most serious.

The person commissioning a system (any kind of a government program, a procurement, a contracted capability) often does not have the technical depth to specify every security control they need. That is not negligence. That is the nature of the problem. Security is complex, evolving, and deeply specialized. The entire reason you bring in experts is because you cannot navigate it alone. So, the person commissioning the work has a valid expectation of professionalism from the technical experts they hire!

When those ‘security’ experts deliver a system without encryption, without access controls, without audit logging, without the protections that any reasonable person would assume were included, they are not just defending their delivery… When they point to the requirements document and say: ‘it wasn’t specified’, they aren’t making a false claim ‘legally’ speaking... What they are doing is exposing the gap between what they were hired to do and what they chose to do.

The person who bought the house didn’t ask for locks. They assumed locks. Because a house without locks is not a house. It is a structure that fails at one of its most fundamental purposes. A system without security is the same thing. It is a capability that fails the moment it encounters the condition it was built to operate in.

And unlike a poorly specified feature that wastes budget and frustrates users, a security gap does not stay contained. It exposes data. It enables breaches. It causes harm to people who had no part in the requirements conversation and no ability to protect themselves from its outcome.

The stakes are not abstract. The knowledge gap is not theoretical. And the “you didn’t ask” defense, in a security context, is not a contractual position. It’s a confession.

What Professional Obligation Actually Means

Medicine codified this a long time ago. Informed consent. Do no harm. Finance/financial advising did too, using terms like fiduciary duty. These are not aspirational statements. They are enforceable obligations that exist precisely because the knowledge gap between specialist and client is real, significant, and consequential. And because supposed experts didn’t voluntarily meet those expectations.

They exist because the bodies who govern and regulate those fields recognized that leaving the implied requirements to chance produced outcomes that were indefensible. So, the obligations were made explicit. The professional is required to act in the client’s interest even when the client doesn’t know enough to demand it.

Technical program work, and security specifically, has not fully made that turn. Current contractual models still allow the knowledge gap to be treated as the client’s problem. If you didn’t write it down, you didn’t ask for it. If you didn’t ask for it, you don’t get it. If something goes wrong because of what wasn’t specified, that’s a requirements failure, not a delivery failure.

That model protects the wrong party.

The specialist has the knowledge. The specialist has the expertise to know what should have been in the requirements even when the client didn’t. The specialist took on the work knowing that gap existed. The obligation to close it — or at minimum to surface it explicitly rather than silently benefit from it — sits with the person who understood what was missing.

Implied requirements are not a loophole. They are a test of whether the expertise being sold is actually being applied in the interests of the person/people who needed it.

The Question That Has to Be Asked

Every program, at every stage, involves people who know more than the people they are serving. That asymmetry is not a problem. It is the point. It is why expertise was brought in.

What matters is what that asymmetry obligates.

Before delivery, someone with technical depth needs to be asking: what did this customer need that they didn’t know to ask for? What have we assumed they understood that they almost certainly didn’t? What gaps exist between what was specified and what is actually required for this thing to work safely, securely, and in the interest of the people it was built to serve?

Those questions are not scope creep. They are professional responsibility. And depending on the customers and/or products involved, could literally be a matter of life or death.

The customer hired you because the subject matter was too complex to navigate alone. They trusted that the expertise they were paying for would be applied in their interest — not just to the edges of what they were able to articulate.

The knowledge gap is the reason they hired you.

It was never meant to be a defense.

At Leitwolf, we treat implied requirements as real requirements — because the people we serve are counting on us to know what they couldn’t have known to ask for. If that’s the kind of partnership your program needs, let’s talk! Contact us: info@leitwolf.net

Good Intentions Don’t Translate to Good Outcomes

Most programs don’t fail because of bad people. They fail because of good people with unchecked ideas.

The requirements were written with care. The reviews happened. The working groups met. Everyone was trying to do the right thing. And somewhere between the original need and the final delivery, the thing stopped being about the person who needed it and started being about the process surrounding it.

That’s not a cynical observation. It’s a structural one. And until you see the structure clearly, you can’t fix it.

The Good Idea Fairy

There is a character that shows up in nearly every program that goes sideways. They don’t have a formal role in the org chart necessarily, but they are the chief cause of the drift – The Good Idea Fairies... They’re not malicious. In fact, they almost always actually want to help. They’re usually senior enough to be heard and removed enough from the front line to have stopped feeling the problem directly.

They arrive with a suggestion.

“What if it were multi-purpose?”

“Could we make it more flexible?”

“Shouldn’t it be adaptive?”

Those are not requirements. They are aspirations wearing the clothes of requirements. And in a regulated environment — government, defense, healthcare — each one of those words is a like a trigger.

The moment “multi-purpose” enters the requirements document, the program is no longer solving the original problem. It is now also anticipating every other problem it might conceivably be asked to solve. Safety has to assess the new contexts. Security has to expand the threat surface. Testing has to cover the additional use cases. Documentation has to cover the testing. Training has to cover the documentation. Governance has to oversee all of it.

None of those functions/disciplines are wrong to respond the way they do. Every regulated discipline is doing exactly what it is supposed to do. The cascade is feature, not a flaw. It is working as designed.

The actual failure occurred one step earlier… when nobody stopped to think. When no one asked the Good Idea Fairy a simple question: what problem on the front line are you actually solving with ‘multi-purpose’?

More often than not, the answer is none. But the suggestion sounds better. It feels more defensible. It gives the impression of forward thinking. One word. In one meeting with the wrong audience and without a single follow-up question. Now the program just got six months longer and end product becomes considerably harder to use.

The Person Who Needed It

Before the beginning of every single program in existence, if you look back far enough, there is a person… This person has an actual problem. The problem they have is usually specific and observable. (It is also inevitably far less complicated than what eventually gets built to address it.) This also is the person who gets stuck with that complicated and barely useful ‘multi-functional’ product that falls out of the other end.

That person, usually called an end-user, is consulted at the start. Their input goes into a document. The document gets approved. And then, almost without exception, the program stops talking to them. The end user is an afterthought until the program wants to roll out their shiny, flexible solution.

In between the initial ask and final reveal, a lot of things happen. Decisions get made about what they probably need. For them, not with them. Constraints get applied based on what is assumed about their environment. Assumed because once again, no one thinks to ask… We have to go fast, right? Features get added because someone, somewhere, decided they would be useful and make it more ‘multi-functional’ that the first ‘multi-function’ that was added. None of those people involved are the person with the problem.

They are interpreting, translating, and augmenting — through their own lens, with their own priorities, at increasing distance from the original need.

By the time delivery happens, the gap between what was needed and what was built can be enormous. Not because anyone failed at their job. Because the job everyone was doing had quietly shifted from solving the problem to managing the program.

The person with the problem is still there!! The one who needed a solution. They’ve been there the whole time. They adapted. They found a workaround. They got on with things. They didn’t file a change request because the system made that part hard and their need didn’t wait!

When the delivery finally arrives, they look at it and they recognize almost nothing of what they originally asked for. And they are not wrong. They take the ‘multi-function’ turd and throw it on a shelf or in a trashcan, and use their improvised solution.

Good Intentions Are Not Enough

The instinct to make something more ‘capable’, more ‘flexible’, more ‘future-proof’ is not a bad instinct. In isolation, almost every addition that gets made to a program is defensible. The additional functions mean it can handle more situations. The compliance requirement protects everyone involved.  But ‘defensible’ good intentions are not the same as actual requirements. Those solve actual problems held by real people.

The problem is not any individual decision. It is the accumulation of decisions made without returning to the original question: does this still serve the person we built it for?

That question stops being asked early in most programs. Not because people are negligent. Because the process doesn’t require it. Requirements are locked. Scope is defined. The program moves into execution and the feedback loop between what is being built and what is actually needed gets longer and longer until it effectively doesn’t exist.

By the final delivery, the program has answered a hundred questions that nobody asked and has not answered the one that started the whole thing.

What the Structure Has to Require

The fix is not a better requirements template. It is not another review gate or a more detailed approval process. Those are the mechanisms that got us here.

The fix is a standing obligation to return to the original person, with the original question, at every point where the program changes direction. Not a user representative appointed by management. The actual person who will use the thing, on the day it matters, under the conditions it was built for.

Before any new features get added, someone needs to be able to answer: who asked for this, and have we confirmed with the end user that it serves them?

Before any constraint gets applied, someone needs to ask: have we told the user what this means for them, and do they still get what they needed?

Those conversations are uncomfortable because people assume they surface disagreement or slow certain decisions down. And those do happen. But what they actually do is prevent the much larger cost of discovering at delivery that the thing you built is not the thing that was needed.

The most expensive outcome in any program is a faithfully executed wrong requirement. Everything that follows building the wrong thing expertly costs more than the conversation that could have prevented it. Thing like the rework, the delay, the loss of confidence, the capability gap that persisted while the program ran, and so on.

Good intentions matter. They are necessary. They are not sufficient.

What has to be asked, at every stage, is not just “are we doing this right?” It’s “Are we doing this right?” AND “Is this still the right thing to do for the person who needed it in the first place?”

If you can’t answer both of those questions, the program is running for itself (not the person you think).

At Leitwolf, keeping the original need in frame — and the original user in the room — is foundational to how we work. If your program has drifted or you want to make sure it won’t, let’s talk! Contact us: info@leitwolf.net