When David Zink became Blue Cross & Blue Shield of Rhode Island’s CIO in July 2002, he found an IT department that couldn’t get out of its own way. Like a football team that can drive to the five-yard line but can’t score, the IT department could never quite finish its implementations. There was a lack of direction and a lack of organization. Different groups worked on similar projects for different departments, solving the same problems over and over, and no one could tell Zink why. IT just jumped whenever the business units asked it to, without even asking how high.
Not surprisingly, project deadlines were always slipping and departments such as sales and marketing began pursuing their own solutions. That, of course, produced a proliferation of unintegrated systems and applications.
It was a vicious cycle, says Zink, as IT was pulled away from new projects to cope with outlier apps and systems that it could neither support efficiently nor integrate effectively.
Blue Cross & Blue Shield of Rhode Island’s (BCBS of RI) then-CEO, Ronald A. Battista (who stepped down last May and was replaced by James E. Purcell), and COO Richard Farias knew that the IT department had problems and offered Zink carte blanche support in transforming it.
“If there’s one key to becoming an agile IT department,” says Zink, “it’s top-management support.” Without it, he says, the company’s various departments would forever be fighting over IT resources and further fragmenting IT’s focus.
So Zink wasn’t interested in incremental change. He didn’t want to rock the boat; he wanted to sink it and build a new one. He began the transformation by firing vendors that weren’t providing support, leeching the company’s budget. He outsourced day-to-day IT operations, including the help desk and application development, to Perot Systems. He established a governance organization for monitoring the contract with Perot and developed an architectural plan that would migrate BCBS of RI from its aging, closed, proprietary systems to an open architecture. He brought in new project management methodologies. He introduced discipline to the processes of developing business cases for IT projects and defining requirements for new applications.
“We took on the whole world of IT and tried to improve our capabilities across the board,” he says.
“Now we have a working relationship with everyone,” says Zink. “We have input on everything. We’re able to deliver much faster because we’re totally integrated with the business.”
Zink understood that to restore the business-side’s confidence in IT and make his department agile, he had to look at a broad spectrum of IT functions. BCBS of RI and many other CIO (U.S.) 100 honourees reworked different aspects of their IT departments — including staffing, architecture, software development, vendor management and budgeting — to make them more nimble, responsive and, ultimately, valuable to the enterprise.
Training an agile staff
An incident early in Douglas Caddell’s now five-year tenure as CIO of law firm Foley & Lardner LLP underscored for him the importance of familiarizing IT employees with the pressures and nuances of a client services business.
One day around 4:30 in the afternoon, an engineer Caddell had hired received a call from a tech support person in Foley’s Washington, D.C., office. He couldn’t get the printer to work, and an attorney needed to submit a filing to a judge by 5 p.m. The engineer told the support person that he’d work on the problem first thing in the morning. The attorney went ballistic. If he didn’t submit on time, his client would be in violation of a court order. The engineer, however, didn’t know that.
When the story got back to Caddell, he came up with the idea for Foley’s Technology Orientation Program (TOP).
“We created the TOP program to get back-room people like programmers, analysts and engineers from the national office into a practicing law office so they could see what our business is about,” says Caddell. Now by their third or fourth week on the job, technology workers new to the national office in Milwaukee are sent to one of the company’s larger regional law offices for a week. They meet with all of the administrative departments such as word processing, document management and loss prevention, library services, office services, litigation support, accounting and HR (areas they’d never deal with let alone see in the national office) to learn what those departments do and how they use technology to do it. About 25 per cent of their time is spent in these meetings, says Linda Sanders, director of tech support in Foley’s Los Angeles law office. The rest of the week they work alongside the local office’s technology staff, repairing broken or malfunctioning equipment, going on support calls to attorneys’ desks, and setting up videoconferencing — all so that they can experience firsthand the pace and pressures of the business. Employees who go through TOP have to fill out a 10 question survey summarizing what they learned and providing feedback on the program.
By exposing IT workers to the deadlines attorneys are under, their high expectations and the gravity of the matters with which they deal, Caddell hoped to create an agile, high-performance IT department that could turn on a dime, set and reset priorities and develop initiatives that would streamline work processes and enhance the relationship between Foley and its clients. (The experience also helped IT employees understand that every hour an attorney can’t work equals a loss of US$300, the company’s billable rate.)
Having a deep understanding of the business also enables the IT department to develop innovative applications such as its automated conflict checking system, which, in a matter of hours, makes sure that Foley has no prior relationships preventing it from taking on a case. Systems such as this help Foley differentiate itself in a highly competitive industry. For example, one of Foley’s clients was so impressed by the firm’s ability give it a quick answer on potential conflicts (as opposed to the days that it took other firms) that it hired Foley to work for its other business units.
Building an agile architecture
Four years ago, an unreliable IT infrastructure was the Achilles’ heel at Golden Gate University (GGU), a private San Francisco-based school geared toward working adults. Weekly network and server failures that caused the university’s e-mail and ERP systems to go down for hours at a time crippled GGU and prevented it from achieving the goals it had laid out in a turnaround plan — such as providing access to enterprise data through a Web browser, letting students apply for admission and register for courses online, and offering classes on the Web. How could students or administrators trust the network (and the university) if it was always crashing?
The network and server failures resulted from the lack of real architecture supporting them, just a hodgepodge of unstable, unintegrated legacy systems and platforms. GGU hired Anthony Hill as its CTO in August 2001 to chart a robust and extensible path for IT. Hill implemented a Linux-based open architecture that would make the IT department more productive by focusing it on a single set of technologies. And that, by virtue of its stability and extensibility, would enable the university to add the networked services it needed to attract students.
Hill chose a Linux-based open architecture because of its low total cost of ownership and lack of vendor lock-in. “Open source makes me more agile by giving me a choice of hardware and a global community of support that we don’t get through vendor solutions,” says Hill. Additionally, by standardizing on one operating system, his staff can deepen its expertise in that area. And having a deeply skilled IT staff, a global community of support and lots of different development tools from which to choose means that the IT department can respond more quickly to change and to the university’s needs. For example, since moving to the open architecture and the Linux OS, Hill says his IT department deployed the notoriously complex Oracle 11i ERP suite, relaunched GGU’s Web site, and upgraded its networking and database infrastructures faster and with more quality than it would have been able to do two years ago. “Right now, I think we’re delivering seven to 10 times more projects with the same number of people than we did two years ago,” Hill says. “Obviously, if we can deliver more projects faster, that allows the business to achieve its goals faster.”
Programming the agile way
Since Acxiom Corp. began experimenting with grid computing in 2000, the giant customer information aggregator increasingly relies on agile software development methodologies such as extreme programming (characterized in part by continuous testing of small coding improvements), rapid application development (contingent upon the reuse of software components), joint application development (involving the end user in design and development) and iterative development (in which changes are made constantly throughout the development process).
“We don’t go off and plan requirements on our own for a year and then build software for three months,” says Terry Talley, the senior technical advisor in charge of Acxiom’s grid initiatives. “That’s the old waterfall model of software development that’s largely discredited in the industry.”
In particular, iterative and joint development, wherein programmers regularly produce new releases of software in close collaboration with business users, provides Acxiom with a number of ways to achieve agility, says Talley. The two methodologies foster close alignment between business users and development staff, and they enable developers to address users’ needs and requirements for an application as soon as they surface. They also enable geographically dispersed teams to work on different parts of a software program at the same time using a variety of open source tools, such as an online repository where developers can study requirements, report bugs and check in code.
Rapid, iterative and joint development also facilitate the easy reuse of code, which speeds up the process. For example, when a developer has to build a Web service, he can simply go to Acxiom’s Web-based software library and check out the lines of code that make Web services secure and reliable so that he doesn’t have to rewrite those functions and thus can focus on coding for the desired functionality, whatever it may be.
“Incremental improvements and iterative development cycles all play into our ability to deliver quickly,” says Talley.
Each of Acxiom’s 25 to 30 development teams decides which agile software development methodology it’s going to use to write a particular application (or piece of an application) based on the team’s skills and the staffing or time constraints it may be under. For example, to develop a job-scheduling application in the C++ language, one of Acxiom’s technical unit leaders opted for the pair programming approach when he realized his team didn’t have the perfect mix of skills. He had people who understood job scheduling, but in a mainframe environment, not a C++ environment. Conversely, he had staffers versed in C++, but not in job scheduling. So he paired the engineers who had previously worked on job scheduling apps with engineers knowledgeable about C++. Thanks to this approach, the team met its deadline and created quality code in a first release.
“Delivering software is important to our business, and we must manage that development environment so that we’re always making progress,” says Talley.
Keeping your vendor agile
In preparation for outsourcing 650 employees in eight functions including claims processing, IT operations, telecom administration and application development to Perot Systems Corp. on June 1, 2003, BCBS of RI CIO Zink established a governance team to monitor Perot’s performance. While the governance team is similar in purpose and structure to outsourcer oversight organizations at other companies, it was set up expressly to react with agility to changes in the business and to get those changes reflected in the contract.
Zink appointed eight different BCBS of RI executives to monitor Perot’s performance on a daily basis in each of the functional areas. These BCBS of RI executives track more than 125 metrics — such as the number of claims outstanding, the length of time it takes to pay a claim and network response time — to see if there are any deviations from the norm, good or bad. They also monitor 50 service-level agreements (SLAs) that have financial penalties attached if Perot fails to meet them. Each of the BCBS of RI executives oversees someone from Perot. And Zink meets with his team and representatives from Perot on a weekly basis to review status reports.
The governance team also facilitates changes to the contract and SLAs as the business changes. For example, in October 2003, BCBS of RI changed an SLA pertaining to the number of points Perot could earn for processing claims between different states’ Blue Card plans. The Blue Cross Association had shortened the amount of time that members were given to pay claims; the SLA was changed to reflect the new rules.
Budgeting for agility
In 2002, at the height of the corporate scandals and the economic downturn, when Merrill Lynch & Co. Inc.’s business was taking a hit, the company embarked on a restructuring of its IT operation. IT had been set up in vertical silos across Merrill’s three business groups: asset management, institution and retail. Each of these businesses had its own IT staff and assets. As a result of this decentralized structure, Merrill didn’t get any economies of scale purchasing IT; redundancies of technology, people and processes proliferated.
Merrill decided to centralize IT into a global services organization and to deliver it to the business as a utility. In other words, each business group would tell IT how much computing power it needed, and IT would charge the business on a monthly basis for what it used.
John Cummings, Merrill’s senior vice-president, chief information and services officer, and head of global technology and services, says the utility model provides a mechanism for throttling IT services — such as storage and processing power — up or down depending on business demand. The agility comes in because it “allows the businesses to change the pricing and the internal profit-and-loss dynamics of their businesses so they can respond much more quickly to changes in the marketplace,” says Cummings. For example, if a business unit decides to phase out a product that consumed a lot of storage or processing power, Merrill now can transfer that IT capacity to another area of the business that’s growing. It can reuse the technology rather than having resources dedicated to supporting a now-obsolete product.
Before IT could begin sending bills to the business groups, it needed to explain to them how IT was charging them and what they were being charged for. IT named this awareness effort Cost Transparency Now.
Each bill that IT sends out consists of a macro view of the business’s total technology costs and breaks down the total cost into details — such as the exact technology assets and resources that were consumed to support say, Visa transactions, and what each of those assets and resources cost at a unit level. “Cost Transparency Now converts very deep and complicated technology functions into volumes and transactions and unit costs that are meaningful to a business group,” says Cummings.
Clarian Health Partners Inc., a consortium of hospitals, has a different approach to funding its 21-person Department of Business Innovations, which combines IT, business process reengineering and procurement staff, and is charged with reacting quickly to new opportunities and challenges. The Department of Business Innovations’ budget is divided between two areas: projects that will enhance patient care and projects that will streamline physicians’ work, according to Tal Moise, vice-president of the department and co-CIO. Except for a requirement that a portion of Business Innovations’ budget must go to patient care and a portion to physicians, the department determines what projects it’s going to undertake within those two categories based on Clarian’s needs. It’s not locked down; the budget is not fixed. “This gives us a great deal of flexibility. When a new event takes place, or a new market opportunity comes up, we can simply apportion those dollars to the appropriate location,” says Moise.
Because the Department of Business Innovations has the authority to decide what specific projects to focus on, it could react quickly to the effects of a new Indiana law that pertained to organ donors. Before the law was passed in mid-2003, family members of organ donors who had died had the right to veto their loved one’s decision to donate organs. The new law took away that veto. Suddenly, there was a 30 percent increase in the number of hearts, lungs and other organs coming into Clarian’s transplant lab. The lab couldn’t cope. But within two months (and for under US$30,000), Business Innovations built a system that automated Clarian’s process for matching donated organs with needy patients.
Agile IT for agile business
From one IT department to another, no matter what the industry or mission, the message is always the same: To become agile, everyone in IT has to understand the business inside and out. IT can’t stay on top of business needs, or react quickly to new market opportunities, if it doesn’t know or understand the business drivers. And just as the IT department must foster flexibility and responsiveness across a number of disciplines inside IT, companies have to promote that same flexibility and responsiveness across all their business units. Giving a stodgy business an agile IT department is like giving a fish a bicycle. There’s nothing like bureaucracy to put the kibosh on agility. Agility has to be the mantra of the the company at large, and as BCBS of RI’s Zink says, it has to be supported by the top executives.
According to Zink, you know you’ve completed the transition to an agile IT department when the business doesn’t even think of moving in any direction without IT’s input.
“I have a tremendous working relationship with my peers,” he says. All the other senior vice-presidents and vice-presidents come to IT for help. “Before (the transformation), they never would have thought of IT. They would have thought of ways to avoid IT.
“Today, they don’t do anything without us.”
