Better Together

In the last couple of weeks I’ve had a chance to reacquaint myself with a couple of great local I.T. vendors. They’re helping us craft a Disaster Recovery strategy.

For larger companies this is relatively easy. Just throw gobs of money, time and resources at the problem and away you go. It’s actually easier to justify DR in a larger business environment than in a smaller one – even though the predictable outcome of NOT having a recovery plan is the same. (I’ve had to do both.)

For privately held firms or smaller public firms, “DR on a budget” is a lofty challenge. Duplicating a server rack at another site is expensive. Having all your applications hosted at a 3rd party data center is expensive. There has to be a better alternative.

This week, a couple of local vendors are really stepping up. Our shop is thinking about virtualizing our servers – both for the daily benefit of leveraging unused processing power and because we can take a “snapshot” of the virtualized servers to shorten recovery time in the event of a disaster.

Virtualizing servers effectively separates applications from hardware, allowing the applications to be easily transported and recovered into another virtualized environment very quickly.

Think of it this way.

Circa 1950, every office Manager had their own secretary to do typing. One Manager. One secretary. Sometimes the secretary was overwhelmed with work and sometimes there was no work to do. Then someone came up with a different idea.

By introducing “typing pools”, a group of secretaries were organized to handle the typing needs of a group of Managers. In this way, no single secretary got overwhelmed with work.

Server virtualization works the same way. Most servers are responsible for one main application or service. By pooling processing power across applications, we can make better use of our servers.

Well, once we get our servers virtualized, we benefit on a daily basis. But, in the event of a disaster, where can we recover? We’re all set to go. We have snapshot tape backups of our virtual servers in hand.

Now what?

Well, it turns out that there are NOT a whole lot of great options for small business. If we want to recover our data at a hosted site, we need to rent the site as if we were using it every day. This option is way too expensive (or we’d already be doing it).

So the way I see it, we’ve just uncovered a business opportunity for our vendors. And to our vendors’ credit, they see it too. So now, they’re trying to figure out how they might host DR services for small business. The idea would be to setup a series of virtual servers in their data center, then contract to several companies for the same recovery space to cover their equipment costs. And voila! An affordable DR solution for smaller businesses.

Companies like SunGuard and IBM have been doing this for years for big companies. Now it’s time that someone offered the same protection for smaller business – at prices that smaller businesses can afford.

The lesson here, is that some customers simply invite their vendors into the office to be beaten up on price. Smarter customers take a look for opportunities where both customer and vendor can be better together.

There are almost always win/win outcomes, if everyone is willing to look for them.

The Power of Tempo

I’ve always struggled to restrain my internal “sense of urgency”. In business, my personal bias has always been toward action. And lots of it.

Some may argue that my approach resembled; “Ready, Fire, Aim!”.

I think that’s a typical response to someone who really wants to see things happen quickly. The reaction is “Not so fast!” or “We’re being too reckless!” The danger in eliciting these responses is that it creates the opposite effect.

Instead of increasing the pace of work, people “dig their heels in” and resist, rather than getting on board and fast tracking a solution.

The business challenge works just like a Chinese finger puzzle. When you insert your fingers in each end of the tiny tube and then try to pull your fingers free, the puzzle grips your fingers more tightly. What seems like an obvious solution to the puzzle is the wrong one.

I’ve learned a more effective approach is to gently increase the tempo of work. Think of it like a metronome. By gradually increasing the tempo over time, your team will work at an improved pace – something they might have resisted, had you attempted the increase in one big jump.

Try breaking the habit of weekly progress meetings. It’s very easy to fall into the trap of meeting on a regularly scheduled basis. Sure, meeting every Friday at 9am is easy to remember, but it imposes a certain pace on the project.

So break the habit.

Try meeting on Mondays and Thursdays. Set the unconscious expectation that the same work will happen before each meeting. What was once a ten week project, becomes a five week project. Simply meeting more frequently to report on progress, sets the expectation that progress should be made.

You begin to break that old college habit of starting the term paper the night before it’s due. With weekly business meetings, the work usually gets done the night (or hour!) before the meeting.

Increasing the meeting frequency also allows you more frequent opportunities to reset expectations.

“Guys, it doesn’t have to be perfect. It just has to BE!”

Let’s get our prototype up and running, set the right expectations with our internal customers (let them know it’s a prototype), allow people to use it. Then improve it.

Our goal is to make version 2 bug free. Let’s not try to architect perfection. Let’s built it based on user/customer experience.

The longer term benefit of increasing the pace and NOT trying for perfection, is that you begin to develop a learning organization. Expect some mistakes and begin to see them as improvement opportunities. “Blame” is expunged from your team vocabulary. And as the rapid prototype mindset takes hold, you begin to see other incremental improvement opportunities in every process you use.

By looking at each opportunity as a challenge to improve through “tweaks” and multiple iterations, you slowly empower your team to identify opportunities on their own. Not all changes have to come as a result of a big project. Teams can make a big impact my making incremental progress on lots of smaller projects too.

Finally, remember that Teams Win and Coaches fail. If the result of one of your accelerated projects is less than expected. Take the heat for your team. If you’re asking them to take a risk by developing 90% solutions, you had better provide “cover” for them. And when the team has success, give them ALL the credit.

I think you’ll be pleased with the results.

Here are the Cliff notes:

1. Gently increase the tempo.

2. Aim for a 90% solution.

3. Pilot and improve.

4. Migrate to a learning organization.

5. Take the heat, when necessary.

Ask the Right Question!

A business associate of mine is in talks with a local client about a potential consulting engagement.

Due to a number of factors, the client believes they need to reorganize their I.T. resources, and they’re looking for help. Certainly the options are obvious; align by customer segment, align by function, align by technology, even align by application.

The problem with the whole exercise is this.

They’re asking the wrong question.

First, the client needs to answer the question – “What problem are you trying to solve?”. Once you get the question right, the answer becomes almost self evident.

Without a clear understanding of the problem, any internal alignment will do – because you don’t know what the outcome should be! The client would be better served hiring my friend to help them identify pain points within their service delivery and support model (which he’d be excellent at doing) – to help them understand the nature of their problem; to help them pose the correct question.

They might even discover that I.T. alignment isn’t the issue at all. It could be an I.T. governance issue or possibly an underperfoming department.

The lesson here is that sometimes consulting dollars are better spent helping you ask the right questions, than in providing the answers.