All Posts in Organizational Design

|In: Career Management|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

Understanding comes first.

Yes, yes, I know. It sounds like one of the Seven Habits. I’d be happier if it was one of the seven virtues, seven wonders of the world, or even one of the seven dwarves.

It’s okay. Covey’s authorship and my insane jealousy of his success notwithstanding, understanding should come first. So credit where it’s due, and anyway, this is a completely different context. While as a matter of both good manners and wisdom it is a good idea to understand what the other feller is trying to say before you start to pick it apart, it has nothing to do with this week’s subject.

This week we’re talking about documenting stuff, writing about stuff, designing stuff, and stuff like that.

Starting with this admittedly trivial aspect of the subject: If you find yourself using “thing” and “stuff” a lot in your writing (and “You know what I mean” in your speech), there’s a decent chance you haven’t thought your subject through. Thing and stuff are vague generalities whose use should be reserved for the most general cases only. Otherwise you can always find a more precise word or phrase that helps readers home in on what you’re talking about.

But that’s more symptom than anything else. I’m talking about the admirable but ultimately misplaced focus many analysts and designers have to get the documentation right. Not that getting it wrong is better, understand. It’s that …

An illustration: Imagine you’re documenting a business process, as is required for various business certifications that start with “ISO,” as well as being insisted upon by one or two maturity model variants. You get the experts into a room, ask what triggers the process in question, ask “and then what happens?” over and over again, and use the answers to build a comprehensive flow chart comprised of a few hundred boxes connected by appropriate arrows and requires a large-format printer to render.

You’ve accurately documented the process, which is useful. The shortcoming: While you’ve documented the process you don’t understand it.

In part, it’s a forest/trees problem — excessive detail can obscure the essentials. As we’re using process analysis as our exemplar (and I’m constructing a strawman to flail at), imagine that instead of setting a goal of “documenting the process” we made our goal understanding it instead. What would we have done differently?

First, we’d have started by listing the process’s outputs. They’re the essence of what matters. Everything else is just the means to producing them; any other means is equally valid.

Next, the inputs — the raw materials the process transforms into its outputs.

Following that … and this won’t be surprising to regular readers … are the organization’s priorities with respect to process optimization. Organizing a process to (for example) maximize flexibility can lead to a very different design than optimizing for, say, a low defect rate (Chapter 3 of Bare Bones Change Management provides a reasonably complete account of process optimization parameters and their trade-offs).

Now is it time for the flow chart? Sorta. Now is the time for flow charts that follow guidelines along the lines of what the Rational Unified Process advises for developing use cases: If you have more than about seven steps in your process description you need to re-think your process description.

Which is often four steps too many, as a very large number of business processes have only three steps to describe: Collect information -> Update databases -> Create process outputs.

Simplistic? Not really, although it is an awfully simple account. Its value is in encouraging this question: Is there a simpler way to collect all the information and use it to update the database?

Because the next step is to drill down each step into the process flow inside it, also adhering to the seven-or-so step guideline. Three layers is almost always enough detail; I’ve never seen a process that’s needed more than four (I’ll save you the math — that’s enough room to describe 2,401 process steps).

But if you follow these guidelines without making understanding the point, all you’ll have accomplished is to document the process differently. Everything I’ve described here is just a means to that end — a way to facilitate understanding.

Not that understanding, all by itself, will do you much good either. But it’s a prerequisite to what you do need.

No, not love, no matter what Sergeant Pepper’s Lonely Hearts Club Band sings, and no matter how pleasant the experience.

What you need, in the world of business, at least, are insights. You get them by understanding something deeply enough to visualize it.

Which is one reason I wish we could stop calling the stuff “documentation.” It might describe what the stuff is, but it misses what matters … what it’s for.

Comments