It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

Ever wonder what separates successful IT departments from the ones that generate nothing but gripes?

Not what separates star-performing IT from “the pack,” but what separates the competent from the rest?

150 factors make the difference, but they aren’t all created equal. Squint at the list hard and 18 float to the top. (Why 18? Because that’s how many actually floated to the top. I didn’t start with a number in mind.)

Some background: Back in the last century when I wrote the  IS Survival Guide I organized the factors needed for IT to work into four buckets. Over time these evolved into the framework I use today: Business integration, process maturity, technical architecture, and human performance.

The 150 factors on my list of what makes the difference come from drilling down into these four categories. Selecting the 18 “critical success factors” from that list was less than scientific but more than arbitrary — it was the result of experience and lots of correspondence over the years.

This week’s column defines the big four and their overall scope. Starting next week we’ll dig into the critical success factors and what to do about them if your organization comes up short. So without further ado:

Business Integration

Business integration covers everything about how IT fits into the enterprise as a whole. It happens at three levels: strategic (meaning enterprise-scale), tactical (divisional), and business-infrastructural (overall “lifestyle” technologies) integration. And yes, I’m abusing the language using it this way. Live with it.

Those are the whats of business integration. The hows are governance and the business/IT relationship.

Process Maturity

Process … more accurately, processes and practices … are how an organization does its work. IT’s processes and practices fall into five broad categories:

  • Delivery management: Primarily on the applications side of IT, how the organization makes sure IT actually does deliver what it’s supposed to deliver. Delivery management breaks down into three levels: Program management, initiative management, and project management.
  • Application support: This includes everything having to do with designing or selecting; building or installing, configuring and integrating; enhancing; maintaining; and (when the time comes) retiring business applications.
  • Information management: Making sure all structured databases and unstructured data repositories contain what they’re supposed to contain, and are organized so as to maximize their maintainability, integrity, and value.
  • IT Operations: If the systems are down, nothing else matters. If they’re sluggish, something else matters but not much. IT Operations is where IT makes sure the value it’s already delivered is there, ready to use when it’s needed.
  • Personal technologies: The ERP suite is strategic and runs the company. The CRM suite is strategic and drives revenue. But employees live their lives on their PCs, smartphones and tablets, using the office suite, email system, and telephones. Handle these well and employees will forgive a lot. Handle them badly and your reputation is shot.

Technical Architecture

Yes, IT might be “about the business,” but in the end, someone has to make sure the company has the right technologies in place, organized well, and put together to facilitate the company’s next step instead of acting as a barrier or bottleneck. Notwithstanding all that’s written about shadow IT, non-IT IT and so on, when it comes to the stuff that can’t just be a standalone “island of automation,” that someone is IT.

Technical architecture encompasses the applications portfolio, the company’s structured and unstructured data repositories, and all the platforms and technical infrastructure they reside and run on. And how they all fit together.

Human Performance

IT might be “about the business,” and its job might be to provide the technology the company needs (and by the way, its job is now bigger than that, but that’s a different topic for a different column).

IT might get its work done through well-organized processes and practices, but in the end it’s the people who work in IT who make the difference between success and failure.

Human performance isn’t about whether the people who work in IT perform. It’s about everything that has to come together so IT has great people working in it, with as few barriers as possible standing between them and success.

These four factors — business integration, process maturity, technical architecture and human performance — are what IT has to be good at if it’s going to be considered competent.

How does IT become good at them? That’s what the list of critical success factors is for. We’ll start digging into it next week.

Last Sunday wasn’t my own. I’m part of a pursuit team, and we had to rehearse face-to-face to prepare for Monday morning’s presentation.

For me, giving up a Sunday for my employer is an unusual event. For many present-day CIOs and IT managers it’s a way of life.

Does it have to be this way?

The answer is predictable: It depends.

Of course.

But even though it depends, I’m pretty sure it doesn’t depend all that much.

What’s out of your control is your company’s management culture. If weekend hours are a cultural compulsion you had better leave a trail of obvious I-was-paying-attention-to-business bread crumbs behind, complemented by regular in-person appearances. The alternative is to be told you just don’t have the work ethic (don’t get me started) to be part of the team.

That leaves the other side of the it-depends dividing line: When there just aren’t enough hours in the day to get all the work done that needs doing … not occasionally when a crunch hits, but because that’s the nature of the job.

In my experience, there are just a few reasons days don’t have enough hours, most of which are under a manager’s control. Some of the biggies:

Failing to delegate

When a manager has too much work, he/she probably hasn’t given enough of it away.

Don’t you wish you were paid to have brilliant insights like that?

The delegate-more advice does come with a few caveats (you’ll find them, and more, in Leading IT: <Still> the Toughest Job in the World , yours truly, 2011):

> Delegation is collaboration: You get to define the desired outcome. If you’re smart you’ll allow for the possibility that there’s a better one than what you thought of.

> Delegation isn’t a paint-by-numbers exercise: The person you’re delegating to should be the one to come up with the plan. You do get to critique the plan and make suggestions (see previous bullet). You also meet regularly during the course of the work to monitor progress and, if appropriate, make suggestions (see previous bullet).

> Success isn’t what you would have done if you’d done the work: In most cases there’s more than one right answer. Be open to the possibility your sense of aesthetics is a matter of opinion.

> Who did you hire? If there’s nobody in your organization you can delegate something to, consider the possibility that you’re hiring the wrong people.

Comfort zones

All of us … and I’m no exception … like and are more comfortable with some kinds of work than others. It isn’t unknown for even the best managers and staff to unconsciously increase the priority of comfortable tasks and decrease the priority of uncomfortable ones.

And so, you end your day with the glow of satisfied accomplishment that comes from converting a few PowerPoint presentations to the company’s new standard template, attenuated by the nagging concern that maybe you should have worked fewer hours on this and more on getting performance appraisals done.

Yes, yes, yes, I know: Hard work and perseverance pay off in the long run, but procrastination pays off right now. This works just fine until you can’t procrastinate any longer. Then you work after work hours instead of during them.

During is better.

Master your tools

Word, Excel, PowerPoint, Visio, Project, and so on are the tools of your trade. Within each one of them there are features that can help you get work done faster. The missing piece: Most people aren’t willing to learn them. The result: Everything they do that makes use of these tools takes longer than it should. Much longer.

It’s like someone who hauls a big rug out back to hang over a clothesline so they can beat the dust out of it, because they refuse to learn how to run a vacuum cleaner. Sorta.

The infinite pile of work

The pile of work you have to do is finite. The pile of work you might do if you collect everything you might do and add each and every item to the stack is infinite, or, if not infinite, like Einstein’s explanation of the universe: finite but unbounded.

One way or another, there are people who see every pile of work as boundless. These folks always manage to find yet another task to fill out their 70-hour work week, because for them every un-undertaken task is an unscratched itch.

If you’re one of these unfortunate souls, I have no metaphors to offer by way of a solution. But don’t complain about your unreasonable workload.

It’s a self-inflicted wound.