This study into Defense IT challenges addresses why DOD fails with Information Technology 86% of the time. Dr. Ash Carter's goal of engaging Silicon Valley and expand the Defense Industrial Base will fall short if DIUX does not understand these root causes.

1. Why DoD is Woefully Behind
in Information Technology
Michael Cobb
CTO (Rugged Cloud Inc.)

2. Don’t Shoot the Messenger
• This presentation is the unfiltered research from 136 senior High Tech (Silicon Valley)
engineers, executives, sales executives covering DoD, and systems support personnel.
• A series of 25 non leading questions was asked as well as three essay like questions
which asked respondents to write their top three solutions which they believed would
help close the DoD/Silicon Valley technology gap.
• Phone and personal interviews were conducted (91) with those respondents who were
willing.
• 9 LSI’s (Large System Integrators) were asked the same questions.
• 1 US Congressman Chief of Staff presented with the question pool and synopsis of the
results.
• Several GAO papers were culled, as were several technology publications, news sites and
editors.
• The research was performed under non attribution.

3. Summary
• The rocky launch of the Department of Health and Human services' healthcare.gov is the most visible
evidence at the moment of how hard it is for the federal government to execute major technology projects.
• Despite efforts to make government IT systems more modern and efficient, many agencies are stuck in a
technology time warp.
• The slow speed of approval to operate new technologies, and the vast installed base of systems that
government IT managers have to deal with all contribute to the glacial adoption of new technology.
• The government's decades-long increase in dependency on contractors to provide even the most basic
technical capabilities.
• Over 50 percent of the federal workforce is over 48 years old—and nearly a quarter is within five years of
retirement age. And the move to reliance on contractors for much of IT has drained the government of a
younger generation of internal IT talent that might have a fresher eye toward what works in IT.
• The government buys and builds things in accordance with "the FAR"—Federal Acquisition Regulations. If it
isn't a “Program of Record”, government culture dictates, it seems it's not worth doing.
• Even when a big rollout "succeeds"—as in hits its numerical goals—it's more often than not a dirty victory.
• I worked for a major technology company during the Army Enterprise Email migration and I can tell you it is
nothing short of a catastrophic failure. It is unreliable, it causes Outlook to hang and crash routinely, and
messages are severely delayed or outright lost with no explanation.

4. Summary (cont.)
• The bottom line is that federal IT program’s success is measured by things that have nothing to
do with how successful they are or by the metrics most of the world uses.
• User experience and productivity as a metric for IT success, the government keeps throwing
out numbers that mask the truth: the only people who would use their systems are the ones
that are forced to.
• If the govies worked for a high tech company they would have been fired 3 months into their
employment.
• Were afraid to tell them the truth because they will put us on the unofficial “black balled” list.
• Disenfranchisement came early…because we were just a “vendor”.
• They find reasons to not adopt a technology because it’s “Too Hard” for them to understand.
• Leadership is disconnected from what few smart engineers they are.
• We have had numerous social gatherings with govies who berate leadership and the project
they worked on but they simply are afraid to escalate serious problems.

5. Summary (cont)
• They work with outdated requirements that have no basis for technology today!
• Govies are to close to the LSI’s and in fact several of them used to serve with each
other when they were in the military.
• The LSI’s use “best value” to hide behind the LSI’s needs to enhance net margins.
• We told the govie program manager that what they are trying to do was “stupid” and
they did it anyway.
• They seem to make technology decisions because of what they know.
• The govies “load up” a program to bill their time to even though most of them
should never have been on the program.
• Vendors are treated as the enemy. We seem to always start off a mtg on the
defense.
• They refuse to meet with and use stupid arguments like we can’t talk to vendors.

6. Summary (cont)
• LSI’s are simply misrepresenting our technology.
• The govies use the trade study process because they are too lazy to do their job’s.
• It’s their people and processes that pose the biggest challenges to how quickly they can use
emerging technologies. The government wants the digital technology of tomorrow -- with
procurement policies written decades ago, when typewriters ruled the day.
• The problem is people – it affects the government’s use and implementation of technology in
two ways. On one hand, workforce culture plays a major role in technology decisions made
within an agency. Does the organization take acceptable risks or is leadership content with the
status quo? The culture resistant to change.
• The LSI’s are nothing more than a form of federal welfare. These guys have no idea about
leading edge technology and all they care about is net margins. The govies abdicate the throne
to these clowns and they wonder why they get screwed.
• I keep hearing how they want to get closer to industry. When we try to approach them the
always hand us off to some SI. We tried to engage the SI and they said they had already made
a technology decision. I talked with a friend of mine who works for the company they chose
and he said it was all about pricing. They had to go into the mud and are essentially losing
money on this program.

7. We must understand the DoD’s position
• Woefully inadequate engineering talent
• Cannot keep pace with Silicon Valley pay scales.
• Generalists permeate the rank and file.
• Technology has become to difficult to understand by the lay person.
• Complete lack of collaboration with industry (the people who invent the tech) not
the system integrators.
• Specious “requirements” left over from legacy programs
– Program architecture never performed.
– Spend my time of why not, than how.
– Blaming contracting is an easy out.
– No feedback loop on failures. Cannot quantify poor results. No one responsible!

8. We must understand the SI’s position
• (Same as the govies) Woefully inadequate engineering talent
• Cannot keep pace with Silicon Valley pay scales.
• Generalists permeate the rank and file.
• Technology has become to difficult to understand by the lay person.
• Complete lack of collaboration with industry (the people who invent the tech) not the
system integrators.
• Driven by butts in seats
– Net margin driven by how many hours they can bill against a program.
– Drive by best value THEY DEFINE.
– Cherry pick lowest cost components for a program
– See no evil, speak no evil. Unwilling to tell their customer when they are wrong.
– Most SI employees are former military or government
– To “cozy” with the govies.

9. DoD SI Competitive Problem
• The competitive landscape
• SI’s compete with each other on cost not technical purity.
• SI’s use trade studies twist the technology to fit net margins.
• SI’s lock in vendors with “exclusive” contracts to prevent other SI’s from using
the tech across a competed program.
• SI’s build lock in into a program making it very difficult to fire the SI.
• SI’s do NOT want “vendors” to talk directly to the government about the
technology.
• OCI’s are a specious strategy to lock out competition.

10. What Can Done Tactically
• The one single recommendation that was common amongst the participants was DoD must first admit
there is a problem.
• Services (Navy, Army, Air Force) should develop a single ARB to define mandated requirements across the
services for IT. The ARB needs teeth.
• IT Requirements should not be outsourced to SI’s. They should be well defined and backed up by the
services and ANY changes or exceptions shall be backed up with well reasoned data.
• Service CIO’s need teeth. They should be the definer of the service IT architectures and should set mandated
standards across their service.
• Services should design reproducible solutions to drastically reduce costs across the board. One offs across
the myriad of programs in the services are killing costs and integration capability.
• Eliminate best value. There is no such thing in IT.
• Stop out sourcing responsibility to SI’s. A failed program because of poor technology selection needs to be
owned by the government.
• Mandate a feedback loop and ensure people are held responsible for performance.