-
Please take a moment and update your account profile. If you have an updated account profile with basic information on why you are on Air Warriors it will help other people respond to your posts. How do you update your profile you ask?
Go here:
Edit Account Details and Profile
IKE Double Pump
- Thread starter robav8r
- Start date
I disagree. Some risks may never be realized. Trick is to have robust plans and bump plans in the event that risks are realized. Otherwise you'll never get anything done.
You plan assuming that maintenance is going to work miracles on your airplanes and understand your priorities. Its better to have a 10 line sked and fly 9 of those lines then it is to have an 8 line sked and fly 8 lines.
Spekkio
He bowls overhand.
Lines of funding and who's responsible for the bill certainly could explain a lot. In the example I noted above, if the project sup admits a delay too soon then he could be on the hook for all of the overtime to get back on track.
Again, I don't know all of the ins-and-outs of why it happens. But it does, and it's not because the Navy enterprise doesn't know how long it takes to overhaul a warship.
The shitty thing is that somewhere there's a deployed boat/ship that pays the price for all of this through a sudden extension or surge deployment, even though a plan could have been developed far in advance.
I acknowledge that the plan will never be perfect, but we're always WAY off. If it takes on average 22-24 months or longer to complete an availability, we shouldn't be planning for 18. It doesn't magically make the yard work any faster, and it has a ripple effect on operational units.
Last edited:
All I can guess is that somewhere that someone has made the decision that that pain is better than the pain of empty dry docks and an idle workforce. I can see it being a tough puzzle to figure out to make sure all the pieces come together at the right time. Also not sure what sort of historical analysis back shop these folks have access to make use of all the data that's out there. In general govt is pretty bad about having and using efforts like that.
Pags, are you serious? I understand there are "different" levels of planning and expectations for the myriad groups and levels of your audience, but are you suggesting at the strategic level that there is no place for a "worst case" planning consideration?
exNavyOffRec
Well-Known Member
so true
No. There's a time and place for the different cases and you should know what your risk is before you pick one. Some scenarios you'll want to be risk averse and in others you may be willing to accept more risk. Most of the cases I'm talking about are more tactical and operational (individual ship maintenance plan, daily flt sked). How the risks roll up and impact the strategic level is also important to understand.
OK, maybe if you're a squadron skeds writer, sure, but that is such horrible project management I don't even know where to begin.
Again, depends on how much risk you can afford and how many resources you have. Not everything can be waterfall.
Yup. Navy is absolutely terrible about Big Data. We definitely collect all sorts of it, but that's different from making sure you gather the right data and have the actual analysts/process improvement folks in place to actually make use of it.
And process improvement is really hard in an organization that is always running flat out.
Additional caveat - meant to put in my last post - I haven't lived the nuclear side which is also very different (public vs private shipyards).
Agree we are definitely way off on the planning. I dunno know the ins and outs as I never lived the day to day of the platform HM&E problems, but for CRUDES, that is where the bulk of the delays come from. I can't tell you if the problem is lack of skilled labor (tradesmen), lack of budget, lack of competence, whatever. I will say lack of skilled labor (whether it's doing the job right or being able to get somebody with the right credentials when needed) definitely appears to be a consistently observed problem, though. We are about to pump billions of dollars into the shipyards - hopefully that fixes that at least.
Where I will disagree is that Navy knows how long it takes to overhaul a warship. We don't. If we did, we wouldn't have yard periods that never fucking end (I recall one that slid over a full YEAR a few years back). But again, what I don't know is how well those root cause lessons are being rolled up.
I'm well aware, but even in Agile, you never plan to 100 percent capacity, let alone beyond it. You leave a buffer based on demonstrated velocity that either gets eaten up by unexpected events, or the team pulls in additional work once they've met their commitment. An Agile team that's 100 percent booked is a team that's not Agile, because they can't adjust and pivot without dropping something they already projected they'd do.
Waterfall or Agile, you always always factor in risk by decreasing scope and/or increasing time.
There's no way to partially deliver a warship, though. There are certain prerequisites when dealing with hardware systems that you can't skirt around. I can't deliver a hull with holes in it or with just the diesel generators installed or with full combat systems and no generators. We may have lessons learned but that doesn't mean we incorporate them well into the requirements for the maintenance periods.
Also, our contracting and requirements writing are too strict and rigid to make Agile work. Hell, we can't even get software requirements right for Agile to work. Most of the programs we say are Agile aren't actually Agile. https://breakingdefense.com/2020/06/dod-agile-software-development-still-too-slow-gao/
Unless you are telling CAG that you will have ten lines, when you only have 8.... You don't pray for maintenance miracles. That kind of organizational "pressure" leads to mishaps. If anything, in my limited twelve years in, you add time to their estimates, because that is generally more truthful. Not their fault, they are likely just following your philosophy of overselling what can be done.
Last edited:
This description shows more about what's fucked up in shipyard maintenance than it does anything to critique Agile. If you're working in Agile, this is a time problem, not a scope problem. The idea that a "partially delivered warship" is on the table assumes that someone is going to come back to you and say "no more, you're out of money" when you've been interacting with them every one month to two weeks, showing them the latest progress, and updating them on your best estimate of when shit is going to be done.
The great fallacy of waterfall methodologies is assuming that your initial estimate is anything approaching right, when you're making it at the point of maximum ignorace. In software as in ship maintenance, you don't know what you don't know until you crack the shit open and start working. So your initial estimate of scope, time, OR cost will be at best plus or minus 33-50 percent off. Agile junks the Gantt chart in environments like this. There are too many variables that you can't hold constant, or even measure at all. Which means predictions beyond about three months are useless. So get to work, learn what's actually there, and refine your plan based on what you know now, not what you knew at the beginning or two weeks ago.
Google the Cynefin framework and its differentiation between "complicated" and "complex." Waterfall is designed for things that are complicated, like making a Swiss watch or building a building. Agile is designed for things that are complex. Software systems are complex. Politics is complex. It sounds like shipyard maintenance is complex. The weather is complex. We don't ask a weatherman what the weather is going to be like on one day 6 months from now, because we know he'd laugh in our face and say he doesn't have any way of knowing beyond some vague range.
The fact that the government sucks out loud at Agile doesn't make Agile a bad idea when it's appropriate to use it. That's like looking at the Browns' and Lions' 0-16 seasons, and drawing the conclusion that no one can ever play football. In the words of consultant Ron Jeffries, you tried baseball, and it didn't work. If you can't make Agile work in software, well, frankly you work for an organization that's fine with being mediocre. Even the medical and financial fields are looking hard at how to mesh their compliance requirements with Agile. It absolutely can be done.