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

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.

The New Economy must truly be dead.

In the New Economy, I’ve been told by experts, the customer is king. If it were alive, how would you explain Larry Ellison?

Even notorious industry bad boy Computer Associates thinks good customer relations are important, and is promoting a new image as a kinder, gentler software company.

But then there’s Ellison, who, at Oracle AppsWorld, told his customers … his customers! … that they should customize their companies to his software. Customizing the software is wrong. Complementing it with third-party software is wrong. Building applications in-house? Don’t you dare! That would get in the way of your company’s primary mission according to Oracle: Software integration.

The right thing to do? Adapt your business to the predefined processes Oracle has thought up for you, and run your business on nothing but Oracle software, of course.

This attitude would be predictable coming from a communist, but Ellison’s a rich guy. So what is he thinking of? He’s telling us to trust a central planner (Oracle) to anticipate everything we need, and to figure that if he didn’t anticipate it you don’t really need it.

That’s a centrally planned information economy. Memo to Larry Ellison: Centrally planned economies don’t work, and it takes a long time to recover from the failed effort of trying to make them work. If you don’t believe me, take a look at the Russian economy.

Ellison’s mandate is bad for his customers for two entirely different reasons, both related to the fall of world communism.

The first: Ellison ignores the complexity built into every real company — the same complexity that causes all centrally planned economies to fail. Market-based economies don’t out-compete centrally planned ones because they’re more efficient. They’re actually inefficient in some ways, encouraging redundant effort (we call it “competition”). What makes market-based economies superior to centrally planned ones is their ability to recognize and fine-tune the satisfaction of demand.

So while an ERP vendor’s information-economy central planners can recognize and satisfy the big-ticket items like supply chain management and financial reporting, your IS organization is more likely to recognize and satisfy requirements that are closer to home, like (for example) your real estate management department’s need for an investment management system.

Nor does it stop there. Your IS organization also consists of central planners. They’re unlikely to recognize and satisfy (to take another example) your marketing department’s need for a system to schedule use of your company’s trade-show booths. That’s what personal databases, electronic spreadsheets, and Jane, who’s “good with this stuff,” are for.

Unmet need isn’t the only problem, either. There’s also the clothing-size issue: Just because a suit is well-made doesn’t mean it looks good on you. It also has to fit.

Oracle’s process designs are, I’m sure, neither better nor worse than any other carefully plotted swim-lane diagrams (the standard way to graphically describe a process design). It’s just that they almost certainly don’t all line up with your current processes, so taking Ellison’s advice means process re-engineering on a massive scale. The good news is that the process designs themselves are done. The bad news is that the good news only covers about 10% of the total effort of changing every process in your company.

Ellison isn’t completely wrong, of course. Many ERP implementations are unnecessarily complicated because of that’s-how-we-do-things-around-here thinking. It’s quite true that many companies don’t give their ERP vendor’s shrink-wrap processes a fair hearing.

But imagine your meeting with the CEO, COO, and CFO where you explain the benefit of standardizing on nothing but Oracle’s software and processes: “Sure, we’ll have to change how every bit of work in the company is done, but in return we’ll save on the cost of Oracle upgrades! Not only that, but we’ll operate exactly like every one of our competitors. Think of the benefit to our customers — they’ll be able to switch among all of us at virtually no cost!”

Good luck finding your next CIO position.

The whole thing is silly. If every company took Ellison’s advice, then every company would follow identical processes throughout — those envisioned by their ERP vendor, and only those envisioned by their ERP vendor. Taken to its logical conclusion, the result would be that every company in a particular industry would be identical to all others.

Hmmm. Maybe he is a commie after all.

ManagementSpeak: Our staff are empowered to make critical business decisions on their own.
Translation: Our staff are authorized to make decisions as directed by management.
KJR Club member Dennis Kolda felt empowered to disambiguate “on their own” for us. I felt empowered to use the cool word “disambiguate.”