???At the end of the day it's far better to plan for 100% and achieve 90% then plan 80% and achieve 80%.
OK, I'm 95% confused...
???At the end of the day it's far better to plan for 100% and achieve 90% then plan 80% and achieve 80%.
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.That's terrible risk management.
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.???
OK, I'm 95% confused...
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.I suspect a big part of it on the private side is that there are cost penalties (either a hit or a bonus withheld) to the repair yard to resetting the schedule/missing milestones, so even a government supe is going to be really careful about making a delay official.
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.The problem is you never know what you're going to find when you crack something open. And then you never know what analysis is needed, what parts you might need to fix it and what their lead times are. Yeah, you can hazard a guess and pull piles of historical data but you never know if you're looking at routine maintenance or a unique failure until you get eyes on whatever you're working on. Then of course multiply this problem by however many pieces of equipment are in the work package.
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.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.
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?No one wants to know worst case, everyone plans to best or middle case and then reacts when worst case happens. At the end of the day it's far better to plan for 100% and achieve 90% then plan 80% and achieve 80%.
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.
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.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?
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.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.
Again, depends on how much risk you can afford and how many resources you have. Not everything can be waterfall.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.
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.
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.
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.Again, depends on how much risk you can afford and how many resources you have. Not everything can be waterfall.
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.
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.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.
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.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.
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.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/