Leadership: Three CIOs Come Up With the Rules Of IT

We are taught from a young age about rules. Kindergarten is chock-full of rules that are supposedly all you really need to know. Rules apply to every segment of life thereafter—school, dating, taxes, meetings, the workplace. Follow directions. Wait your turn. Keep your hands to yourself. Clean up your own mess. File on time.

The fact is, all IT departments have rules. Whether posted on the company intranet, embossed on a coffee mug, or unspoken yet understood, rules are meant to set expectations, influence behavior and promote team play. Just as in kindergarten.

Many CIOs today have created their own set of IT rules, written them down and pushed them out to their staffs. Some lists are very specific—targeting governance, alignment, capital expenditures and vendor selection. Some are more conceptual—translating the CIO’s vision for IT into concrete, actionable principles. Others use humor to sort out serious subjects such as network security, technology standards and risk management.

Regardless of what they call their IT rules or how they publish the rules, these CIOs consider their rules a critical piece of their leadership strategy. The 10 rules that Bill Vass, senior vice president and CIO of Sun Microsystems, has promulgated guide his IT staffers in both their day-to-day work and long-range planning. “IT is very complex, and people need a predictable environment to work in,” he says of his CIO Essentials, which he developed while working at the Pentagon. His not-so-subtle message to Sun’s IT staffers: If you follow these rules, you’ll never be in trouble.

The 13 Golden Rules that Ron Bonig, executive director of technology operations at George Washington University, wrote for his department use straight talk and a bit of humor to allow staffers larger parameters in which they can make decisions on their own. “I can’t be there all the time,” Bonig says. “You have to empower them with a set of rules.”

Rules help Dow Jones CIO Bill Godfrey close the gap between IT and the business. “I needed to have some mechanism, some framework to promote ongoing alignment,” says Godfrey, who rolled out his Big Rules in 2004. “All of the rules in one form or another are there to sustain, protect and foster alignment.”

Some CIOs, however, take a different view of rules for IT. “I have seen other CIOs who have done these rules,” says one longtime CIO who requested anonymity. “They tend to be mocked by their employees.” It’s very hard to write effective rules, says this CIO, and they tend to decompose into just another company policy or manual that is soon forgotten.

CIOs who have embraced IT rules acknowledge this challenging fact of corporate life. “Simply having rules on a website is not the same thing as having them integrated into your climate,” says Godfrey.

Therefore, CIOs should follow a few rules themselves before they roll out their own: Balance rigor with flexibility. Avoid clich¿ Remember that rules are part of a strategy—not the strategy. Never miss an opportunity to talk them up. Above all, however, CIOs need to set a good example for their employees. Vass jokes that his staffers will occasionally catch him about to break one of his rules on project prioritization. “You have to live by your own rules,” he says.

Bill Vass, Sun Microsystems:

Essentials for Successful IT Operations

In spending most of his formative IT years at the Department of Defense, Vass got to see the best and the worst of IT projects in a technology portfolio that encompassed 6,200 systems. He investigated why the top 10 percent of projects succeeded and why the bottom 10 percent did not. His CIO Essentials sprang from those experiences.

Vass wasted no time in implementing his rules at Sun when he got the CIO job in 2004. They were posted on the corporate portal, and he talked them up at staff meetings at every opportunity. The rules, he says, are in order of priority. (As he acknowledges, his rules dovetail quite nicely with Sun’s open-systems strategy.)

If his staffers follow them, they can’t go wrong, Vass says. “For example, if you’ve done everything that’s on there, you can’t make a wrong vendor selection. Because if you’ve followed all these rules, the [systems are already] open.”

That said, Vass’s rules aren’t set in stone. “Everything is a living document,” he says. “You have to measure whether the rules are being effective.”

Bill Vass’s CIO Essentials

Rule 1 Open systems succeed.

This rule has been true from the beginning because open systems are standards-based. Of course this is good for Sun because we’re an open-systems company. But I’ve also watched many open systems succeed in scale and continue over a long life span. As an executive who approves or influences technology purchases, don’t you want to guarantee that your systems will scale to meet new demands?

When I was in government, I spent all my time on two types of projects: projects that were over budget, behind schedule and all messed up—or projects that were ahead of schedule, on time, with happy users and under budget. And in almost 100 percent of the cases, the good projects were based on open standards because only they had the flexibility to scale and the flexibility beyond being locked in to one vendor.

Rule 2 Proprietary systems fail in the long run.

The second rule is the opposite of the first. Proprietary systems don’t scale. To accommodate any unplanned growth, they must be redesigned in the end. And they always cost more in the long run. Proprietary systems were the single greatest waste of IT dollars I saw in those 6,200 government systems.

To use a construction analogy, imagine every IT system starts off based on plans for a house but usually grows into a skyscraper. If you build on open systems, you have a strong foundation on which your systems can grow to accommodate new business and user demands. Importantly, proprietary systems usually cost three to four times more than open systems over their life spans.

Rule 3 Separate logical layers.

This is a key insight into a major cost driver in system lifecycle cost, and it’s a technology decision you have to make early. Spend a little extra time up front to separate your technology layers: presentation, business logic and data. By separating them out in the beginning, you are ensuring that each can scale and change independently.

Rule 4 Standards matter.

These days especially, this rule is really important. Companies with written programming and process standards will succeed, because they’re following standards and open systems, meaning they can meet new technology [needs] with minimum effort. This was true on a mainframe, and it’s still true today. This also gives you the internal flexibility to seamlessly move resources from one project to another without huge ramp-up times.

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: Their functionality was very thin but is now getting bigger. And as bandwidth becomes more pervasive, functionality will get even thinner again. This cycle applies to all technology and should play a factor in your technology decisions. Such cycles have been consistent throughout the history of IT and 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 5 percent technology and 95 percent communication, hand-holding and getting people to understand the vision, and [taking] the necessary steps to help people overcome the fear of change.

Try getting them to rethink the very way they use computers by “seeing” or visualizing the benefits before considering what changes are needed to achieve that benefit. Technology 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 a project will take me two weeks to complete—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.

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 measure cost. If you don’t care about schedule, then don’t measure 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. I track those metrics all the time and manage my employees by them so they know what their focus should be, and our management understands 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 overanalyze. 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. Get value out of your technology now, but ensure you can scale it for greater benefits in the future.

Rule 10 Nothing in life is easy.

The last rule is tongue-in-cheek. Always assume the worst from a risk-management perspective. 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 what can go wrong will go wrong, and plan accordingly. As an executive, you’ll be prepared and will be able to lead any type of project effectively.

Ron Bonig,

George Washington University:

Axioms to Empower the IT Staff

In keeping with their name, Bonig’s Golden Rules are short and memorable maxims. He never misses a chance to preach his gospel—at meetings, in e-mails, in conversations. “We don’t have a chart on the wall,” he says, “but you repeat them, you leverage any moment and talk about them.” That way, his staff of 140 knows exactly what’s important to the department and George Washington University, especially Rule 1. “Lots of them get wrapped up in the new,” he says. “We have to remember our first job: to keep everything in production running.”

Bonig believes the biggest benefit of the rules has been a sense of empowerment among his staff and a morale boost. “As long as you operate in these parameters, you will get your job done,” he says. “We can correct any honest mistake.”

Ron Bonig’s Golden Rules

Rule 1 Production is job number one.

Rule 2 The first part of job number one is to “protect the data.” Backups are sacred. Even scheduled production can be interrupted to get a clean backup.

Rule 3 Nothing I say regarding deadlines, projects or special initiatives should ever be construed as permission to deviate from Rule 1 and Rule 2.

Rule 4 Standards and procedures are your safety net. If you follow them, you can be virtually guaranteed that no mistake you make will cause a disaster (the procedures include peer review, testing and validation).

Rule 5 If [you don’t document it,] it didn’t happen. Keep it online and in several places. If you write it down on paper, it’s obsolete before the ink is dry! (Especially for documentation, configurations.)

Rule 6 The most important part of the plan is the back-out strategy. If it all turns to “soup,” you can get back to a steady state if you have planned it.

Rule 7 There is no such thing as an inconsequential change.

Rule 8 Never say no to a user—just put a price tag on the yes.

Rule 9 Nobody is indispensable…but all the systems administrators are forbidden to cross the street at the same time.

Rule 10 To borrow from Mark Twain: “Put all your eggs in one basket, then guard that basket!”

Rule 11 And to also paraphrase von Clausewitz: “No plan survives intact the first contact with the users.”

Rule 12 You can put the square peg into the round hole, but you have to use a big hammer. It is easier to recruit and hire for the skills you want in the first place.

Rule 13 It’s only money. If it is critical, we’ll have a bake sale.

Bill Godfrey, Dow Jones

Guidelines to Bridge the Alignment Gap

Godfrey’s IT rules had their genesis in a couple of tough years for his department and Dow Jones’s ad revenue streams, in which IT struggled with a very heavy project load and a fast pace of change in the business. Cost management and project execution were both primary goals for Godfrey, even as demand for IT functions was still outpacing what he could supply. His list of Big Rules, he says, “was an attempt to hold chaos at bay.”

So far, so good. Senior Dow Jones management has welcomed IT’s push into stricter IT governance and better business alignment. “We’ve been invited to lead,” says Godfrey. “But leadership comes with expectations, and we need to get stronger.” He insists that this is just version 1.0 of the Big Rules. In the works now is version 2.0, which will detail organizational strategy and how IT can be woven into the fabric of the company. “Just because I have rules, doesn’t mean we’re done,” Godfrey says.

Bill Godfrey’s Big Rules for IT Service Governance

Rule 1 Strategic Planning

¿ All technology divisions will have a documented technology plan.

¿ All technology divisions will have published goals and objectives.

Rule 2 Production Prioritization

¿ Production problems classified as Severity One take resource precedence over all else. Management and staff will work on Severity One problems immediately and continously until resolved.

Rule 3 Enterprise Architecture

¿ All technology divisions will have a documented high-level architecture.

¿ All technology divisions will adhere to infrastructure standards or seek exception approval.

¿ All technology projects costing more than $250,000 total must be approved through the Early Look Architecture Zoning process prior to capital approval submission.

Rule 4 Project Management

¿ [There will be] 100 percent adherence to the Dow Jones (DJ) project management process for all nontrivial development projects (projects estimated to take more than two weeks of staff time).

¿ All development projects will have a specifically identified business sponsor and a specifically identified technology project leader prior to initiation.

¿ All development projects requiring infrastructure support will directly involve infrastructure support staff during project initiation, giving the infrastructure staff an opportunity to directly participate in the design of systems solutions.

Rule 5 Time Management

¿ All staff time will be appropriately entered into the IT time reporting system on a weekly basis.

Rule 6 Technology Business Management

¿ As represented in approved budgets, technology costs will not exceed plan unless explicit approval is granted by the CIO.

¿ Technology contracts will be managed and approved through business management services.

¿ All third-party contractors [and] consultants will sign non-disclosure agreements [and will be] managed under the non-employee security policy and through the DJ preferred vendor program.

Rule 7 Capital Approval Management

¿ All projects will adhere to corporate expenditure authorization processes.

¿ All projects are required to have appropriate IT senior leadership team sign-offs prior to business line submission.

¿ For all projects requiring CIO approval, all staff work and IT senior leadership team approvals will be complete prior to seeking CIO approval.

¿ Any project with a total cost of more than $250,000 will be submitted to finance for formal business case review.

Rule 8 Requesting Proposals from Third Parties

¿ All requests for proposals from third parties will be reviewed and approved by the CIO prior to execution.

¿ All requests for proposals from third parties that could have DJ infrastructure implications will be reviewed and approved by technology engineering services prior to execution.

Rule 9 Relationship Management

¿ Business technology directors are 100 percent accountable for all technology, direct and indirect, in support of their business lines.

¿ Business technology directors “own” all business application vendor relationships.

¿ Enterprise technology directors “own” all infrastructure vendor relationships.

Rule 10 Infrastructure Management

¿ Enterprise infrastructure services is 100 percent accountable for the DJ global infrastructure.

¿ Enterprise information services is the only organization that makes infrastructure decisions.

¿ Enterprise information services owns and manages all infrastructure capital.

Rule 11 Compliance with Audit, Regulatory and Legal

¿ Information technology services will comply with all audit, regulatory and legal requirements.

¿ The IT senior leadership team is accountable for compliance.

Rule 12 Operations Procedural Compliance

¿ [There will be] 100 percent compliance with [the] enterprise change control policy and procedure.

¿ All production applications will be supported by a service-level agreement.

Rule 13 Information Security

¿ All technology staff will comply with the Dow Jones information security policy.

¿ Information security approval must be secured prior to implementing new technology or making major enhancements to existing technology. This review and approval is to take place before any formal or informal obligations are made between DJ and a supplier.

¿ All credential and access management to a financially significant application will be managed and controlled through information security.

Rule 14 Sarbanes-Oxley Compliance

¿ [There will be] 100 percent compliance to all Sarbanes-Oxley controls.

¿ All IT leaders will be thoroughly familiar with the IT general control policies [regarding] governance, project management, operations, access control and data management.

¿ All IT leaders, supervisor and above, are responsible and accountable for Sarbanes-Oxley compliance across their respective areas of control.