So you're the new CIO? Congratulations or condolences, which should it be? A bit of both. Nobody ever said it would be easy to be a tech-savvy plus business-savvy strategist who focuses on important IT initiatives and innovations while simultaneously managing hiccup-free daily operations and delivering complex initiatives predictably, on schedule, and within budget.

But that's your job.

It's hardly a surprise that turnover is legendary. In truth, there aren't a lot of people to whom this level of versatility comes naturally. And even among those who can figure out what they should do, much of what goes wrong for CIOs arises from how they go about it. The substance of what you do matters, of course. But great ideas poorly communicated don't get implemented, or if they do, it's without broad support, so if things go wrong, the only neck in the noose may be the CIO's.

Critical to success is gaining the respect of two very different constituencies: on one side, hard-nosed businesspeople who live in a nuanced messy analog world of worrying about customers and competitors and the bottom line; on the other side, technicians who live (or try to live) in an orderly unambiguous digital world, worrying about architectures, technologies, and techniques. A CIO who fails to show understanding and empathy with both will have a difficult and probably rather brief tenure.

In the accompanying Executive Report, we show that the best ways to go about gaining respect depends greatly on the initial situation. The framework for analyzing the situations is a matrix based on two questions: What happened to your predecessor (moved on with honors, still around but moved out of IT, or pushed out of the organization)? And where were you before (in the organization's IT community, in a non-IT post in the organization, or outside)? Navigate successfully and doors open and tend to stay open. Get it wrong and you could spend the rest of your tenure as CIO on the back foot. The purpose of the report is to suggest ways for new CIOs in each situation to maximize the likelihood of getting it right.

Much of the report focuses on how emphases and priorities differ by situation. We also explore style and, inevitably, politics, and how those need to be tailored to the situation. Some fortunate people can come in as a new CIO armed not just with the knowledge of what to do, but also with the instincts to grasp the situation quickly and adapt their style and their priorities and approaches for doing it. As a consultant to a number of CIOs over many years, I have not seen this happen a whole lot -- though I acknowledge consultants see a sample skewed toward the less successful. There is an all-too-lengthy laundry list of ways to mess up, and those are only ones I've seen myself.

The report also covers specific actions to take, or at least launch, in the first 100 days. These include a range of items such as the following:

• A "safety check" looking for vulnerabilities to events outside your control such as denial-of-service attacks

• A sweep for "unexploded land mines" such as troubled projects, unsupported vendor software, and key people inclined to defect

• Getting to know the numbers (i.e., becoming familiar with spending along a number of different dimensions)

• Ferreting out your real mandate (i.e., do they really want a business-IT strategist or just a cost-cutter who doesn't mess up?)

• Launching strategic conversations if you feel they would be well received given your sense of your real mandate

• Picking some low-hanging fruit (i.e., getting rid of low-value spending whose axing would ruffle no important feathers)

All the actions apply regardless of the situation, but their relative priorities and emphases are a function of the situation. Next, the report follows these general assignments with situation-based advice, identifying pitfalls and dealing with style and politics and relative emphases.

The report also suggests things not to do in the first 100 days, such as technical initiatives that would require spending a lot of political capital (as well as money and people's time) for activities whose tangible value is hard to explain outside the IT shop.

Another category to avoid in early days is changes in high-level reporting structures or budgetary practices (i.e., areas with high political visibility) without a clear statement of the problem you're trying to solve, the urgency of solving it, and why your proposed change would solve it. Avoiding a hornet's nests, absent critical urgency, is a good idea.

Perhaps the most important word in the new CIO's vocabulary is "why." As the CIO, it's your job to be able to make the "why" case for anything you want to do -- strategically, technically, organizationally, and financially -- to your CxO peers. This is not about asking permission to do things as much as it is creating a level of comfort that you have a firm hand on what's going on in your area of responsibility; you know what's right to do and why and how best to get it done. Therefore, it must also be your job to extract compelling "why" answers and credible "how" answers from IT people, expressed in English rather than jargon.

No book and certainly no report should claim to be a definitive guide to making the first 100 days a success; being a CIO is playing in the big leagues where book-learning only goes so far. Yet academics and consultants and, most of all, practitioners, keep chipping away, as they must. If the thoughts in this report help keep some new CIOs from doing (or failing to do) things later regretted, they will count as chips.