Rule 4: Standards Matter
Especially these days, this rule is 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
Technology is cyclical. Take cell phones, where functionality was very thin, are now getting fatter again. As bandwidth becomes more pervasive, they 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 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 “The” 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% 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. Remember, even though you know technology generally improves users’ lives, 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 a project will take me two weeks to accomplish — which it would if I spent 100% 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 based on your 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.