Let’s get down to cases.

No, not use cases, and can we all please stop adding “use” to “case” to try to sound cool unless we’re planning to use the Rational Unified Process to actually define one?

Thank you. I feel much better now. Where was I?

You want to provide technology leadership. You’ve assessed the situation and all the factors we’ve talked about over the past two weeks are in place, including an enthusiastic business partner. Now what?

Now you’ve learned something about the danger of success, that’s what. Because if everyone you pitched your idea to had said no, you’d have the satisfaction of saying “I told you so” in a few years. Much easier than all the hard work of actually making something happen.

Don’t say I didn’t warn you. Anyway …

You and your sponsor will be tempted to do this the easy way: Evaluate development partners who are experts in whatever the technology is you’re talking about, make sure the winner agrees to adhere to your technical standards and (if you’re advanced) to work with your enterprise technical architects to make sure the new stuff has a clear place in those standards, sit back, and enjoy the show.

It’s tempting. But it misses the point, which is that your most important goal isn’t a successful implementation. Your most important goal is to build a reusable organizational capability.

To be fair, sometimes the best way to build an organizational capability is to establish a firm, deep, durable relationship with an outsourcing partner. If that’s your plan, fine and dandy, but make it a clear and explicit choice, not a default, slippery slope you fall onto because you took the path of least resistance. And even then …

If you outsource, you have a bit more to do. If you don’t, you have more.

Start with the basic framework of organizational design:

  • Process — how you want the work to get done.
  • People — new skills and knowledge you’ll need in your organization.
  • Technology — not only the technology you’re trying to introduce. “Technology” means tools, which includes little niceties like how the new technology fits into your overall development environment, what you’ll need in the way of testing tools, and how IT operations will make sure the new system is working right.
  • Structure — once you’ve finished a successful pilot project you’ll need to assign responsibility for the various bits and pieces.
  • Culture — everyone’s mental habits around how we do things around here. If the impact of culture isn’t immediately obvious, think back, if you’re old enough, to the early days of the World Wide Web, when IT figured the company website should be developed using the same disciplines it used to implement the general ledger system, but Marketing figured it should use the same disciplines it used to build marketing campaigns.

Don’t get too far ahead of yourself. Pilot projects give you more than quick business benefits and “proof” (hah!) of concept. After the pilot you’ll have the benefit of hands-on experience, unlike now when all you have is the benefit of abstractions and theory.

For the pilot, engaging an experienced outside partner is generally a good idea, assuming the technology isn’t so new that there is no such thing. But engaging an outside partner isn’t the same thing as handing the project over to the outside partner with little or no internal involvement. Don’t do this: You and your staff won’t learn anything, except for what you’ll learn about the resentment you’ve caused by giving the fun stuff to the outside vendor.

So make blended teams a project requirement. Assign project management responsibility to the outside vendor. Fair’s fair — allow a certain amount of inefficiency as the team members you provide come up to speed.

But your goal is, at a minimum, owning business leadership, and very likely self-sufficiency. This is your opportunity to build enough expertise to accomplish this.

And in particular, don’t forget the critical role your business analysts will need to play. They’re the ones who match what information technology can do (both the stuff and the organization) to what business executives and managers want to accomplish.

With any luck you’ll have an obvious choice — the business analysts who have already been in your office, trying to persuade you the technology in question has important potential for the business.

Haven’t had any? You aren’t alone. In my experience, relatively few business analysts think maintaining awareness of new technologies and trends is something they ought to do.

The same thing seems to hold among developers, sad to say. So on the people side of things, give this opportunity to the happy few exceptions who do.

* * *

Truth in advertising: I’m employed by Dell Services, which is in this business, which means I’m not entirely impartial in thinking vendor support, either for your early-stage efforts or for building your capability through an outsource, is a good idea.

We’ve been talking about ITaaS — IT as a Service, which doesn’t mean an IT organization that lives in the Cloud, and does mean an IT organization that runs itself as a separate business that views the rest of the enterprise as its internal customers.

Which means with ITaaS you have broader responsibilities than the head of a business division or department. Starting with the past two weeks’ topic – deciding on your business model, of which we covered about half the ones on my list. To continue … and let me emphasize, I’m not saying these are all good ideas. I’m not going to even try to connect these to anything IT might want to pursue — I’ll leave that to your imagination. But they are common business models, so what the heck:

    • Size/growth. Whatever it takes to get bigger. The usual end-game is to dominate a market or distribution channel to the point that doing business with you is either unavoidable (de facto monopoly like Microsoft with desktop Windows and Office) or just a lot easier than the alternatives (Amazon).
    • Do the deal. Live to sign big, interesting contracts. This is an entrepreneur’’ business model. Think Donald Trump and Ross Perot. It’s a business model for people with chutzpah. Not for the faint of heart.
    • Amoeba.  Try a bunch of stuff. Do more of whatever sells and less of whatever doesn’t. This is just the ticket for entrepreneurs who are too prudent to base their futures on doing big deals. Big-deal entrepreneurs will say “risk-averse” or something stronger rather than “prudent,” but they’re pretty much the same thing.
    • Landlord/Tenant. Also known as the Hollywood Studio Model. You provide facilities for entrepreneurs, internal or external. They take most of the risks; your risk is that they might not succeed well enough to pay the rent.
    • Return/profit. Whatever it takes to improve the bottom line. Not a good idea, because it encourages business leaders to take their eyes off the ball. Profit should be a consequence of the business model, not the model itself.
    • Shareholder value. Whatever it takes to drive up the stock price. You know that eyes-off-the-ball thing? Focusing on shareholder value makes focusing on profit look like a good idea.
    • Wait ’em out. Sure, your marketplace has changed. But if you batten down the hatches and hoist up the landlubbers, maybe big competitors will die first and you can inherit their customers, thereby putting off the inevitable. Think Best Buy, inheriting Circuit City’s customers, thereby looking like it was succeeding even as it was becoming little more than “Amazon’s showroom.”
    • Charybdis. The business spiral of death, aka “eating the seed corn.” Revenues are declining. Rather than fix the problem, cut costs enough to maintain profit margins. The business will fail, but you’ll pocket enough bonuses to retire in comfort before the inevitable happens.
    • Find a buyer. Give up. Suck in your gut, put on lipstick and makeup, and find someone with a lot of cash to take you in and give you a nice home.

There you go. If you want to head down the ITaaS path, ask yourself: Just how seriously are you going to take the idea that you’re running a separate business? If you mean it, start with the business model. If it’s just a metaphor, you’ll have to decide how far you’re going to take it.

Which gets to Mike Riddle beating me to the punch on a couple of points he made in last week’s Comments, namely: “If it is really going to be ITaaS, then it must be subject to market forces:

1) It must compete with outside vendors to keep its business, and

2) It must be free to sell to outside business. If it cannot, then the separate run as a profit making unit fails because it is not allowed to develop a full market.”

Yup. If you’re serious about running IT as an independent business, the rest of the business is going to want you to compete with outside vendors for their trade. Then there’s the other side of the coin, namely, that you’ll be dividing IT’s time between the rest of the business and other corporate customers.

Oh, and one more thing — you and your staff will have to get into the habit of responding to the various informal requests for favors you all get from your non-IT colleagues every day, “I’ll be happy to do this. Here’s what it will cost.”

They’ll love that.