Rules for Running a Successful IT Organization

Rule 4: Standards matter

Especially these days, this rule is really important. Companies with written programming and process standards will succeed overall because they're following standards and open systems, meaning they can meet new technology with minimum effort. This was true on a mainframe and it's still true today.

This also gives you the internal flexibility to move resources from one project to another without huge ramp-up times for the development team. With everyone following the same standards, you end up with a very flexible team that is mobile enough to change quickly as user/business demands change.

In addition, it provides continuity on the project when key personnel change. I cannot tell you how many projects fail simply due to key changes in personnel during the development and implementation cycle. With process and technical standards, these changes are seamless; without them, they are a disaster.

Rule 5: What's old is new again

You could also call this "back to the future," or "same stuff, different day." Technology is cyclical. Take cell phones for example, whose functionality was very thin, is now getting bigger, and as bandwidth becomes more pervasive, will get even thinner again. This cycle applies to all technology and should play a factor in your technology decisions.

I've got a hundred numbers stored on my cell phone. When my kid puts it in the bathtub, the phone is dead and the numbers are gone. The time it takes to re-enter those numbers is worth much more than the device. If the information were held on a central server, I'd be happy because I could just get another phone and pull the numbers off the central server. Imagine the benefits you'd enjoy if you applied such thinking to all your systems.

These cycles have been consistent throughout the history of IT. First, we had everything on one big fat machine, to which we were directly connected at each location. Then, we had everything centralized on the mainframe, with lots of remote thin clients attached. Next, we pushed everything out to fat clients again, with very little on the server (the fat machine has gone from a mini-computer to a PC). After that, we have pushed everything centralized back to the server again with very thin Web-based clients.

These cycles will continue, along with the cycles of distributed computing models. Successful IT shops recognize these cycles and design systems that can change as the cycles change. If you follow rules one-through-four, you will always be ready for these cycles.

Rule 6: Technology is not a problem

In many cases, designing, implementing, and deploying technology is not a problem. Getting people to embrace technology and understand its advantages is the hard part. It's the hardest thing IT managers do — the job is five percent technology and 95 percent communication, hand holding, and getting people to understand the vision.

Even if the change is really simple and the benefits are obvious, people need to stop their "real" work to make the change. And people fear change. Try getting all your employees to rethink the very way they use computers.

How do you make them understand that they can go to any conference room, insert their badge into a Sun Ray appliance, and start working? If they have a Sun Ray appliance at home, they can pick up where they left off, and they don't need to carry a laptop. And if they're not at a Sun Ray, they have the portal and can still get their session through a browser or Internet kiosk. Technology like this really improves users' lives, but it can be daunting to them at first.

Rule 7: Know your estimation factor

Gaining a reputation for completing projects on time is important for any executive because it establishes credibility. An estimation factor is how long you think it will take you to perform a given task. When guessing this, most people forget to factor in phone calls, meetings, approval processes, and interdependencies.

My estimation factor is four. That means when I first determine that a project will take me two weeks to accomplish — which it would if I spent 100 percent of my time on it, with no interruptions — I multiply that projected number by four, and guess what? I'm always on time.

To determine your estimation factor, you need to collect metrics over time — tracking original estimates — so you can compare them to the actual time when you deliver. This needs to be a process standard in your organization.

Rule 8: You manage what you measure

Measure only what you care about, and communicate that to everyone — your direct employees, peers, and your own management — so they understand and accept your priorities. If you don't care about cost, then don't manage cost. If you don't care about schedule, then don't manage schedule. If you are not measuring it with a metric, then you are not managing it.

At Sun IT, we care about availability and quality. I know the availability and performance of every one of my systems and gather volumes of performance data on each. And when a system is slow, I am instantly paged so I can address the issue. I track those metrics all the time, and I manage my employees by them. So my employees know what their focus should be, and my peers and management understand my team's priorities.

Rule 9: Don't let the best be the enemy of the better

This rule addresses analysis paralysis — the tendency to over-analyze. By trying to implement the world's best system, you might analyze for three years, which means you won't gain benefits for at least that long.

If you follow Rules one through eight, you won't make a bad decision. So decide what you want now and move forward. Be confident in your decision. Even if you want to add new technology later, if you base the system on open standards and separate your layers, it's easy to make changes.

For example, it's better to deploy a Java Card badge now than wait another six months until it's a 64K badge, and then wait another six months until it's a 128K badge. Even if you get twice as much memory in a year, what will you do with it? If you deploy them today, you can have session mobility and single sign-on, and start delivering these and other benefit streams. You're getting value out of technology now and can easily add on more memory or benefits moving forward.

Rule 10: Nothing in life is easy

The last rule is tongue-in-cheek. Always assume the worst from a risk-management perspective. Remember: this is setting expectations. Assume that a system is going to production and the server hasn't arrived; your project lead is leaving for another company; and users will do all the things you don't think they'll do.

Don't plan too optimistically. Assume that these are the kinds of things that are going to happen, and because there are so many moving parts, something usually does happen. As an executive, you'll be prepared and will be able to lead any type of project effectively.