My Photo

« Warfare's Long Tail - Cyber Warfare in Georgia | Main | Open Source in Defense: A Culture Virus »

August 15, 2008


James Lorenzen

Since joining my current team I have made the opportunity to visit our users at the 7th in Korea. The information I gained and brought back was irreplaceable. Seeing how the warfighters used stuff I created 30 days ago was an exciting feeling.

On the topic of delivering incremental capability that doesn't solve the problems for 2011, I couldn't agree more. Back at my former company, a fortune 500 company at the time The Williams Company, I worked in the intranet group developing intranet applications specifically for HR, AP, Solution Center, etc. These weren't top of the line applications. They were "just enough" to make them more productive than staying in outlook, excel, and ppt. We would spend 3-5 months developing it and that was just about it and then we would go onto the next group.

On that subject choosing the right technology to achieve that is what I think about the most. Building things faster and easier are at the forefront of my daily thoughts. Things like rails, grails, ruby, php, flex. Compared to the old java webapp days I can create a simple rails/grails web application in a third of the time it took me with java/struts etc.

Joe Webster

I know I’m just complaining (with little expectation of changing anything). But I think there are some (among other numerous) basic economic tenets that aren’t working in this DoD IT market. “Market failures.” Competition matters but DoD processes and long acquisition cycles create barriers-to-entry into this market and protect the encumbents. Too much process has created an environment that makes it very hard for organizations that are beholden to Quarterly earnings to participate in DoD programs. The cost of monitoring programs that take years to get to contract award, the cost of responding to multiple RFIs, etc. makes it hard for any but the entrenched DoD contractors (who are funding this “stuff” in their overhead costs for existing programs) to participate. As a result, potentially high-quality organizations with great product and intellectual capital shy away from establishing a government practice. And competition for government business is not as fierce as it could otherwise be. One good example is the stronghold some of the traditional, big DoD contractors have on contract vehicles that have allowed them to morph over time from hardware (planes, boats, tanks) to software developers. The government has paid for the on-the-job training and funded and re-funded many low performing programs because of the reluctance (based on apparent risk) to use lesser known corporations whose expertise lies outside traditional DoD hardware.
In order to create motivation for the best minds and products to be continually available to the government, we need to reduce these barriers-to-entry. Ha!

The other market failure I notice every day is that these over-budget, under-performing programs are never allowed to fail or be terminated. They just re-baseline. I'm currently thinking that “hangings at noon” in the central market place would be a good idea.

Bill Parcells has taken 4 different football teams to the playoffs and won 2 Super Bowl rings (with the NY Giants). One interesting occurrence that seems to happen every time he takes over a new football team is that some very comfortable, highly paid “super star” gets cut or demoted. In the first 2 weeks of training camp. When he first joined the NY Giants, it was quarterback Phil Simms (who later did take Parcells to his first Super Bowl win). At Dallas, it was Keyshawn Johnson. Most recently, Parcells has taken over the Miami dolphins and Jason Taylor was shown the door. The point is made that nobody is above the law, nobody gets to take it easy and live on their laurels, there’s a new sheriff in town and the standard of performance is very, very high.

When DoD baselines and re-baselines underperforming programs, they continually erode the standards of performance. There’s apparently no real penalty for underperforming. The competitors are vanquished once and for all, early on, in the initial competition. And then the encumbents motor-on at their own pace for a very long time. Especially in the IT world (without naming names), there are numerous expensive programs that deserve to made an example of.

MAJ Joseph Rush, CGSC student

As an acquisition officer I can tell you that the long hours committed by many DoD vendors are greatly appreciated by the warfighter and the commands they serve in. In my acquisition career I have mainly worked in the aviation community dealing with communication assets and how they are integrated onto platforms. In most cases the vendors provide a 1-800 help desk that is manned 24/7 and also provide a web-based diagnostic self help service. These services have proved invaluable to both warfighter and the support representatives that are deployed in harms way. I will tell you that this work does have real meaning and that individuals making that kind of commitment should feel a great sense of pride in the work they do. There are, however, some points brought here that I wish to clarify.
First, your point about “exercises not counting” may be too aggressive in that it glosses over a main tenet in ensuring improvements or new technology meet the desired capability requirements and have been thoroughly tested to avoid existing capability being disrupted, which is a common reality within aviation platforms. I am on board with reducing the timeframe needed to deliver a capability but there are minimum steps to this process that cannot be omitted. Aviation, specifically, has its air worthiness requirements that are admittedly complex and time consuming but this process ensures extensive regression testing that negates any possible defect or glitch that could negatively impact operator efficiency or, God forbid, a catastrophic failure.
Second, creating an environment where subject matter experts are working side by side with the warfighter is commendable. The question here: where is the line drawn for how many contractors are permitted in theater at one time. As a commander, I would want any and all support available to ensure soldier safety and mission accomplishment. The reality is, however, that each person admitted into theater adds to the scope that that commander is responsible for and, finally, distracts from his ability to effectively support his mission due to that increase in scope. One way to circumvent this is to cross train support representatives, which I did after being curtailed on the quantity allowed, but this increases the demand on these folks and reduced their ability to support effectively.
I realize my views on this may be out of my realm but I thought it would be beneficial as a different perspective which may point out challenges not considered.

The views I present here are my own and not in any way an "official statement" from the government.
---- MAJ Joe Rush, current student at CGSC.

Thanks all for the comments. I appreciate the feedback.

@ MAJ Rush, I should probably clarify that my points about the use of exercises and the interaction between warfighter and developer are focused directly on the area of software development.

Software has different attributes than hardware platforms and I don't think it is well served by the slow release rhythm that comes from the DT/OT cycle. I should have been more careful in my wording though because I don't want to leave the impression that I don't believe in those processes for hardware. The Bradley experience still resonates and the reasons for DT/OT are as strong as ever; but the way they are done doesn't work well for software.

Software, being morphable, works best when it is released in as-small-as-practical increments and feedback from real world usage is continuously fed back into the development process. "Exercises don't count" in the sense that they are often heavily scripted, and by the time they happen so much has been invested in the system that it is gamed to win / work.

I'd really like to see an approach to software in the DoD that was fast, incremental, and with much better contact with the real users (whether in theater or in the form of immediately-after-deployment interactions).

Thanks for your insight.

The comments to this entry are closed.