In today’s connected world, those who would do us harm are
connected perhaps more effectively than we are. According to a recent
article in “Wired” magazine (“How
Technology Lost the War: In Iraq, the Critical Networks Are Social
– Not Electronic”, November 27, 2007) insurgents in
Iraq “cherry pick” the best U.S. technology
– disposable e mail addresses, anonymous Internet accounts,
and the latest radios. They do everything on-line, which
includes recruiting, fundraising, and trading bomb building
tips. The article goes on, “The insurgent groups
are also exploiting something that U.S. network-centric gurus seem to
have missed: all of us are already connected to a global media
grid.” We must be able to operate at least as
successfully in this connected world.
Collaboration and information sharing today are defined by Web 2.0 or
Enterprise 2.0 technologies. They have characteristics
including real time information sharing and immediate feedback that
provide new distribution channels and radical transparency.
They include the amateurization of technology away from
‘traditional’ IT companies to virtually anyone with
a good idea. This implies a power shift. It also
implies agility and speed.
Time-to-market in the private sector is about seeking market
advantage. Some services and applications can be created and
deployed in mere hours in today’s web services and mashing
environments. Using a web services platform, for example
Amazon and Google, one can stand up a web site in a matter of hours or
even minutes. Speed and agility are the bywords.
Listening to executives in the private sector, you hear “rush
to mistakes; fail early” and “perfect no; fast
always”. In the end, it is about this –
getting and maintaining competitive advantage. This is the
driving force for the Defense Department as well.
So, how do we stack up? In the Defense Department we are, in
a word, slow. We take months and even years to develop and
write requirements. We do analyses of alternatives.
We develop test plans with key performance parameters to be met in
their entirety before a system can be successfully fielded.
And, we certify systems for security.
All of these steps are done serially. We are process bound
and we do things for IT in the same manner in which they have been done
for years while the commercial IT marketplace leaps ahead. As
a result: we are very good at delivering IT
‘systems’ in 5 years that are - 4 1/2 years out of
date.
As an example, we’ll take a look in the articles below at
testing for DoD acquisition programs today. We will see test
schedules that, from start to finish, take several months, and
sometimes years. They’re too complex.
They’re too time consuming.
We have a systems mentality for IT that has its roots in large, complex
weapon systems. The private sector has moved towards
developing and deploying small modules of capabilities and services to
gain rapid results in the market place.
Simply put, DoD IT acquisition is out of synch.
It’s time for change.
So, what has DISA done? A new attitude toward acquiring IT
has emerged – one driven by speed and prudent management of
risk. The articles below describe how DISA is turning this
new attitude into results for the warfighter. The articles describe how we work the front end
of the process – the requirement; perform necessary
processes in parallel rather than serially; fix the schedule; start
small but scale appropriately; and kill programs early if necessary without prejudice.
We are aggressively working to keep requirements documents small
– broad statements of objectives and capabilities.
Traditionally, when asking for the time, we have told our suppliers how
to build the clock. No more. Now, we are describing
the problem to be solved and asking our suppliers how they would solve
the problem. This approach has a drawback in that it requires
the evaluation process to be more subjective and therefore more
difficult. But in the end, we get ideas and solutions that
lead to best value.
We operate under the ABC philosophy – adopt before buy, buy
before create – in order to get speed. The ABC
approach is described in more detail in the articles below, but
here’s a quick preview. In deploying an enterprise
capability or service, we will adopt something developed and fielded by
a Military Service or Defense Agency if it can scale to enterprise
use. Adopting probably means that we accept something less
than the 100 percent solution, and, depending on what’s
missing, that can be okay if we gain speed. Adopting also
means that we have a new partner, the organization from which we
adopted. And, that’s a strategic advantage for a
joint solution. If we cannot adopt, we will acquire a commercially available service or
capability as a managed service. And, if we still
can’t meet the need, we will build it. When we have
to build, we will build small capabilities and services –
small modules built by small, agile teams.
The private sector has proven it is possible to have a fast acquisition
and development process that minimizes risk, reduces cost, improves the
quality of testing and certification, eliminates duplication, and
enables data sharing. As an added bonus, decision makers get
a better understanding of the capabilities and limitations of the acquisition and development
process. For example, eBay has a simulated environment where
developers can test their applications prior to running them in the
eBay production system. We are doing this today at DISA. We
have the user (people with hands-on knowledge of what is required),
developers, testers, and certifiers working together in parallel in
what we call the Federated Development and Certification Environment
(FDCE), or the “sandbox”. The
“sandbox” is covered in more depth in one of the
articles below.
If speed rules, then the schedule is king. We must deliver
new capabilities and services using schedules that produce real
improvements quickly, so “fixing” schedules is an
absolute. Too often “requirements creep”
extends schedules as thinking matures on what is needed or how to
provide it. This results in extended slips in schedules for
deliverables as we strive for the “right, complete”
solution. Wrong approach. We will fix a schedule
and deliver to it. This will quicken the flow of new
warfighting capabilities and reduce the risk of losing momentum and
funding.
We
have, then, a
mindset that allows, and perhaps even encourages,
accepting less than a 100 percent solution. The up-front
requirements process will never be good enough to provide the 100% true
picture of what we’ll need, considering today’s
increasing pace of change. The best way to get past this
within a reasonable cost/schedule timeframe is to put the product in
the field as soon as we can and let users provide true
“operational” feedback. The key here is
to gather user feedback rapidly and add it to the solution in the next
small capability or service module. This is counter to our
“Key Performance Parameter” (KPP) operational
evaluation culture that is highly risk averse. Our new
approach requires an attitude that we will deliver to a fixed schedule
to put advantage in warfighters’ hands quickly. It
involves making the tough decision to deliver on schedule whatever is
available and has gone through a risk reduction process like the
“sandbox” regardless if it hits all KPPs.
This is time to market: getting warfighters improvements at increased
frequency.
And, we must be able to kill programs early, if warranted, before we
increase the national debt. Using the techniques and
processes we have described, we can assess and decide early if an idea
won’t work. We then need to be able to kill the bad
idea before we spend a fortune in the serial processes of dream, build,
test, and certify.
According to an article titled “The Spymaster” in
the January 21, 2008 edition of the “New Yorker”
(page 50), an innovator from Disney hired into the National Security
Agency (NSA) recognized the “lumbering” pace of
innovation. One said, “Insufficient attention was being paid
to the end user”.
We want to think big, start small, and scale appropriately.
Speed!
So why is DISA working so hard to increase speed? Our end
users are the warfighters. We need to give them every
possible competitive advantage against insurgents who, today, are too
often beating us in time-to-market.
We
have, then, a
mindset that allows, and perhaps even encourages,
accepting less than a 100 percent solution. The up-front
requirements process will never be good enough to provide the 100% true
picture of what we’ll need, considering today’s
increasing pace of change. The best way to get past this
within a reasonable cost/schedule timeframe is to put the product in
the field as soon as we can and let users provide true
“operational” feedback. The key here is
to gather user feedback rapidly and add it to the solution in the next
small capability or service module. This is counter to our
“Key Performance Parameter” (KPP) operational
evaluation culture that is highly risk averse. Our new
approach requires an attitude that we will deliver to a fixed schedule
to put advantage in warfighters’ hands quickly. It
involves making the tough decision to deliver on schedule whatever is
available and has gone through a risk reduction process like the
“sandbox” regardless if it hits all KPPs.
This is time to market: getting warfighters improvements at increased
frequency. 
