All Posts in Leadership

|In: Career Management|Last Updated:

What, I’m sure you’ve been wondering, does successful spycraft have to do with the projects your organization undertakes?

Wonder no more. I’ve tracked down the answer, courtesy of Good Hunting: An American Spymaster’s Story (2014), whose author, Jack Devine, ran some of the CIA’s biggest, most complex, and highest-profile covert operations (he was the Phillip Seymour Hoffman character’s successor in “Charlie Wilson’s war” – the U.S. support for the mujahedeen’s resistance to the Soviet invasion of Afghanistan.

If you decide to read it you either will or won’t be put off by the author’s occasionally self-congratulatory tone, and might or might not be convinced CIA covert operations are as good an idea as he thinks they are. KJR doesn’t discuss foreign policy matters unless they’re directly related to information technology, and even then …

Whether you think covert operations are a good idea has nothing to do with they take. Turns out, a lot of it is (or should be) Project Management 101. It also turns out that whatever else Jack Devine is, he’s KJR’s kind of project manager: His list isn’t about what’s needed for covert ops to succeed. It’s a list of the factors without which covert operations (and your projects) are bound to fail:

  • Viable partners in place: In the world of covert ops this means there has to be a significant faction within a host nation that shares our goals and objectives and is willing to fight for them. In your world this means someone who matters in the affected business areas has to want it deeply enough to stick his or her neck out from time to time to help the project succeed.
  • Real-time, accurate information: In the world of spycraft this means information from foreign agents, not just technologically gathered intelligence. In your world this means you need a personal network that lets you know what the buzz is about your project.
  • Adequate resources: You might recall that nearly every Y2K remediation project succeeded. You also might recall that companies opened their checkbooks to support them. You also might recall business leaders who drew exactly the wrong conclusion … too many idiotically decided their success meant there never had been any risk. The right conclusion: While “throwing money at a project” doesn’t generally help, starving a project is usually much worse.
  • Bipartisan political support: In business, bipartisanship isn’t good enough, because few businesses are limited to just two competing factions. So from your perspective let’s call it multi-partisanship. Not everyone has to support a project for it to succeed, but enough have to that the political clout is on the project manager’s side.
  • A direct threat to U.S security: In covert operations, this means the adversary against which the covert operation is targeted must present a clear and present danger — covert operations aren’t something to undertake lightly. Projects in your world ought to have some reasonably direct connection to threats and opportunities in the marketplace.
  • Proportionality: Even the cleanest covert operation can cause “collateral damage” (the intelligence community’s clinical euphemism for “innocent bystanders can get hurt or killed”). In your world the situation is less extreme but still real: The expected value of a project’s outcomes must outweigh, not only its direct costs but also the intangible costs associated with the disruption it causes.
  • A reasonable prospect for success: For a covert operation, policy makers must have clear objectives and a fact-based assessment demonstrating that the operation is feasible. For one of your projects it’s usually a good idea to either determine that someone else has done something similar and succeeded at it, or to complete a so-called but usually mis-named “proof of concept.”

Devine makes the point that making sure these factors are in place is the responsibility of policy makers, not the CIA. KJR makes the point that business policy makers have a parallel responsibility, not the CIO.

Except that this is where the parallel breaks down. When we’re talking about the CIA and covert operations, even success can have grave consequences, so strong top-down controls are essential.

Keep in mind that instituting controls means establishing a system in which the default answer to any suggestion is “No.” This is rarely desirable. At best, it’s less undesirable than the alternatives.

Most businesses want, or should want to encourage innovation and initiative, something controls stifle through the EHL effect (epiphany half life) — the time needed for the enthusiasm for a new idea to be cut in half.

So before you subject proposed projects to too much vetting, ask yourself whether the loss of innovation and initiative is worth it.

See proportionality, above.

Comments

|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