Since its publication in April’s Proceedings, I’ve been pleased that “It’s Time for a ‘Sea Control Frigate’” has helped start a discussion about a new small surface combatant (SSC) on message boards, the blogosphere, and social networking platforms. The article describes how a modified version of the Coast Guard’s National Security Cutter with improved survivability features and combat systems could offer a terrific supplement to the Littoral Combat Ship (LCS). With the attention the article received, various readers had questions concerning some ideas brought up, so I’ve taken the time to address them.
Analyzing Cost and Production
Many asked how the projected cost for the ship could cost $800 million with the last national security cutter price costing $735 million. Surely the upgrades mentioned in the article are greater than $65 million. They are indeed. However, what was probably missed is that the $735 million order for the last NSC was for a single ship – economies of scale can drastically reduce the cost per unit due to various efficiencies gained. For example, when the Coast Guard ordered several at a time, pre-NSC #5, the cost was substantially less. My math: the 2006 per unit cost for an NSCs (in a bulk order) was $584 million – when we account for inflation, it goes up to a current value of $650 million, or $85 million less than the last single contract. (The Coast Guard had to order the later ships one by one because it wasn’t written into the budget at the time –and it was uncertain if the 7th and 8th NSCs would even be funded). Thus, a procurement cost of $684 million, which is used in the article and various other official reports, is an average between all the ships. Most likely a base hull would be even less than this, as the price doesn’t include the initial hull design costs (this was incorporated into the NSC program), there are increased economies of scale, and various items included in the NSC price are not be needed on a navy frigate (eg: the complex stern boat launching apparatus). While I estimated $800 million by adding the cost of a VLS, an upgraded 76mm gun, a new radar, and various survivability upgrades, in accordance with navy and congressional reports, a fixed price will likely creep closer to the $900 million mark due to inflation over the next few years and other add-ons the Navy incorporates (this would happen with all of navy shipbuilding though).
Ship Force Numbers and Value Metrics
The latest LCS estimates are at $550 million per ship including mission modules vs. $800 million for a sea control frigate. Assuming we have the same budget to work with, and we’re deciding between a basic LCS only, we’ll either have to choose between 20 LCSs, or 13-14 frigates. This led many to question if it’s worth having a lesser amount of warships for the same price. First of all, for the most part, comparing these numbers are like apples and oranges – who cares about the amount of a certain ship if they can’t do the missions that we need them to do, especially cost efficiently? However, as much of a red herring the argument is, politically, it’s still hard to rationalize, especially since many elected officials find it easier to talk about our ship count in terms of our budget, vice a thoughtful debate on capabilities and requirements. In contrast, one good metric to take into consideration is the average number of ships at sea on missions per day. 20 LCSs on a 3 crews-2 ships-1 deployed plan, averages 20 total days a quarter of underway time on assignments, or 4.5 ships per day. 14 stateside frigates on a traditional deployment cycle average 32 days a quarter out to sea on assignments, or 4.9 ships per day. This means that despite a lesser amount of ships, the sea control frigate still has more underway time doing planned missions than the LCSs. I calculated this data from the class average of underway hours per quarter, and verified this by known historic and planned deployment operational schedules for frigates/destroyers and littoral combat ships.
At first, this may seem contradictory to statements made by officials like Rear Admiral Rowden, who recently claimed that 26 forward deployed LCSs equate to 120 CONUS-based single-crewed ships. This kind of statement is misleading. The Admiral is correct for certain missions and events like foreign nation cooperation and training, humanitarian assistance and disaster relief (HADR), vessels in distress or under pirate attack, counter-narcotics operations, and little-to-no notice popup missions like special ops support. For example, let’s take an earthquake in a Southeast Asian country. The LCS is perfectly fitted to get underway immediately from Singapore, speed to the location, and provide necessary humanitarian assistance, all within hours. However the same can’t be said about the majority of tasking and deployments that have requirements already defined by combatant commanders relating to sea control, like naval escort, focused operations, and deep-water anti-submarine warfare. These missions all require more consecutive days-at-sea, which helps explain the reason why, by design, the LCS averages less mission days per ship than frigates and destroyers.
That’s not to say the 3-2-1 cycle isn’t the right method with the LCS. On paper, minus the sea swap trap, it’s actually a smart plan that saves money and optimizes the ships very well. It’s also necessary to have a flexible warship forward deployed for the reasons stated above, but only for quick back and forth missions in the littoral environment, not sustained blue-water deployments. If we do end up purchasing LCS variants, most of these ships will regrettably end up getting pulled from the presence and shaping missions they were designed for to support these missions.
Determining Feasible Designs
Earlier this month, a request for information (RFI) came out that asked the shipbuilding industry on input for a follow-on to the LCS from mature designs, which led many readers to ask what’s actually on the table. The context of the RFI may seem like it’s targeting a number of different ships and shipbuilders, but it’s in fact just a formality required in the consideration process for any future acquisitions; there are actually only a few possibilities here. The foreign contender with the best shot, if any, is Norway’s Fridtjof Nansen-class frigate because of its past relationship working with NAVSEA and Lockheed Martin. Although any proper frigate is preferred over the LCS because it’s better optimized for operating in blue water environments, I’m partial to the sea control frigate because of its large flight deck and hangar spaces, which gives it the flexibility to support drones and manned helicopters together, something that will likely become the norm within the next 30 years. However, the truth is because of the timeliness of the request and decision making process, together with the red tape that a foreign design has to go through (which was touched on in the original article), it’s probably too late in the process already to even consider a foreign design, regardless or not if it meets what the Navy’s looking for. This is unfortunate; we’ve essentially locked ourselves in a box by not starting this process earlier (or coming up with an organic solution for that matter).
There are several different variants of the LCS that are likely to be considered alternatives– most concepts have been pitched publically in some manner, mostly to international navies under the banners of “International LCS” and “Surface Combat Ship”. These variants could include similar features to a sea control frigate, such as a Mk 41 VLS supporting ESSM and ASROC, a CEAFAR or SPY-1F radar and fire control system, other survivability features, and for the LCS-1 class, an upgraded 76mm gun. However, there are still some problems with this: unlike the NSC hull which was built with reserved spaces that can accommodate a VLS and other systems without hull modifications, a variant of the LCS would likely require design changes more substantial than any NSC-derivative. One industry news source remarked that an international LCS design pitched to Israel that incorporated some of the above mentioned weapons features had an estimated cost of over $700 million (this was in 2008, so it would likely be even more today). Another claimed a rough order-of-magnitude cost would be $800 million, equivalent to a sea control frigate. However, the price pitched to the Navy by Lockheed or Austal might not even matter – with the trends of the LCS shipbuilding program, it’s possible that whatever price is proposed will balloon up even further. This is probably not a risk the navy would want to already take for a program already under heavy scrutiny for its ever-rising costs, especially with a fixed-price option on the table for a sea control frigate. Secondly, it’s likely that no design changes will be able to offer an improved endurance and range; therefore, even with upgrades in weapons and survivability, it would still be ill-suited for blue water missions. Moreover, the manning structure and contractor reliance wasn’t made to accommodate long lasting blue-water missions either, which means even some small casualties that are normally fixed by a DDG/FFG ship’s force could and throw off an entire mission; something probably not ideal for optimizing the readiness kill chain.
This leads us back into re-examining the numbers. With the same budget, an up-armed LCS design with a higher unit cost reduces the number of LCSs that are produced. For example, an improved LCS costing $650 million each (which by all estimates are very optimistic) buys only 17 ships, three less than planned. As the LCS cost continues to increase, the ship price per unit gap continues to close, until its relatively the same price.
Cross-posted by permission from CIMSEC’s NextWar Blog
Within the U.S. Navy, routing up correspondence seems fairly straightforward, but in the execution there always seems to be issues that make it anything but. In some commands, dozens of pieces of correspondence are routed per day, and in even the best commands, an occasional piece of correspondence tends to either get lost or misplaced. Conversely, if leaders aren’t accountable, correspondence may be held onto for longer than standard policy, contributing to a negative climate. Either way, it seems like locating correspondence is always a hot topic. One thing I’ve noticed, when managing an administrative department at sea, is that most of the e-mails, questions, and drop-ins we received were related to the tracking of correspondence.
There is no standard issued software to administer the routing of correspondence at sea, so we decided to create one with support from other members of the administrative department and the CMC. The software, called eCART (Electronic Correspondence and Routing Tracker), is used to track all correspondence that goes up through the ship’s office to the XO and/or CO. Correspondence is still placed in a traditional folder with a routing slip, however, leaders now input the correspondence name into the eCART program for tracking. When it’s hand carried to the next person that it’s going up to, the user clicks a button in eCART to mark it as being “routed” to that next position in the chop chain. The program then automatically sends them an e-mail informing them they now have custody of that certain piece of correspondence. For ease of use, the e-mail contains a link that takes them to the eCART program, where they themselves can continue routing the correspondence up the chain.
When a user is routing up correspondence via eCART, they can add comments electronically. These comments, as well as the full chain of custody with dates and times, are seen both up and down the chop chain to increase transparency in the process.
When there are new comments to be read, there will be an asterisk preceding the subject that alerts the user. The interface is very straightforward and is broken into two tabs – “My box” and “My Correspondence”.
“My box” displays all the pieces of correspondence that the user’s position has custody of. “My Correspondence” displays all the originating correspondence from that user whose routing is still in progress or marked as completed/returned. For personnel that wear more than one hat, they could switch back and forth between their positions in the program by selecting their role in a drop-down box (ie: OPS may be the Safety Officer, and STRIKE may be the Legal-O). This allows any number of authorized users (even a whole office) to control one box and all receive e-mail notifications. It also allows another authorized user to fill into a position as “acting”. Thus, the routing process can still function when someone goes on leave or TAD. Since having several users control a box could create a problem with accountability, the program always logs the specific person that takes any action.
Included is a complete administrator interface, which allows designated managers to add, modify, and deactivate users and positions. There is also an option that allows the user to skip all e-mail routing notifications, which may be useful for VIP positions like the XO and CO that receive many pieces of correspondence. However, for the XO and CO, who may not want to be bothered to use the program themselves, it is more likely for designated authorized users, such as members of the ship’s office, to go in and record a change every time correspondence is transferred in or out of their boxes.
The program is built entirely on Microsoft Access. One Access file (acting as the database) is put onto a hidden directory on the ship’s shared drive or exchange server. A second Access file containing the user interface on top of 850 lines of VBA scripting acts as the client and is also put on the shared drive or exchange server as read-only and distributed to users. The client calls and communicates with the Access database on the network, which allows it to serve as a de facto software and database package, supporting up to 50 users accessing it simultaneously. The database file can easily be saved, backed up, and even transferred between LANs by simply compressing it into a zip file. The program calls and interacts with Outlook e-mail through an appropriate reference, and automatically detects the Windows’ user and alias information, so it automatically logs in the appropriate user when opening the program.
eCART is a finished product that can be deployed at any command, but is specifically intended for commands at-sea. Initially, it may be hard for all leaders in a command to adopt this new process, but with proper training, and even the implementation of policies such as one that rejects any correspondence not logged in eCART, it can easily become second nature.
Cross-posted by permission from CIMSEC’s NextWar Blog
There’s been a big uproar lately about innovation in the Navy throughout message boards and the blogosphere – what is innovation, what it’s not, and what method Big Navy should be taking to jumpstart innovation among the fleet, if any at all. LT Jon Paris and LT Ben Kohlmann, both of whom are very involved in the conversation, had a great discussion about the topic on CIMSEC’s Sea Control Podcast, hosted by LT Matt Hipple. LT Paris followed up with an excellent blog post. While there are some contrasting views, it seems like one thing that’s agreed upon is that the deckplate innovation already occurring in the fleet sometimes doesn’t make it “up and out” or isn’t as publicized as it should be. In that capacity, LT Hipple, and some members from the CNO’s Rapid Innovation Cell, offered a challenge to start publishing examples of innovation in the fleet. I’ve decided to take this up head on in a series of “Innovation Files”.
Nearly every command has a “Plan of the Day” (POD) – a widely distributed one-page agenda with at least the current and following days’ schedule of events. Depending on the command, certain PODs are very long and many regularly contain dozens of events per day, some at overlapping times. Early on, I noticed a couple glaring inefficiencies particular to my command. First was the process – A yeoman would be specifically assigned to “do the POD” for the day, a duty rotated among the junior yeomen that nobody wanted. This task started by opening the previous day’s POD, changing the date, piling through various e-mails and files on the shared drive, and then writing the new daily schedule by hand. After an hour or two, it would get routed up to the ship secretary, personnel officer, admin officer, training officer, operations department, various department heads, command master chief (CMC), and some others before finally getting to the XO. Every position in the chop chain had their own changes and events to add, and it required the yeoman to literally go around the ship looking for each of these people, and then going back and correcting the changes for each correction or addition. It wasn’t uncommon to print in excess of 15 POD drafts before the final revision. As you can imagine, POD duties were an all-day event, and since the POD needed to be finalized and signed by the next day, it kept everybody around well into the evening.
After much thought, the XO, personnel officer, and I agreed on a plan to create a public calendar on Microsoft Outlook to streamline the POD process. However, PODs have a very specific format, and Outlook can print nothing close to the format. For example, asterisks had to be next to times if the event was to be announced on the 1MC, events had to be in bold lettering if the CO was attending, and everything had to fit on the page in two neat columns. It wasn’t as simple as hand-copying every single event into the old POD format though; the daily schedule constantly changed throughout the day, and there was no process in place to ensure if any late additions or modifications in Outlook were included in the POD. This, along with other human errors, severely complicated the process, and made it essentially as inefficient as the old method. If only there was a better way!
Introduce the automated POD (autoPOD). We decided to devise a macro app on top of Microsoft Publisher, a computer publishing tool, to automatically translate events on Outlook into the same easy POD format everyone was used to seeing. Macros are essentially programs, coded in easy-to-learn VBA (Visual Basic for Applications), that are built on top of application documents (in this case Publisher’s and Outlook’s) meant to automate tasks within these programs. Because of this attribute, it gets around IT policy requirements, which prohibit the introduction of specific executable programs not pre-approved by SPAWAR. Microsoft Publisher was chosen over Word because it’s specifically designed to manipulate documents with multiple dynamic text boxes. Through an appropriate script reference, the app asks the user permission to reach out to any designated public Outlook calendar. Then all the user has to do is click one button, and it automatically inserts the daily schedule into the POD publication – complete with dates, events, headers, etc. The layout is easily manipulated by different codes inputted into the appointment screen on Outlook. For example, for an event to appear “bold”, which indicates the CO is attending, an actual Outlook invitation for that appointment is sent to the CO, which is then designated on the user interface with a specific user name.
Along with events, the app supports all sorts of informational headers put in by different users through Outlook tags – for example, the operations officer puts in the appropriate command duty officers and duty sections, and the quartermasters put in sunrise and sunset times into Outlook. The app supports time structures displayed as “All Day” or “TBD”, and all types of recurring events. Different permissions (ie: read only, add, or modify/delete) can be granted to different users to modify the Outlook Calendar, and the program is set up for an administrator to view when and who is putting in the events, so it’s not possible to sneak a last minute evolution for the next day without the XO and CMC knowing.
AutoPOD was eventually customized for several other tasks. By request, we built an automated Plan of the Week (POW) 10-day printable outlook on top of Microsoft Excel for the Planning Board for Training (PB4T), which mimics the POD format each day, for planning purposes. Other ships had a weekly or monthly outlook summary with important events listed on the back of their POD, and autoPOD was customized for these commands as well, using the “priority” attribute to determine if the item should be displayed on a weekly summary. We have continuously refined AutoPOD to accommodate every ships’ POD format, meaning there will be little, if any, visible change to the Sailor. For example, there are options to modify the font, size, and width for the time and subject columns. Additionally, it’s designed to be plug-and-play – all contained in one publisher file – so it can be used immediately and without any complicated installation procedures. Detailed documentation is provided on how to install the program and manipulate the schedule via Outlook.
It is worth noting that the initial concept of autoPOD was not received well in its early stages. For example, the yeomen were used to a certain way of doing things, and didn’t want to move over from Word to Publisher. Despite comprehensive training, some department heads and department lead chief petty officers continued to send e-mails to admin with their events, instead of deconflicting and scheduling it themselves in Outlook. However, after much dedication and patience, everyone slowly acclimated. The new system is now second nature, and it’s hard to think of how life even functioned in the past.
To date, autoPOD has been distributed to over a dozen ships, across several waterfronts. It has undoubtedly made the POD process less frustrating, and has saved countless manhours and time, from the junior yeoman who can produce a POD in minutes, to the XO who no longer has to micromanage the process. Unfortunately, we recently hit a bump in the road when asked to set up the app on a ship that finished an extensive shipwide IT refresh known as a Consolidated Afloat Networks and Enterprise Services (CANES) installation. At the time, CANES strictly restricted ships from creating and using shared calendars, along with other security settings that prevented the app from working properly. A workaround is in progress, but it illustrates a point that has been brought up in the recent discussions – many Navy policies and procedures are around for valid reasons, but often come at the expense of productivity and innovation. It’s essential to collaborate between the fleet and appropriate project managers / designers / policymakers to figure out an optimal mix.
Of all the missions the Surface Navy does, Ballistic Missile Defense (BMD) might be the least sexy. It involves sitting in a small box in the middle of the ocean for weeks, usually far away from land or even any commercial shipping traffic. Ships on station need to be in a specific engineering and combat systems configuration at all times so they can track or engage a target at a moments notice. This means there aren’t many opportunities for training, ship handling, gun shoots, swim calls, and other evolutions. Sometimes, a poor middle-of-the-ocean satellite uplink makes the internet unusable, and “River City” could be set (meaning the internet is turned off completely) for bandwidth constraints or upholding Operational Security (OPSEC) due to mission sensitivities. Depending on the ship’s heading and location, TV-DTS (the Navy’s satellite TV connection) could go down as well. Hopefully the seas aren’t rough, because there’s little chance to get a modified location (MODLOC) to divert for better weather. If it’s a nice day, fishing from the fantail seems to be the most exciting thing to do; although there never seems to be much luck in getting a catch (it seems most fish know how to avoid the BMD box at all costs). Forget port calls, but even when ships aren’t on station, they could still be on a formal or informal “tether” which prevents them from going anywhere too far away from the BMD Theater (yes that means no Australia!).
For those that have done a tour with the Forward-Deployed Naval Forces (FDNF) in 7th Fleet, it is known especially well that the long-term schedule is taken with a grain of salt. Stateside deployers have the luxury of knowing their deployment timeline years in advance. However, the Japan-based ships in 7th fleet, especially the nine destroyers and cruisers that make up the backbone of the battle force, face uncertainty every day.
Due to rising Asia-Pacific tensions, FDNF operational tempo (OPTEMPO) has increased dramatically and the continued requirements that ships have to meet also continue to increase. It is quite frequent for ships to be called out to sea at little-to-no notice for any number of different missions including anti-submarine warfare (ASW), ballistic missile defense (BMD), and even humanitarian operations! The jam-packed schedule does not allow for any wiggle room – this means that ships are also called up last minute to replace others that are down a warfare area, have an engineering casualty, or need extra time to prepare (or re-prepare) for a major inspection such as Board of Inspection and Survey (INSURV) or Type Commander Material Inspection (TMI). Unfortunately, Sailors and their families take the blunt of the unpredictable schedule, and in my opinion, it is one of the main reasons one chooses not to do another FDNF tour.