4 hours ago, brabus said:

I get it from the company perspective. But, also there are some significant portions of industry that can eat a big bag of dicks (and the gov to, to be fair). The taxpayers getting fucked because company X can’t (or doesn’t try hard enough) to meet their promises of capabilities on timeline has to end (F-35 is a great example). Maybe the middle ground is fixed-price, but with carve outs for things out of the company’s control - black swan event, unobtanium REM price goes above X value, etc. @ClearedHot You appear fairly deep in industry: what are your thoughts from that perspective AND as a taxpayer?

Maybe the government actually needs to figure out what requirements they want by, I dunno, talking to operators and maintainers who fly and work on aircraft? Stop letting retard aquitition officers and civilians throw bullshit in RFI/RFPs, then get pissy when it's almost impossible to keep a timeline due to moving or impossible requirements. This is coming from someone who worked on the KC-46 contract, drafting contract change proposals, engineering change proposals, basis of estimates, responding to RFI/RFP/PCOLs, and currently works on the F-16 program.

4 hours ago, Sua Sponte said:

talking to operators and maintainers who fly and work

No way, not possible. Some acquisitions LT knows better.

I am fully retired now, but throughout my career, I generally preferred Firm-Fixed-Price (FFP) contracts for everything except situations like this.

With FFP contracts, I was driven to find efficiencies that could increase profitability. Improvements in manufacturing efficiency, supply chain management, engineering processes, and labor productivity directly improve margins.

The problem arises when the government has shifting priorities and requirements, as it did with the T-7. The program is a perfect example of how winning a competitive FFP development contract is not necessarily the same thing as winning a profitable program.

The Air Force made three significant changes to the T-7 program and, in my view, attempted to push much of the associated cost onto Boeing. I suspect SNC is concerned the Navy will do something similar.

1. Expanded pilot accommodation requirements

The Air Force expanded the required pilot accommodation range, primarily affecting the crew escape system. At contract award, the requirements were based substantially on a 1967 male pilot survey. Two years after the award, the Air Force changed the requirement to accommodate the central 95% of the U.S. recruiting population, including women weighing as little as 103 pounds.

This was a significant and expensive engineering change to the aircraft.

2. Evolving training performance requirements

The training performance requirements were not fully defined at the outset. To its credit, the Air Force wanted a platform that was not simply a replacement for the T-38, but a better training aid for fourth- and fifth-generation aircraft.

Initial testing revealed that the aircraft did not meet the sustained-G performance metrics and exhibited significant wing rock at high angles of attack (AOA).

The Air Force offered to pay the increased engineering costs to address these issues, but those costs were not fully burdened, and Boeing lost significant money implementing some of the fixes. Ultimately, the Air Force lowered some of the performance requirements.

3. Changes to the procurement strategy

When a company bids on a contract, particularly an FFP contract, much of the anticipated profit comes in the out-years as production ramps up.

If you slip the schedule by a year and reduce the number of aircraft purchased each year, the financial impact on the vendor can be devastating.

Based on the original schedule, Boeing purchased many long-lead items in advance to reduce costs and meet delivery requirements. When the Air Force changed the procurement strategy, Boeing was left holding the bag on much of that supply chain commitment.

From a taxpayer perspective, FFP contracts are generally a good thing. You budget for a capability and spend within that budget unless you change the requirements.

They also incentivize companies to invest their own money in Independent Research and Development (IR&D), which drives innovation throughout the U.S. defense industry.

The situation under Trump has been different because the government injected significant amounts of money into defense programs all at once. Prior to that, the Department of Defense was increasingly asking industry to assume all the risk, only to occasionally cancel programs after companies had invested tens or even hundreds of millions of dollars in development.

The Light Attack program is a perfect example. The Air Force spent relatively little while promising to purchase hundreds of aircraft, a commitment that never materialized.

I know several CEOs who went to the Pentagon after that and a few other similar incidents and essentially said, "We won't play this game again." Justifiably so. They have a fiduciary responsibility to their shareholders.

I know of two occasions when my former company flat-out said, "NO THANKS" when the Air Force asked us to bid on something. The service was incredulous, and the Secretary of the Air Force eventually engaged our CEO directly. His response was essentially: Either you fund the development upfront or give us a contract. If not, adios.

I highly suspect that was the same calculus SNC used in making its decision.

37 minutes ago, ClearedHot said:

Either you fund the development upfront or give us a contract. If not, adios.

I highly suspect that was the same calculus SNC used in making its decision.

It does seem like the competition boiled down to the Navy asking the vendors to take on too much risk for a fixed firm price contract.

It's been a long time since Acquisition 101, but isn't this why you have a "Technology Maturation and Risk Reduction" (TMRR) phase? In aircraft development, isn't this the point where you fund a handful of companies to do development, burn down risk, build prototypes, then do a fly-off? Announce the winner, and move on to Engineering and Manufacturing Development (EMD)?

It seems like in this case, the Navy wants to skip the TMRR phase, and go straight to EMD. Which would work, if there wasn't so much risk still baked into their requirements.

I speculate because the Navy (like the AF) wants a new trainer, but they want to do it on the cheap.

Edited yesterday at 01:26 PM1 day by Blue

48 minutes ago, Blue said:

I speculate because the Navy (like the AF) wants a new trainer, but they want to do it on the cheap.

The old acquisition adage, we all fly into combat in platforms built by the lowest bidder...

Contractors usually make a good portion of their profit with contract modifications (e.g., KC-46 RVS 2.0). Even then, it’s usually only 8-12% profit, in my experience.

12 hours ago, ClearedHot said:

I am fully retired now, but throughout my career, I generally preferred Firm-Fixed-Price (FFP) contracts for everything except situations like this.

With FFP contracts, I was driven to find efficiencies that could increase profitability. Improvements in manufacturing efficiency, supply chain management, engineering processes, and labor productivity directly improve margins.

The problem arises when the government has shifting priorities and requirements, as it did with the T-7. The program is a perfect example of how winning a competitive FFP development contract is not necessarily the same thing as winning a profitable program.

The Air Force made three significant changes to the T-7 program and, in my view, attempted to push much of the associated cost onto Boeing. I suspect SNC is concerned the Navy will do something similar.

1. Expanded pilot accommodation requirements

The Air Force expanded the required pilot accommodation range, primarily affecting the crew escape system. At contract award, the requirements were based substantially on a 1967 male pilot survey. Two years after the award, the Air Force changed the requirement to accommodate the central 95% of the U.S. recruiting population, including women weighing as little as 103 pounds.

This was a significant and expensive engineering change to the aircraft.

2. Evolving training performance requirements

The training performance requirements were not fully defined at the outset. To its credit, the Air Force wanted a platform that was not simply a replacement for the T-38, but a better training aid for fourth- and fifth-generation aircraft.

Initial testing revealed that the aircraft did not meet the sustained-G performance metrics and exhibited significant wing rock at high angles of attack (AOA).

The Air Force offered to pay the increased engineering costs to address these issues, but those costs were not fully burdened, and Boeing lost significant money implementing some of the fixes. Ultimately, the Air Force lowered some of the performance requirements.

3. Changes to the procurement strategy

When a company bids on a contract, particularly an FFP contract, much of the anticipated profit comes in the out-years as production ramps up.

If you slip the schedule by a year and reduce the number of aircraft purchased each year, the financial impact on the vendor can be devastating.

Based on the original schedule, Boeing purchased many long-lead items in advance to reduce costs and meet delivery requirements. When the Air Force changed the procurement strategy, Boeing was left holding the bag on much of that supply chain commitment.

From a taxpayer perspective, FFP contracts are generally a good thing. You budget for a capability and spend within that budget unless you change the requirements.

They also incentivize companies to invest their own money in Independent Research and Development (IR&D), which drives innovation throughout the U.S. defense industry.

The situation under Trump has been different because the government injected significant amounts of money into defense programs all at once. Prior to that, the Department of Defense was increasingly asking industry to assume all the risk, only to occasionally cancel programs after companies had invested tens or even hundreds of millions of dollars in development.

The Light Attack program is a perfect example. The Air Force spent relatively little while promising to purchase hundreds of aircraft, a commitment that never materialized.

I know several CEOs who went to the Pentagon after that and a few other similar incidents and essentially said, "We won't play this game again." Justifiably so. They have a fiduciary responsibility to their shareholders.

I know of two occasions when my former company flat-out said, "NO THANKS" when the Air Force asked us to bid on something. The service was incredulous, and the Secretary of the Air Force eventually engaged our CEO directly. His response was essentially: Either you fund the development upfront or give us a contract. If not, adios.

I highly suspect that was the same calculus SNC used in making its decision.

I gotta ask how did the contractor get into this deal without seeing this?

Fickle indecisiveness of the government especially after the requirement changes that screwed up the KC-46?

How are the vendors not self protecting or putting contractual language in the deals guaranteeing full compensation for said changes?

Edited 19 hours ago19 hr by Clark Griswold

12 hours ago, Clark Griswold said:

I gotta ask how did the contractor get into this deal without seeing this?

Fickle indecisiveness of the government especially after the requirement changes that screwed up the KC-46?

How are the vendors not self protecting or putting contractual language in the deals guaranteeing full compensation for said changes?

Have you heard of a thing called the U.S. Government? They ALWAYS change the rules...

1 hour ago, ClearedHot said:

Have you heard of a thing called the U.S. Government? They ALWAYS change the rules...

That’s true but what I’m asking is how could Boeing not see this coming in the T7 and not sign unless they were protected from the good idea fairy / staff guy’s last minute change whose cost is gonna be sent to them.

As a private company they can say no, counter their offer or propose a totally different deal. Maybe that’s naive but I’d rather be that than in a deal where I lose money because my customer is acting like Vader

Edited 7 hours ago7 hr by Clark Griswold

4 minutes ago, Clark Griswold said:

That’s true but what I’m asking is how could Boeing not see this coming in the T7 and not sign unless they were protected from the good idea fairy / staff guy’s last minute change whose cost is gonna be sent to them.

As a private company they can say no, counter their offer or propose a totally different deal. Maybe that’s naive but I’d rather be that than in a deal where I lose money because my customer is acting like Vader

Again, I don't think you understand the U.S. government and their willingness to change the rules of the game. As a Senior VP I had lawyers, former government contracting officers and industry experts parsing every bit of language in every contract. We were still at the whims of the government...they ALWAYS reserve the right to cancel the contract so companies are usually on their heals.

The really sad part, the government PMs are largely terrible...they would not be employable elsewhere. Let me share an example...I need to slightly change it so as not to give away names and such.

I was working a project to integrate munitions and sensor capabilities on some high-end aircraft. The company was state of the art with some of the best programmers in the business...doing crazy cool things with software and sensors. We were using a software process called "Agile", which has been around for a number of years and is VASTLY superior to the way programming was done in the past (Waterfall). Under the old system (Waterfall), if you were building a program to accomplish a task you would start at the beginning and work sequentially through the task to write the program.

Years ago some smart programmers decided on a new method that breaks the project into chunks and assigns levels of difficulty to each stage. Then they focus on the stages that are hardest to complete and assign a lot of energy to run sprints to develop and complete those tasks. There is an agreement that each segment has an agreed upon input scheme and out put scheme (Interface Control Document - ICD). As long as everyone sticks to the ICD you can develop individual modules very efficiently.

We were 1/3 of the way into a project and the government sent a large team to do a milestone review. They did not grasp and had never heard of Agile (despite our briefing when we bid the project). Several hours into the review they wanted to talk to me and the senior leadership team in private. The point blank told us they were going to cancel the project because we were so far behind...we had not even completed the first block of the program.

It took several hours standing at a whiteboard AGAIN describing AGILE and exactly where we were. Of course we did not complete the first block...turning the program on and getting to a start menu was the easiest thing in the project, we had been focuses on cursor on target mensurated three digit coordinates while blending multiple sensors. They put on us on "probation" and we provided weekly reviews...Much to their surprise we ended up delivering the project SIX months EARLY, BELOW cost and with ZERO defects. I can;t stress enough how impressive it is to have zero defects....the power of AGILE.

I can give you COUNTLESS other examples...it is a FUBAR'd mess.

14 minutes ago, ClearedHot said:

Again, I don't think you understand the U.S. government and their willingness to change the rules of the game. As a Senior VP I had lawyers, former government contracting officers and industry experts parsing every bit of language in every contract. We were still at the whims of the government...they ALWAYS reserve the right to cancel the contract so companies are usually on their heals.

The really sad part, the government PMs are largely terrible...they would not be employable elsewhere. Let me share an example...I need to slightly change it so as not to give away names and such.

I was working a project to integrate munitions and sensor capabilities on some high-end aircraft. The company was state of the art with some of the best programmers in the business...doing crazy cool things with software and sensors. We were using a software process called "Agile", which has been around for a number of years and is VASTLY superior to the way programming was done in the past (Waterfall). Under the old system (Waterfall), if you were building a program to accomplish a task you would start at the beginning and work sequentially through the task to write the program.

Years ago some smart programmers decided on a new method that breaks the project into chunks and assigns levels of difficulty to each stage. Then they focus on the stages that are hardest to complete and assign a lot of energy to run sprints to develop and complete those tasks. There is an agreement that each segment has an agreed upon input scheme and out put scheme (Interface Control Document - ICD). As long as everyone sticks to the ICD you can develop individual modules very efficiently.

We were 1/3 of the way into a project and the government sent a large team to do a milestone review. They did not grasp and had never heard of Agile (despite our briefing when we bid the project). Several hours into the review they wanted to talk to me and the senior leadership team in private. The point blank told us they were going to cancel the project because we were so far behind...we had not even completed the first block of the program.

It took several hours standing at a whiteboard AGAIN describing AGILE and exactly where we were. Of course we did not complete the first block...turning the program on and getting to a start menu was the easiest thing in the project, we had been focuses on cursor on target mensurated three digit coordinates while blending multiple sensors. They put on us on "probation" and we provided weekly reviews...Much to their surprise we ended up delivering the project SIX months EARLY, BELOW cost and with ZERO defects. I can;t stress enough how impressive it is to have zero defects....the power of AGILE.

I can give you COUNTLESS other examples...it is a FUBAR'd mess.

This might help if there is a next time (or for anyone else that's interested)...

• Waterfall (top row):
  The product is built piece by piece—first wheels, then an axle, then a partial vehicle—until the final car appears at the end. Each step delivers components, but no usable vehicle exists until the very end.

• Agile (middle row):
  Each stage produces a usable solution, starting with a skateboard, then a scooter, then a bicycle, then a motorcycle, and finally a car. The product evolves while delivering functional value at every step, even if it is not the final form.

• AI (bottom row):
  The first version already looks like a strange but complete “car‑like” solution, and subsequent iterations are refinements that steadily improve it. This implies rapid generation of a complete but imperfect solution, followed by iterative optimization.

What it represents conceptually

The image represents different development mindsets and value‑delivery models:

• Waterfall:

  • Sequential, linear process

  • Long time before the user gets value

  • High risk if requirements change late

• Agile:

  • Iterative and incremental

  • Continuous user value and feedback

  • Adaptable to changing requirements

• AI‑enabled development:

  • Immediate generation of a working solution

  • Nonlinear progress (big jump early, refinement later)

  • Emphasizes speed, experimentation, and augmentation of human effort

The core message

The image argues that how you deliver value matters as much as what you deliver. Waterfall delays value, Agile delivers value early and often, and AI compresses timelines by producing usable solutions almost immediately—even if they need refinement. It is often used to provoke discussion about modern software development, innovation speed, organizational change, and decision‑making models, especially in leadership or technology contexts.

 

And, to through even more gasoline on this dumpster fire, there is now a PM tool called Jira that a lot of USAF cyber acquisition organizations are using...

Jira is a popular project management and issue-tracking platform developed by Atlassian. It is widely used by software development teams, IT departments, and increasingly by business and operations teams to plan, track, and manage work.

What Jira Does

Jira allows teams to:

• Track tasks and action items

• Manage projects and workflows

• Plan and monitor work across teams

• Report progress and performance

• Coordinate agile development (Scrum and Kanban)

Common Jira Terms

Term	Meaning
Epic	A large body of work or major objective
Story	A user requirement or capability
Task	A specific piece of work
Bug	A defect or problem to be fixed
Sprint	A fixed period of work, typically 1-4 weeks
Backlog	Prioritized list of future work
Kanban Board	Visual workflow board showing work status

Example

A state military headquarters implementing a new personnel system might organize work as:

Epic: Deploy Personnel Readiness System

Stories:

• Members can update contact information

• Leaders can view readiness metrics

• Administrators can manage user accounts

Tasks:

• Create database

• Configure authentication

• Conduct security testing

• Train users

Why Organizations Use Jira

Jira provides:

• Visibility into who is doing what

• Accountability for tasks and deadlines

• Workflow automation

• Dashboards and reporting

• Integration with tools such as Microsoft Teams, SharePoint, GitHub, Azure DevOps, and Confluence

Simple Analogy

If you think in military staff terms:

• Project = Hurricane Response Modernization

• Epic = Personnel Accountability

• Stories = Muster capability, reporting capability, alerting capability

• Tasks = Individual actions assigned to specific staff members

In one sentence: Jira is a work management and issue-tracking system that helps organizations plan, assign, track, and report on projects and tasks from start to finish.

 
We can now return to our regularly scheduled discussion about pilot training...

Jeez...just start making T-37s and 38s again and call it a day.

1 hour ago, ClearedHot said:

Again, I don't think you understand the U.S. government and their willingness to change the rules of the game. As a Senior VP I had lawyers, former government contracting officers and industry experts parsing every bit of language in every contract. We were still at the whims of the government...they ALWAYS reserve the right to cancel the contract so companies are usually on their heals.

The really sad part, the government PMs are largely terrible...they would not be employable elsewhere. Let me share an example...I need to slightly change it so as not to give away names and such.

I was working a project to integrate munitions and sensor capabilities on some high-end aircraft. The company was state of the art with some of the best programmers in the business...doing crazy cool things with software and sensors. We were using a software process called "Agile", which has been around for a number of years and is VASTLY superior to the way programming was done in the past (Waterfall). Under the old system (Waterfall), if you were building a program to accomplish a task you would start at the beginning and work sequentially through the task to write the program.

Years ago some smart programmers decided on a new method that breaks the project into chunks and assigns levels of difficulty to each stage. Then they focus on the stages that are hardest to complete and assign a lot of energy to run sprints to develop and complete those tasks. There is an agreement that each segment has an agreed upon input scheme and out put scheme (Interface Control Document - ICD). As long as everyone sticks to the ICD you can develop individual modules very efficiently.

We were 1/3 of the way into a project and the government sent a large team to do a milestone review. They did not grasp and had never heard of Agile (despite our briefing when we bid the project). Several hours into the review they wanted to talk to me and the senior leadership team in private. The point blank told us they were going to cancel the project because we were so far behind...we had not even completed the first block of the program.

It took several hours standing at a whiteboard AGAIN describing AGILE and exactly where we were. Of course we did not complete the first block...turning the program on and getting to a start menu was the easiest thing in the project, we had been focuses on cursor on target mensurated three digit coordinates while blending multiple sensors. They put on us on "probation" and we provided weekly reviews...Much to their surprise we ended up delivering the project SIX months EARLY, BELOW cost and with ZERO defects. I can;t stress enough how impressive it is to have zero defects....the power of AGILE.

I can give you COUNTLESS other examples...it is a FUBAR'd mess.

Gotcha, little by little my hope that most government bureaucracy can become something more than a jobs program is destroyed

What keeps the PMs attached to Waterfall vs Agile? The legal process and reporting requirements / milestone definitions or just intellectual inertia?

---

This mess is just a self inflicted wound, our allies already had existing programs (M-346, T-50, etc…) we could easily have just cut n pasted.

Edited 2 hours ago2 hr by Clark Griswold

Another thing, if the government gets pissed a contractor through say CPARS (government report card on the contractor) on a certain program, they have the authority to negatively affect the contractor on other programs.

4 hours ago, Clark Griswold said:

What keeps the PMs attached to Waterfall vs Agile? The legal process and reporting requirements / milestone definitions or just intellectual inertia?

At the time AGILE was new to the defense industry and the old established PMs and PEMs showed ZERO willingness to learn something new. They grew up on waterfall and invested no time in bettering themselves or learning what the professional software community was doing as they advanced the art of the possible. Now they love it, in fact there is an offshoot strategy from AGILE called Modular Open Systems Architecture (MOSA). That just means most new widgets the government purchases are not vendor locked on every part or line of software code. Using an F-35 as an example if someone invents a new DAS that is half the cost and four times more effective, the system is designed so that each major LRU operates on that same ICD construct. As long as the company making the new DAS uses the ICD for input and output, the government can swap, plug and play new technology. That is a VERY good thing for the American tax payer.