CONTRACT REPORTS: Schedule Rules: Why Speed is the Critical Variable in DoD IT

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.

abcWe 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.