Ready, Fire, Aim!

In a recent 60 Minutes story entitled Watching the Border: The Virtual Fence, Steve Kroft reported on a high-tech project to secure the U.S./Mexican border. This virtual fence is a multi-billion dollar electronic network of radar, high-definition cameras and underground sensors, developed by Boeing, designed to assist the U.S. Border Patrol.  The report states the project is over budget, late, and ineffective.  There have been technical issues with both hardware and software but, as Steve Kroft points out, “…the biggest problem – and you may find this hard to fathom – was that no one at the Department of Homeland Security or the engineers at Boeing bothered to ask the people who would actually be using the surveillance system what they wanted or how they wanted the system to work.”

The indictment of Boeing certainly isn’t unique.  This habit of “engineering in a vacuum” happens all too often.

Engineers are eager to play with bleeding edge technology.  Systems are sold to the suits in corner offices, not to the khakis in the corner cubicle.  Shadow IT organizations operate without governance.  Budgets are allocated months before requirements are vetted.  I’ve even participated in a meeting where a project manager stated they didn’t have the budget to cover the time it would take for a session with the client to discuss their requirements for a project.  Seriously? Seriously!

Why is there always enough time to do it again but never enough time to do it right in the first place?

A number of years ago I was heavily involved with the Southern California chapter of Z-Series Car Club of America.  I would organize monthly car rallies throughout Southern California along back roads, mountain passes and twisties where we would drop the rag tops and take in the glorious California scenery along with the deep throatiness of a well tuned engine.  And, yes, there were times we would enjoy our cars more than the posted limits of enjoyment.

I was driving a four-banger which produced far less horsepower than the its six cylinder cousins yet, quite often, I was either in the front of the pack or right on the tail of the more powerful cars waiting for an opening so I could move past them.  How could that be?  Well, I would slow down to go faster.  Slow down to go faster?

When a car enters a turn too fast, the driver has to slow down or risk a wreck.  If you want to make it around a corner as quick and smooth as possible you need to brake late, slow down, hit the apex of the corner and accelerate upon exit.  The mistake is driving too aggressively.  Smooth is fast.  If your tires are squealing, you’re losing speed.  The energy from your engine is being converted to noise and heat, not forward momentum.  You need to slow down to go faster.  After all, Happiness is not around the corner.  Happiness is the corner.
Happiness is not around the corner.  Happiness is the corner.

I’m pleased to report that across all those miles I’ve never wrecked.

These same principles apply to IT systems and projects.  We need to slow down to go faster.  Gauge the territory.  Plan our angle of attack.  Listen to what the customer has to say.  Involve them as early as possible… and often.  Get their requirements.  Engage the system’s users.  Ask them how they plan to use the system.  Understand, level set, and guide their expectations.

It is much less costly, in both time and dollars, to develop and implement a system correctly than to ramrod it through and do it again later.  Ongoing support costs skyrocket and customer satisfaction plummets if we allow anyone involved to get away with saying “I don’t want it right, I want it right now.”

In direct response to the pressures to secure our borders after 9/11, no one looked at getting the virtual fence right.  They just wanted it right now.


~ by Marc Hedish on January 14, 2010.

2 Responses to “Ready, Fire, Aim!”

  1. It’s funny that Boeing was contracted to do this job and “invent the wheel”. Israel has such systems that are proven and have been working successfully for decades now, without a glitch.

  2. I love the concept, “slowing down to go faster” and it does apply to IT projects (that are always at risk of scope inflation).

    Good article Marc and thanks for sharing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: