The 2 Minute Drill

Football fans are very familiar with the term "2 minute drill". The term refers to the strategy employed by teams (usually playing from behind) to maximize effectiveness during the final 2 minutes of a football game.

They use a "no huddle" offense, signalling plays using gestures or audible calls. The entire team rushes to the line of scrimmage. They run plays designed to preserve time on the clock - running the ball out of bounds or passing sideline routes.

The pace of play is dramatically increased. The defense has little time to react to offensive formations and no time to substitite players.

An effective 2 minute drill can be a game saver or a game winning strategy.

And so teams practice the 2 minute drill all the time. You never know when you'll need it and you have to be ready, just in case.

The 2 minute drill shows you how well your players perform under pressure. They help distinguish the players who come through in the clutch. The practice takes performance to a higher level (just when you need it most).

In business, we don't have the equivalent of the 2 minute drill. We can't practice performing at a higher level for a short duration. There's no way to know in advance which employees will rise to a stressful challenge and who will fold under stress.

Or is there?

A couple of years back, we were faced with an ERP version upgrade. Typically these can take 6 months or more to complete. They require much of the same testing, documenting, training efforts of the original implementation. They are a tough challenge.

We couldn't stand the idea of spending the next 6 months of our lives going through that hell.

So we decided to do it in 8 weeks.

It was our version of the 2 minute drill.

I must confess, not everyone believed in the mission. A couple of very good functional analysts said it couldn't be done. But we started anyway.

The time constraints caused us to work much smarter, and much faster. But we couldn't sacrifice quality. The system had to work properly, documentation had to be completed and training materials updated. No shortcuts on the results.

This "crisis" forced us all to re-examine the standard processes. We looked for ways to shortcut the process - to do things in parallel. So we installed the new system in its own environment. We began unit testing while our application developers re-integrated customizations we had made. Original test scripts were used and slightly modified. We developed training materials simultaneously with testing. Because the entire team was focused on getting this done quickly we adapted.

We didn't make our 8 week deadline.

We took 12 weeks. But we did it in half the time a typical upgrade takes to do. And the results were spectacular.

We learned several things from the exercise. We discovered who worked smarter and who didn't. We discovered how individuals handled the self-imposed pressure. We saw people "watching each other's back" and helping out where it was required.

Most importantly, we learned that it could be done. We had done an upgrade in 12 weeks. Three months earlier, only a few thought it was possible.

Now I'm not advocating that this be done all the time.

No team can run a 2 minute drill throughout the game. The players would be exhausted, your team incapacitated.

But if you pick and choose the right task or project, and try your version of the 2 minute drill, you'll end up discovering who the star players really are. You'll know your team's true potential and show them what's possible, in the process.

And if your team begins to think that anything is possible. It is.

Why is Saying NO so difficult?

One of the toughest challenges of any I.T. department isn't installing that complicated system, or upgrading the network or integrating that new acquisition or even Sarbanes-Oxley compliance efforts.

It's saying No (or not yet) to enhancement requests. Setting an honest expectation.

Yet without clear, concise, easily understood expectations, our business community's default expectations are "Yes". They're waiting to hear the answer to "when?"

And so it goes. Development requests come into I.T. The B/A says we'll take a look at it. And it never goes any further or the project gets estimated and added to the never ending "list". Or worse yet, the B/A makes some sort of commitment (trying to be helpful) that has little chance of being met.

The requester is disappointed (or irate) and I.T.'s reputation takes yet another hit.

Who's at fault here?

Not the business person, who is trying to improve a business function or reduce costs or service customers better. To them, why wouldn't I.T. want to get their project done? Who can argue with serving customers better or improving costs?

Not necessarily the I.T. business analyst who's listening to the request and estimating the project. After all he/she rarely has any say in how projects get prioritized. They usually aren't in the position to give a Yes or No, yet that's what is expected of them.

The process is the problem.

Imagine for a moment that your company had no I.T. function. Let's say it's 100% outsourced. (Some of you may not have to use much imagination... but I digress). If you need a system enhancement, you'd have to detail the expected benefits of the enhancement, then get the projected estimated by your outsourcer, before you'd have a complete picture of the project complexity and estimated payback. If the investment was large enough, you'd likely have to go through a capital expense procedure, where you'd take the business case to your company controller or CFO and (s)he'd make the decision whether to proceed or not.

The clear advantage to putting the decision in the hands of the Finance leaders is that;

1. They can hold the business accountable for the business case benefits. This has several advantages. Armed with the expectation that the business will be held accountable for the benefits, helps eliminate spurious "nice to have" requests. This reduces requests and related business expenses estimating projects that will never be approved by the business.

2. CFO's can make system project decisions armed with the overall business priorities perspective. Something that I.T. could seldom do.

This process turns I.T. Projects into Business projects.

Which is what they should be.