Team,
Earlier this year I wrote about my visit to the USS OAK HILL (LSD 51) during which the crew gave me a candid overview of the many administrative tools they use every day to get the job done. That visit, and subsequent discussions with other Fleet units, prompted me to take a deeper look into the way our Navy manages its portfolio of software applications in the Fleet. During my review, I found that we were doing a poor job of adhering to any type of controlled process for deploying, sustaining and replacing our software tools in the Fleet. In short, our governance model was ineffective.
As a result, when I last updated you in April, I let you know that I would oversee a comprehensive review of all our software applications being used in the Fleet today as well as take a good, hard look at how we could establish a more robust governance model to ensure we deliver effective tools that meet the standards our Sailors need and expect from us.
We’ve been very busy digging into this issue the past few months and I want to provide you with an update on what we’ve accomplished and where we’re heading.
RADM Meek and his team at Navy CYBERFOR have been leading a team from OPNAV, the SYSCOMs and the Fleet through a two-pronged approach to find and fix the problems we are having with our software tools and applications today and to ensure far better configuration management in the future.
Their first effort has been to identify all the software applications currently in use in the Fleet and come up with a recommendation to keep, kill or fix each one. This effort has certainly been no easy task as we have identified over 170 separate applications in use today. In some cases, we’ve found tools that have multiple versions fielded in the Fleet today (up to 5 in some cases!). As RADM Meek’s team works through the list, I have instructed them to ensure that every software application is reviewed with the end-user, our Sailor, in mind. If a tool is ineffective or causes an unnecessary burden on our Sailors, we need to get rid of it. If it helps the Fleet, then we need to make sure our Sailors have the resources to effectively use it (current software versions, adequate training and out-year support). The final list of recommended apps to keep/kill/fix will be presented to ADM Walsh and me for decision later this month.
RADM Meek’s team is also working on a second effort in parallel to design a Fleet IT governance model that puts the necessary configuration management controls in place to ensure we don’t repeat the mistakes of the past. Part of the reason we ended up in our current situation is that we have had far too many organizations (at least 21) approving too many applications for deployment in the Fleet with no overarching strategy and insufficient sustainability. As a result, once a tool is deployed, too often it is left to our Sailors to figure out how to properly use and maintain it. As a result, we have created an environment where many of our software tools have actually hindered, rather than facilitated, the tasks our Sailors are required to do to execute their missions. The new governance model will have as its focus the goal that no tools enter the Fleet without a full and thorough technical compatibility review and fully funded training and sustainment plans. I do not intend to add time-consuming, bureaucratic layers to the process, but I do believe that we owe it to our Sailors to make sure we’re doing our part by delivering and properly sustaining the tools they need and require from us.
There is no shortage of work being done right now to take these issues on and fix them. RADM Meek and his team are doing an outstanding job leading the way and I have full confidence in their plan. But it’s important that we all realize that we did not get where we are overnight and so we will certainly not be able to fix all the problems overnight. We're going to need a controlled and dedicated effort to get us back on track…and I believe we have the right team in place to get us there.
I will provide you with another update later this month after I’ve received the initial list of tools and keep/kill/fix recommendations.
All the best, JCHjr
03 November 2010
Subscribe to:
Post Comments (Atom)
10 comments:
I'd be tickled to death to see eSoms killed or at least overhauled. It's a dumb program and whoever wrote it needs to go back to programming school. What's worse, it takes way too much time to do tag outs. I spent all morning getting a total of 12 tags. It's either that, or sailors aren't trained in the programs use (actually, I see that a lot).
Also, you really need to get these sailors some more printers. I've been in CCS and saw a sailor have to run all over the ship to find a printer to print out his tags and make copies of my signed WAFs. Not efficient for me or the ship, not by a long shot. It slows the hell out of the work start up and with so many short availabilities, it's not helping the ship or the contractor to get the job done in a reasonable amount of time.
Byron
Admiral -
Tackling the applications is good -- there will always be low-hanging fruit that can be harvested. The real issue, though, needs to be the PROCESSES that those applications were created to address. If the focus is on reducing the burden on Sailors at sea so they can concentrate on their warfighting jobs, then we should really tackle the "requirements" end of this chain.
We need to be asking some basic questions:
- What requirement does the application support? What is the source of the requirement (ISIC, TYCOM, BUPERS, Fleet, DoD)?
- What business process would be impacted by removal of the application? (Promotion, Orders Generation, Pay, Readiness Reporting, etc.)
- What alternatives exist to complete the business process if the application is removed? (Email data/manual inputs ashore, web-enabled input, etc.)
- What will removal of the application do to the shipboard workload required to meet the existing requirement? Can the requirement be removed or modified?
If we can change the process (the requirement), then we'll find it much easier to deal with the applications. I suspect that RADM Meek and his team are finding 95-99% of the applications fall into the "Fix" category -- because there is no feasible alternative to completing the current work. And the number of apps that will be "killed" won't begin to fund 1% of the changes that Sailors would like to see in order to make the remaining programs more useful and beneficial. If we can change the requirement, however, and reduce or remove the need for certain actions or information, then we have a hope of finding some funds to fix the most pressing needs.
The unfortunate reality is that there are plenty of governance processes in place today that, if fully resourced and utilized, would achieve the same result as the Fleet FAM process that is being developed. At every step in the process - from needs identification, through requirements generation, solution design, development, testing, deployment approval and installation - the Fleet has a seat at the table. The fundamental problem is that the number of seats is huge - and there's no way to staff adequately to fill all those roles. Adding a new process to the mix won't do anything to improve the quality of the product that is delivered to the Fleet - but it will slow the time it takes to make that delivery. To properly staff a process of this magnitude - and to ensure that EVERY tool and application is properly vetted, designed, tester and delivered - will take dozens of people. There's no margin for that in our manpower -- but without that level of commitment, any new governance process will devolve into what we have today: one person at the Fleet level adjudicating hundreds of requests/proposals. Just the effort to PROPERLY manage the current Fleet Modernization Process alone would take a dozen people...and that's not trying to tackle the needs/requirements piece of the puzzle.
Rather than a new "process", I would recommend that the Fleet take the lead in facilitating User Forums, where the Program Managers and staff for the afloat applications come to the waterfront and hear, first hand, the feedback from the customer. Leverage the energy and the enthusiasm of the Sailors, along with their ideas, to inform the PM's and to help improve the products. We used to do those kinds of seminars for weapon systems (including Aegis) -- and when they stopped, we saw readiness decline and Fleet dissatisfaction increase.
I am 200% behind delivering the RIGHT tools to our Sailors to do the job, but I believe we can do that within the existing rules and processes - properly staffed - without having to create new layers of bureaucracy and oversight. With a focus on the "why" , I think we can whittle away at the imposing list of demands we place on our Fleet Sailors and make their jobs that much easier.
Admiral Harvey,
It really sounds like you see the pain experienced by Fleet Sailors today:
1. “We were doing a poor job of adhering to any type of controlled process for deploying, sustaining and replacing our software tools in the Fleet.”
2. “If a tool is ineffective or causes an unnecessary burden on our Sailors, we need to get rid of it. If it helps the Fleet, then we need to make sure our Sailors have the resources to effectively use it (current software versions, adequate training and out-year support).”
3. “Once a tool is deployed, too often it is left to our Sailors to figure out how to properly use and maintain it. As a result, we have created an environment where many of our software tools have actually hindered, rather than facilitated, the tasks our Sailors are required to do to execute their missions.”
What bothers me is that, yet again, a senior officer admits there is a problem and then cautions that it will take time to fix. Admiral, we’ve been waiting for years now, and things only get worse.
Perhaps the problem is too big for one group to take on by itself. Maybe it would be better for RADM Meek’s team to continue with the long term goal “to design a Fleet IT governance model,” while a second team of Fleet Sailors works with a short term goal to identify the handful of applications (certainly we don’t need 170!) that Sailors really need today.
The Fleet Sailor team should include representatives from every warfighting community and a representative sample of officer and enlisted rates and ratings. In fact, the vast majority of Fleet representatives should be application users, which is commonly E7 and below! Once the core group of applications is determined – along with a determination of when, where, why and how each application is used to perform tasks – then your technical experts could help determine what functionality should be consolidated, eliminated or improved. And when that determination is made, take a year or so, but please deliver results! (And please, whatever those results end up being, like you have here, communicate with straight talk, not PAO spin. As you know, Sailors can handle anything, as long as it’s the truth, and truth is what they deserve.)
The long term goal ensures that “no tools enter the Fleet without a full and thorough technical compatibility review and fully funded training and sustainment plans.”
The short term goal ensures that – as soon as possible – Sailors have access to the applications they need (and no more), that Sailors can efficiently and effectively perform their work when using the applications, that applications support Sailors’ personnel and career development needs, and that everything is aligned to Navy policy (as promulgated through OPNAV Instructions and NAVADMINs, for example).
Finally, wouldn’t it be excellent if Sailors could access their easy to use applications through a single portal!
Anonymous (re: processes),
Thanks for the comment. You’ve given me much to think about. We are in absolute agreement that the last thing we need to do is to throw yet another process at the problem. What we need to do – and are doing – is a candid and thorough review of why we have failed to deploy and adequately sustain tools to in Fleet. A process is simply a means by which we achieve the end…but the needs of our Ships and our Sailors are the end state that we must keep at the center of our solution set.
I’m quite sure that as we conclude this study we’ll find that a general lack of disciplined execution to the existing processes has put us in this position, and therefore I would not be surprised if our new governance model looks similar to what we already have…but with stronger measures in place to ensure that we are actually adhering to the process over the long term (and not just while I’m here).
When the team out-briefs me later this month, if I feel that we are stuck in an endless loop or otherwise spending too much time churning on a new process then you can be sure that I’ll redirect the effort right away. For now though, I am encouraged by the progress we have made and the path that RADM Meek’s team has taken. Please stay tuned in for future updates; I’ll be looking for your insight after the out-brief later this month.
All the best, JCHjr
Anonymous (re: short/long term goals),
You raise many good points, but let me start by saying that I think we are in agreement with what the problem is and how we need to fix it.
RADM Meek and his team are doing precisely what you suggest – identifying the short term, immediate fixes to get the tools we have today under control for our Sailors, with the longer term goal (but still less than one year) of fixing the process by which we deploy and sustain those tools in the Fleet. The team is on my schedule 19 November to out-brief the keep/kill/fix recommendations and I fully intend to move out from there and execute. They will also update me on their review of the Fleet governance model, but that will take a little more time to make sure we get it right (see my previous comment about not wanting to create new processes just for the sake of it). Everything I have seen so far indicates that we are headed in the right direction.
Thanks again for your valuable input. I look forward to hearing more of your feedback as we work through this, particularly if you disagree with my assessment that I’m approaching this issue with both very near term and long term outcomes as my objectives.
All the best, JCHjr
Good Day Admiral,
I sincerely hope RADM Meek's efforts are productive, although I must admit I have my doubts, considering the list of players (usual suspects) that are providing inputs and making decisions. I don't see enough Sailor and stakeholder (user) participation and consultation, especially from junior and mid grade Fleet Sailors.
That said, I strongly believe the application Functional and Technical owners, especially for Sailor-facing applications, must be directed to schedule, conduct and report routine verification testing (i.e. annually) to ensure their applications continue to function properly in all of the challenging Navy environments in which they were originally designed to work. Over time, these environments can change, which affects reliability and functionality of the applications. And when Sailors become frustrated with online applications, they seldom take the time to engage Help Desks, or even their own chain of command, and things just get worse. Fleet commands should be randomly selected as test participants, and simple and straightforward scripts should be provided for real Sailors to follow. The results could be used to make improvements, create new requirements, or simply confirm that things are OK.
Thank you for listening, and good luck. VR
Admiral,
Your recounting of the challenges Sailors face in using electronic tools is spot on. Those who have commented above are spot on, as well. Seeing how successful your blog is as a feed back loop, is incredibly encouraging to a deckplate Sailor who lives and dies (professionally) by those programs, such as myself. In fact, based upon what has been said here, I have very little of substance to add here.
V/r
YN2(SW), the artist formerly know as Battle Yeoman (I'm not in AFG any more, so the title seems inaccurate)
YN2(SW), whatever you decide to call yourself based on your new geographical location, you will always be welcome on my Blog. All the best, JCHjr
I am just thinking out loud....
Why is software so expensive?
I agree with everyone, glad this issue is being addressed. Has the root cause been identified? Is it lack of bandwidth, processor capability, or is the software ineffcient, or a combination of the above. I guess we will not get into how efficient the combat systems are in regards to bandwidth...robust yes, efficeint no, IMHO.
Some fundamental challenges when talking software, internet, and bandwidth...none of the solutions are easy or cheap. I remember thinking computers would eliminate paper, then all I did was print, revise, and print again. To bring everyone together, lets focus on NAVFIT 98, everyone remember when it first came out...how user friendly was it? How has it changed in the past 10 years? New Thought: Why is it that a program that has very little graphics takes so much bandwidth. DTS is a perfect example. Even on shore, it is slow. I could not imagine using DTS on a ship.
Nice to see these issues being addressed. Taking care of the small details usually helps in dealing with major issues. Keep up the good work.
Admiral,
When I was first introduced to eSOMS I too was a skeptic. A lot of the software (and sometimes even hardware) we are starting to see in the Fleet would be barely out of the BETA stage in the Civilian world. However, after completing a total sonar retrofit involving many high level and large cascading tagouts I was forced to learn the program inside and out.
In the same day I could be hanging 5 new tags and clearing 10 while still needing 20 tags to remain hanging. By about half way through all the CSOOW’s and I were knowledgeable enough that the contractors could come to me at 0800 in the morning and by 1000 all the appropriate tags had been hung/cleared for their work. I couldn’t possibly imagine doing this with the paper tagout system.
eSOMS is only as good as the people using it and updating its database. Along with that people are only as good as their training. I would like to end my post with one of my favorite quotes:
“Why is it called an Afloat Training Group if all they do is evaluate”
Post a Comment