CMV-22B Osprey Rollout

[nittany03]

The problem is that the mission requirements were for COD only. That’s why the Navy examined what the actual logistics requirements are (both peacetime and wartime) and learned that 3 Ospreys could meet those requirements. This is the first time that I have heard the USMC recommended 4 per carrier air wing. I’m not sure who in the USMC was an expert on carrier logistics, but I’m curious as to who the source was for that.

Well, the Commodore on the linked podcast mentioned some experimentation at RIMPAC with doing runs to L-class ships, and I guarantee you that was probably welcomed by the poor bastard on the TACC det who was responsible for wrangling ass and trash . . . I mean P/M/C via 3 H-60s and the ACE. Wonder if they weren't so much experts on carrier logistics as angling to offload log runs from the Marine plopters so they can be more available to go do yut-yut things over the beach. Assuming, of course, that there's a CVN in vicinity to the ARG.

 

[phrogdriver]

Has Bell made electric door locks and windows standard?

Why would you ask Bell? The Navy sets requirements. It’s not let contractors dream things up. They respond to what the military asks for.

 

[wink]

Why would you ask Bell? The Navy sets requirements. It’s not let contractors dream things up. They respond to what the military asks for.

Because I heard Sikorsky has made electric windows and door locks standard. And now that they heard @nittany03 mentioned it, Sikorsky is considering leather seats for the Raider.

 

[taxi1]

The Navy sets requirements.

I didn't know seat heat in my car was a requirement until I had it.

 

[ChuckMK23]

The requirements model is anti innovation, low intellect thinking. MVP is the way. Minimally Viable Product - with design and engineering iteration. 'requirements' is a disease. It assumes the users of teh intended prodcut know what they want - and rarely that insight is valid. NAVAIR PMA shops are especially well known for abusing the concept and culture for their own parochial benefit.

 

[phrogdriver]

The requirements model is anti innovation, low intellect thinking. MVP is the way. Minimally Viable Product - with design and engineering iteration. 'requirements' is a disease. It assumes the users of teh intended prodcut know what they want - and rarely that insight is valid. NAVAIR PMA shops are especially well known for abusing the concept and culture for their own parochial benefit.

What does that mean?

Describe how you plan major programs and capabilities 10-20 years out without identifying what requirements need filling. How is anyone supposed to build anything without knowing what the need is? Do you need something that carries 10 people or 100? Does it need to go 10 knots or 1000?

If you mean describing desired capabilities vice platforms, e.g. “detect a submarine with X dB signature at 100nm” instead of “carry the Farquad Systems Mk 4.2 dipping sonar,” sure. But that’s just another way of stating requirements. But you still need requirements—because that 100nm is likely based on a threat assessment of what that sub is likely to carry.

Stuff has to fit together in a place like DoD. You can’t just buy the “MVP,” whatever that is supposed to be in this construct.

 

[taxi1]

describe how you plan major programs and capabilities 10-20 years out without identifying what requirements need filling.

The Marine EFV had a hard requirement to be a 30 ton jet ski traveling 30 kts, or something like that, until they realized after many billions of dollars and years of effort that the requirements violated the laws of physics.

Then the requirements became something achievable.

 

[phrogdriver]

The Marine EFV had a hard requirement to be a 30 ton jet ski traveling 30 kts, or something like that, until they realized after many billions of dollars and years of effort that the requirements violated the laws of physics.

Then the requirements became something achievable.

Not against the laws of physics, really, just difficult and expensive. But a failure of the technology assessment, not of the idea of having requirements.

They help integrate the force—e.g. you need helicopters that carry X number of people, so you need Y of them to transport a Marine company, so an amphibious ship needs to be of Z size.

Those connections all need to be made. You can’t just buy crap without reasoning behind it.

 

[insanebikerboy]

To illustrate what (I think) @ChuckMK23 is trying to say, I’ll use the Bush as an example. I went out for a few weeks to support a CQ det in 2009, and if memory serves it was the first CQ det post shakedown.

Every ready room had a cork board for pushpins. Not a single person on board wanted a cork board in the ready rooms, instead everyone wanted dry erase boards. But, that was the requirement in the original document, so the ready rooms had cork boards. Squadrons ended up buying their own whiteboards and the last I heard the Navy wrote a new contract (more $$$) to replace the cork boards.

I understand contracts, etc, but I think the bigger point is that the solution to an original requirement might need tweaking or alteration during the acquisition process as the requirement is refined.

 

[nittany03]

@ChuckMK23 and @phrogdriver . . . I make my living in the Agile space. You're both right and you're both wrong, I could write a paper as to why, but I'm not doing that on what's my early Friday night. Suffice it to say that Chuck has obviously had a sip or two of the Kool-Aid and knows the buzzwords, but Agile transformation is not always that easy or appropriate. Hell, it's hardly ever easy, and it's horrible when you're just doing it because some exec heard Jeff Sutherland talk about "twice the work in half the time." Writing those words was possibly one of his biggest mistakes.

For Phrog, the definition of an MVP is that you don't have to buy it. You can if you want to, but you don't have to. It's the minimum feature set which you can demo to a customer and get feedback. Then, you come back to the customer on a regular cadence as you keep adding features, to make sure that you're building what's needed NOW, not six years ago when you signed a contract. The point is that at the end of any given iteration, the customer can say "stop, this is what I need, it's good enough," and you're done.

If you want a specific example of this being applied to defense procurement, Saab built the Gripen using Scrum, and there are case studies at scrum.com, which is Jeff Sutherland's consulting company. If you want more examples of this being used in industrial applications, Google Joe Justice, who worked with Elon Musk at Tesla and is one of the leading minds on Agile hardware development as opposed to software. If you want to know more about the theory, research the Cynefin framework and pay specific attention to the difference between complicated and complex problem sets. Traditional DOD procurement assumes a complicated domain, whereas Agile is specifically geared towards complex situations. Stanley McChrystal also does well explaining complex environments in Team of Teams.

 

[phrogdriver]

@ChuckMK23 and @phrogdriver . . . I make my living in the Agile space. You're both right and you're both wrong, I could write a paper as to why, but I'm not doing that on what's my early Friday night. Suffice it to say that Chuck has obviously had a sip or two of the Kool-Aid and knows the buzzwords, but Agile transformation is not always that easy or appropriate. Hell, it's hardly ever easy, and it's horrible when you're just doing it because some exec heard Jeff Sutherland talk about "twice the work in half the time." Writing those words was possibly one of his biggest mistakes.

For Phrog, the definition of an MVP is that you don't have to buy it. You can if you want to, but you don't have to. It's the minimum feature set which you can demo to a customer and get feedback. Then, you come back to the customer on a regular cadence as you keep adding features, to make sure that you're building what's needed NOW, not six years ago when you signed a contract. The point is that at the end of any given iteration, the customer can say "stop, this is what I need, it's good enough," and you're done.

If you want a specific example of this being applied to defense procurement, Saab built the Gripen using Scrum, and there are case studies at scrum.com, which is Jeff Sutherland's consulting company. If you want more examples of this being used in industrial applications, Google Joe Justice, who worked with Elon Musk at Tesla and is one of the leading minds on Agile hardware development as opposed to software. If you want to know more about the theory, research the Cynefin framework and pay specific attention to the difference between complicated and complex problem sets. Traditional DOD procurement assumes a complicated domain, whereas Agile is specifically geared towards complex situations. Stanley McChrystal also does well explaining complex environments in Team of Teams.

You’re just talking about a different prototyping concept. That’s something OTAs do already.

That’s not getting rid of requirements. You still need something to anchor on. You still need something to say,”This equipment needs to defeat threat X while carrying Y pounds.” Those are tied into doctrine and current intel. You can give contractors more leash as to how you accomplish a requirement, but they’re still a thing.

 

[nittany03]

You’re just talking about a different prototyping concept. That’s something OTAs do already.

That’s not getting rid of requirements. You still need something to anchor on. You still need something to say,”This equipment needs to defeat threat X while carrying Y pounds.” Those are tied into doctrine and current intel. You can give contractors more leash as to how you accomplish a requirement, but they’re still a thing.

No, I'm not. This is a mindset shift as to when requirements are generated and why, not to mention a re-evaluation of what "prototype" means. Yes, you're right that eventually the whole list of requirements will emerge, but the fact that you're talking about giving contractors "more leash" is part of the problem. I'll write about this more later, but I've got other things to do tonight. Suffice it to say that it's all well and good to write a laundry list of stuff tied to today's doctrine/ROCPOE/TACMEMOs/OPLANs/etc, but that means fuck-all years later when the platform enters service.

The entire point of Agile is that it is a mindset to govern your actions when you're operating in an environment where more is unknown than can be known. And the irony is that TACAIR in particular and Navy/Marine Air in general does this in spades at the tactical level better than any software team I've yet seen.

 

[Brett327]

giving contractors "more leash" is part of the problem.

Yes and no. Sometimes industry pitches capabilities that work as part of the whole system that didn't come from a requirements document, but are value added.

The requirements model is anti innovation, low intellect thinking. MVP is the way. Minimally Viable Product - with design and engineering iteration.

Says the guy with zero experience in the process. The MVP model is literally a clown show, Chuck. I don't even understand how you've arrived at this bizarre conclusion.

 

[Odominable]

Re: requirement buffoonery. The Cobra has, inexplicably, SAR FLPN functionality. I refuse to believe that was customer driven.

 

[taxi1]

There are two key questions at work in acquisition
1. What do you want?
2. I don't know, whatcha got?