If the road to hell is paved with good intentions, why do we need so many deadly sins? As with the afterlife, you can fail in the tough job of managing Information Systems even with the best of motives.

If you really want to get into lasting trouble, though, you have to work at it. Here are seven surefire suggestions — admittedly less fun than the real deadly sins—for getting yourself mired right in. Another difference: With the real deadly sins you’re generally off the hook if someone else commits them. You’re guilty of the Information Systems Deadly Sins if any member of your organization commits them.

That’s what leadership is all about, isn’t it? So, let’s dive right into our cesspool of systems malfeasance to find out how you and the rest of your organization can go straight to perdition.

Sin #1: Arrogance. Arrogance is a lot like pride, the unforgivable hubris of legend. And like hubris, arrogance taints your judgment by blinding you to your own limitations.

Systems arrogance takes many forms, so look for the symptoms. Do you hear help desk analysts swapping dumb user stories, or using the popular acronym RTFM (Read The Friggin’ Manual)? Then you can bet your bottle of Pepto Bismal end-users gripe about the “helpless desk” while they long for the days when they bought their own PCs in defiance of IS.

How about your systems designers? Do they complain about users who are unable to reach consensus on system specifications just before they start another endless argument over the best way to map their normalized data model to the persistence layer of their object class hierarchy?

Arrogance is a veneer — a thin covering of excuses hiding deep performance deficiencies. As penance, develop a cultural exchange program with key department heads, and have the offending analysts work at end-user jobs for a few months. Even if they don’t come back humbled, they’ll understand a bit more about the business.

As an alternative, force every analyst who sneers at an end-user to memorize the instruction manual for your VCR.

Sin #2: Grandiosity. Systems professionals engage in systems thinking. Be thankful for it. Part of systems thinking is extending ideas to their natural boundary.

Unfortunately, there’s a sort of one-upsmanship that goes along with this, so if one analyst generalizes the need for a purchasing system into something that covers the whole raw materials life cycle, the next one will extend it further to Computer Integrated Manufacturing. The one thing everyone agrees on is that the person who requested the system is too narrowly focused, and that failing to design for the bigger picture will result in colossal expenses a few years from now.

End-users call this “designing the universe”. It makes them nervous because they thought of the project in the first place, and now some arrogant systems know-it-all (see Sin #1, above) is expanding it into a monstrosity that can’t be built.

As penance, assign the offending analyst to work with Marketing to implement changes to your Web site. Since Marketing asked for the changes last week and wants them in a month, that should break the grandiosity habit.

Sin #3: Project-itis. In medicine, the suffix “-itis” refers to inflammation or swelling. Project-itis refers to a systems manager’s desire to sponsor a Big Project.

This sin is closely allied to both grandiosity and arrogance, but where grandiosity came from a sense of design and arrogance from self-doubt, project-itis comes from a desire for self-improvement — in the career sense, that is. The sponsor of a big project is looking for a promotion: probably to CIO, most likely in a different company, and almost certainly halfway through the project, just when the cracks are starting to show.

Big projects are a sin because anything longer than nine months is forever and will never happen. Projects only succeed when there’s a sense of urgency, so your project planners should break every big project into manageable chunks that stand on their own.

In the meantime, you have to establish a penance for managers exhibiting project-itis. Make them manage the help desk for a while — that should do it.

Sin #4: Jargon. This is the sin of analysts needing to demonstrate they know something end-users don’t. Why use an perfectly good old word when a new one sounds better? That’s especially true if your key end-users have diligently learned to communicate with your analysts.

So, when end-users bought into structured analysis, it was important to introduce JAD and RAD, so you could patronizingly explain that they stand for Joint and Rapid Application Development, respectively. What if the end-user pointed out that you’ve been designing applications jointly for years and it’s been your analysts who have insisted on doing it the slow way? You get to explain that this is different, because there’s a methodology behind it, which is jargon meaning some consultant wrote a book saying it’s okay to do it this way now.

Jargon has to evolve, because the old words end up attached to discredited ideas. There was CASE (Computer Aided Software Engineering), for example which was just perfect for huge projects that never saw the light of day.

So when CASE went out and objects came in, it was perfectly natural to introduce “Use Case Analysis,” introducing a flock of new an useless terms. Here’s what makes Use Case Analysis especially groovy: Its proponents claim credit for inventing the idea of working directly with end-users instead of tossing requirements over the transom — I am not making this up — and they also explain that, unlike traditional forms of systems analysis, Use Case Analysis and the resultant creation of object class libraries deal with normal business concepts.

If you hear your fully buzzword-compliant analysts spouting off to a group of end-users, the penance is clear: Assign them the task of creating a systems glossary. After they finish, compliment them on its quality — and heck, they did such a good job you’d like them to keep it current!

Sin #5: Methodologism. No, not Methodism — we’re not talking about trivial issues like religion, we’re talking about the important matter of adhering to the methodology.

Since nothing gums up a perfectly good methodology like project deadlines and an emphasis on actual business results, methodologists are quick to emphasize that in the long run the methodology will pay off, usually in reduced maintenance costs. Methodologists often commit the sin of project-itis too, since they stem from the same cause — a desire to build an impressive resume to make departure to the next company easier and more lucrative.

Penance? Buy into the methodology … but cut the preferred tools out of the budget, because “We had to choose between buying the tool for you and your two team members or hiring a dozen programmers, and we need the programmers now.”

Sin #6: Control. “We can’t let the end-users do X. If we did, Y might happen!”

The sin of control is expressed through a variety of unappetizing behaviors. A favorite is the creation of unnecessary standards, and an emphasis on enforcement rather than end-user benefit. The creation of standards is not, of course, a sin. The relationship between standards and control is the same as the one between eating and gluttony. One is necessary, the other excessive.

Key to control is prevention. If you hear conversations about how to best prevent end-users from loading their own software, building their own applications, or invoking their spell-checker without first obtaining permission, you’ve got it bad. A sure sign: lots of discussion about headaches, none about business benefits.

As penance, make a speech at your next staff meeting emphasizing the importance of IS setting the example. After all, like Caesar’s wife everyone in IS must be above reproach. So anyone within IS who violates standards and policies will be subject to immediate termination.

Sin #7: Supplier Mentality. Who do you work for? Do you view yourself as part of the company, or as an independent supplier?

The supplier mentality is expressed through unwholesome behaviors and attitudes. Do you view other parts of the company as your “customers”? Do you ask your customers to sign formal contracts? Do you negotiate system features with them as part of the process?

If so, you’re a supplier, not a partner. And as a supplier you don’t need to worry about doing penance. You need to worry about being outsourced — that is, being replaced by a better supplier.

* * *

Okay, so these “sins” have been overstated, but every one can sabotage your relationship with the rest of the company, so they’re worth the exaggerated emphasis. It’s your relationships that represent the foundation on which you build your success. Your behavior and that of everyone in your organization either reinforce that foundation or tear it down.

There’s only one way to choose the right path: Don’t sin.