www.hbrreprints.org

HBR CASE STUDY AND COMMENTARY

How should Peachtree try to fix its IT infrastructure problem?
Four commentators offer expert advice.

Too Far Ahead of the IT Curve? by John P Glaser .
•

Reprint R0707A

Peachtree Healthcare’s patchwork IT infrastructure is in critical condition. Should the CEO approve a shift to risky new technology or go with the time-tested monolithic system?

HBR CASE STUDY

Too Far Ahead of the IT Curve? by John P Glaser .

COPYRIGHT © 2007 HARVARD BUSINESS SCHOOL PUBLISHING CORPORATION. ALL RIGHTS RESERVED.

Freshly showered and cooling down after their squash game, Max Berndt drank iced tea with his board chairman, Paul Lefler. Max, a thoracic surgeon by training, was the CEO of Peachtree Healthcare. He’d occupied the post for nearly 12 years. In that time the company had grown—mainly by mergers—from a single teaching hospital into a regional network of 11 large and midsize institutions, supported by ancillary clinics, physician practices, trauma centers, rehabilitation facilities, and nursing homes. Together, these entities had nearly 4,000 employed and affiliated physicians, who annually treated a million patients from throughout Georgia and beyond. The patients ranged in age from newborn to nonagenarian; represented all races, ethnicities, lifestyles, and economic conditions; and manifested every imaginable injury and disease. Many of them, over the course of a year, would be seen at more than one Peach-

tree Healthcare facility. Max’s marching orders were to ensure quality, consistency, and continuity of care across the entire network—and to deliver all that with the highest levels of efficacy, economy, and respect for patients and staff. Max, still sweating lightly, finished his tea and ordered more. He and Paul commiserated over the steady vanishing of squash courts in the metro Atlanta area. This particular block of four courts was located in a health club not far from Peachtree’s Marietta headquarters. Apart from the one Max and Paul had used, the other three were dark. “By next week,” Paul predicted, “at least one of those courts is gone.” In Paul Lefler’s worldview, things always happened fast. Paul was the CEO of Wyndham Trust, the region’s leading retail bank and mortgage lender. Having overseen Wyndham’s rapid growth through mergers and acquisi-

HBR’s cases, which are fictional, present common managerial dilemmas and offer concrete solutions from experts.

harvard business review • managing for the long term • july–august 2007

page 1

Too Far Ahead of the IT Curve? •• •HBR C ASE S TUDY

John P. Glaser is the chief information officer for Partners HealthCare System, in Boston; a senior adviser to the Deloitte Center for Health Solutions, in Washington, DC; and president emeritus of the eHealth Initiative, whose mission is to improve the quality, safety, and efficiency of health care through information and IT. He is a coauthor of Managing Health Care Information Systems (Jossey-Bass, 2005).

tions, he was an avid believer in brute-force standardization. His management team had honed the art of disciplined conversion, changing everything from signage to systems and processes in very short order, “like ripping off an adhesive bandage.” Squash courts weren’t the only thing vanishing from Max’s universe. So was a comfortable management consensus about Peachtree Healthcare’s long-term aims and how best to achieve them. Paul—like other board members and some in Max’s management inner circle—was applying constant pressure on Max to follow the example of others in the health care industry: Push ahead on standards and on the systems and processes to support them. “You’ve got all the hospitals doing things differently. You’ve got incompatible technology that’s held together by sweat and ingenuity and, possibly, prayer. Just do what other institutions are doing. Common systems, broad standardization… It’s the competitive reality, and it’s the right long-term play! So, what the hell are you waiting for?” But then the iced tea arrived, and Max used the interruption as an excuse not to answer Paul’s question. They’d been having this conversation for several months—sometimes informally, other times in full board or committee meetings. Max listened, to a point. Eventually, he always fell back on his clinical experience. “You can standardize the testing of ball bearings for manufacturing defects,” he said. “But as far as I know, you can’t—at least not yet—standardize the protocol for treating colon cancer.” As a physician, Max believed that the last word in all matters of patient care should rest with the doctor and the patient. But as a CEO he believed in best practices. So his compromise position was to favor selective (Max called it “surgical”) standardization. Indeed, many areas of clinical treatment—immunizations, pharmacy record keeping, aspects of diabetes care—could safely be standardized around best practices over which there were few disagreements. In other areas, though, standardized practices could have scary patient-safety consequences, and physicians had to be free to form their own judgments about which treatments were best for which patients. Lately, however, worrisome developments were eroding Max’s confidence that he could hold out against Paul’s brute-force prescription.

Remember The African Queen?
Days before, there had been a meltdown of the clinical information system at Wallis Memorial Hospital in Decatur. (Wallis was Peachtree’s most recent addition.) Since Max had been lunching with his chief information officer, Candace Markovich, when the alarm came through to her PDA, he drove her over to Wallis to investigate. On the way, Candace reprised her concerns about ensuring uptime and performance quality across Peachtree’s patchwork infrastructure. “More and more, I feel like Humphrey Bogart in The African Queen, trying to keep the blasted engine running on the boat,” she said. “So much of our energy and budget goes into just treading water. And the more we grow, the worse it gets.” At Wallis, Max saw cold panic on the faces of the IT staff as they rushed around trying to repair and reboot the system. Doctors and nursing supervisors stood around looking helpless or angry, sometimes a mix of both. Clinicians, having finally been persuaded to use information technology as a primary tool in delivering care, now depended on it to work reliably. When it didn’t cooperate, they—and their patients—were basically screwed. Now Max witnessed the routine nightmare that many doctors recoiled from. Talented, hardworking, highly paid people were being kept from doing their jobs by the toounremarkable failure of what had become an indispensable tool. Although everyone in IT was working diligently to fix the problem, diligence wasn’t enough to keep disgust at bay. Wherever Max looked, he saw pain. And yet Max was also that rarity in medicine—a physician leader who recognized and embraced the value in technology. An early enthusiast of telemedicine, he had participated in long-distance, computer-assisted research conferences and consultations on behalf of his own and other doctors’ patients. He had easily been converted to the view that computerized, consolidated patient records were vastly superior to manila file folders scattered throughout various specialists’ offices, subject to eccentric clinical and record-keeping habits. As CEO, he had shown consistent leadership in visibly championing IT-based innovation. And he enjoyed a close, positive working relationship with Candace. Even so, all he was hearing from Candace

harvard business review • managing for the long term • july–august 2007

page 2

Too Far Ahead of the IT Curve? •• •HBR C ASE S TUDY

lately was that the IT infrastructure was consuming so much maintenance energy that further technical innovation was becoming a luxury, an afterthought. At Wallis, Max had gotten to see the nature of the problem up close and personal. Luckily, the situation ended up being resolved without major consequences to patients—this time. But Max was now convinced that something urgently needed to be done. The African Queen was headed toward the rapids.

Medicine Is Different
The day after the squash match, Max sat in a budget meeting in his office attended by Candace and Peachtree CFO Tom Drane. Max wanted to know what it was going to cost to rearchitect technology across all of Peachtree’s facilities. Candace and Tom cataloged the results of a request for information Candace had put out earlier in the year. Max paid nervous attention. The combination of IT and big, hairy numbers was certainly not unheard of, but it was still intimidating, mysterious, and worrying. Moreover, it was hard for Max to reconcile the task of standardization with all the realities of the health care mission. Sometimes Max envied Paul Lefler the dispassionate nature of the banking business. No patients, only customers—and most of them just wanted something simple: a loan, a place to put their money, a way to get at it easily. Paul could choose end-to-end standardization with a clear conscience. Health care, though, was different. It was a matter of life or death. Doctors—not wizards of finance—were the authority figures of greatest consequence. Any effort to control or otherwise interfere in physicians’ duties was scrutinized in the long shadow of the Hippocratic oath. For that and other reasons, mergers were not typically a feature of market behavior among hospitals. Often when they were tried, hospital mergers failed. Each institution had its own idiosyncratic, doctor-dominated identity. Put one together with another, and you’d constructed an oxymoron—a health care “system.” Or so the wisdom went until Peachtree did its first merger and created a potent synergy between two great teaching hospitals. Now Max presided over a federation of 11 hospitals of assorted sizes and special purposes, each with its own proud history and culture, each

“You’ve got incompatible technology that’s held together by sweat and ingenuity and, possibly, prayer. Just do what other institutions are doing. Common systems, broad standardization.”

with its own weird mishmash of IT systems of various vintages and vendor pedigrees. Soon, depending on just how much standardization he ultimately decided to pursue, Max was going to rock the whole boat either a little or a lot. Presently under consideration were proposals for what Candace called monoliths— massive systems running massively ambitious enterprise software that would compel the arduous redesign of every business process. The hardware and software, she explained, “are the tip of the iceberg costwise. It’s everything that comes next that makes this so expensive.” Tom reached across a small conference table and turned the page in a three-ring notebook assembled for Max’s edification (Max was famously scornful of PowerPoint). “Looking at benchmark data for implementations of comparable size,” said Tom, “you see there’s potential for the cost to multiply two or three times over budget.” Max admired the way Tom could convey a thoroughly terrifying possibility without betraying the slightest vocal stress—the CFO version of bedside manner. “Really?” said Max. “Two or three? Depending on what?” “Mainly on consulting services,” said Candace. “The time it takes. How hard it is to change the processes, get buy-in, roll out the system without too much scope creep, train the people, make customizations, fix problems that crop up after implementation.” “The good news?” asked Max. “It can work,” said Candace. “It gets the job done. It leaves us with a brand-new homogeneous infrastructure, a single set of systems and applications, complete interoperability and consistency across all of the hospitals, a unified patient records database. Unified everything, really. It’s like we become a single institution with multiple campuses.” “Okay,” said Max, looking now at Tom. “Is there a number you’d like to leave me with?” “Five hundred million to a billion,” said Tom. “Spread out over five to seven years.” “But it could be more?” Tom shrugged. “It could. But I’m comfortable with a billion at the high end.”

Caveat Emptor Everywhere
On an evening a few weeks later, in mid-July,

harvard business review • managing for the long term • july–august 2007

page 3

Too Far Ahead of the IT Curve? •• •HBR C ASE S TUDY

Each institution had its own idiosyncratic, doctor-dominated identity. Put one together with another, and you’d constructed an oxymoron—a health care “system.”

Candace appeared at Max’s door, obviously in the grip of a fresh enthusiasm. Max was trying to get out of the office for his son’s tenth birthday celebration (the boy already regretted his summer birthday, because most of his friends were scattered to family vacations and camps). “Five minutes,” said Max. “It’s Teddy’s birthday.” Candace proceeded to take nearly ten. “As you know, we’ve been goofing around some with SOA,” she told him, pronouncing it “SO-wuh,” a gentle-sounding locution that suggested a seaweed wrap at a Japanese spa. “Nothing too intense, just some prototypes to get a feel for it. My view has been that it’s a couple of years away from being ready as an option we’d have a lot of confidence in. But maybe there’s a way to manage the risk of being more aggressive.” Max understood service-oriented architecture in a limited way. It was the latest hyperbolic promise of technology magic, a way of parsing information systems into modules that perform discrete services. Built out of reusable strands of programming code, these modules could be reconfigured, Lego-like, into new applications at a diminishing future cost. With Max’s blessing Candace had funded some SOA experiments; the results had been mixed but still were encouraging in the proof-of-concept sense. “What’s good is that this would give us a lot of agility. We could easily change a system. We could try something out on a limited scale and move forward in small steps to keep the risk lower. But the thing for you to bear in mind is that SOA gives us the flexibility to go after selective standardization. It’s not a my-way-orthe-highway kind of deal.” Max nodded, intrigued. Nevertheless, he remained standing and edged toward the door— he had to stop at the bakery on the way home to pick up the cake his wife had ordered. Candace talked faster. “The problem is, the SOA market’s not mature yet. There’s a lot of unpredictability. The vendors are still feeling their way along, and the risk for us is we become a victim of their—and our own—steep learning curve.” After a couple of further ambiguous upside and downside observations, Candace released Max. In the car he continued processing the conversation. It was the devil you know versus the one you don’t. But the thought of surrendering on the question of selective standardiza-

tion continued to nag at Max—it was a choice with huge implications for the indigenous clinical cultures of Peachtree’s original parts. A monolithic system would render the surgical approach difficult to the point of impossibility. But SOA might blow up in everyone’s faces, leaving Peachtree with selectively standardized chaos that was scarcely better than what existed today. At the bakery Max was impressed by the colorful sheet cake. It was tomahawk themed for the Braves—Teddy was a big fan of Andruw Jones.

A Femur Meeting
At Max’s urgent behest, Candace presented the pros and cons of the SOA option to a small strategy task force, whose deliberations would inform Max’s recommendation to the board of directors. They met in a 12th floor conference room known as Femur (all of Peachtree’s meeting spaces were named for least-disagreeable body parts, mainly bones). “No choice is perfect,” Candace said by way of introduction. “But who knows? Maybe there’s something here for us.” At a meeting two days earlier she had sketched out the monolithic system, scaring everyone with its price tag. The team had originally been impaneled to give more shape and detail to Max’s goal of surgical standardization. It had made progress toward identifying best-practice opportunities and flagging areas where physicians and institutions should—for now, at least—be left to their own devices. At the outset of this process, Max had framed what for him was the key issue: “We could declare that everyone in this building will from now on wear uniforms,” he said. “We’d then have an office-wear standard, but what would be the point? Standardization has to be seen in the context of something gained. Do no harm, right?” But now the whole strategy was up in the air. Max firmly believed that Peachtree’s best long-term bet—exemplified by his cautious approach to standardization— was to preserve at all costs the hospitals’ flexibility to respond to constant change. But Paul Lefler and others saw his caution as timid. Their view was that only by creating a thoroughly unified institution would Peachtree shed its legacy, premerger shackles. Besides Max, Candace, and Tom, the team

harvard business review • managing for the long term • july–august 2007

page 4

Too Far Ahead of the IT Curve? •• •HBR C ASE S TUDY

Max firmly believed that Peachtree’s best longterm bet—exemplified by his cautious approach to standardization—was to preserve the hospitals’ flexibility.

consisted of the COO, presidents of two of Peachtree’s hospitals, and the president of the Peachtree Healthcare Foundation, the company’s nonprofit research arm. Candace moved quickly through her formal briefing, careful not to dive too deep, so there would be time for questions at the end. Tom asked who else in the health care industry was aggressively adopting an SOA strategy. “No one that I’m aware of,” she said. “To be honest, that’s one of the reasons key vendors are eager to work with us. They want to get some health care cred. On the one hand, that motivates them to be flexible on pricing. On the other, it makes us the guinea pigs.” Max listened as Candace laid out the risks and uncertainties. SOA was new and had no industry track record, she said. “So it’s very hard to estimate with any reliability what a given unit of progress will cost, how long it will take to achieve it, and how close the resulting service will come to performing the way we intended it to. The concept of SOA suggests that it’s less expensive in the long run than the monolithic system, but we don’t have any data from other health care institutions to prove that. So you can’t rule out that it might end up

costing the same.” Max found himself wanting Candace to be just a little more upbeat on SOA. She’d incited him to think about it, and now he was beginning to wish he’d never heard of it. “So, why would anyone bother with it now?” he asked her. She proceeded to share the Candace Markovich Theory of the IT Future: SOA was potentially the migration path to a transformative way of creating technology capability. “I really do believe that’s true,” she said. “So you can imagine how it might not totally thrill me to think about spending a bazillion dollars on a brand-new, shiny dinosaur that we’d be stuck with at a point in history when the IT world is moving someplace else. That isn’t a choice I’d want to have to make. But I can see the logic in making it, because SOA is still kind of a crapshoot.”

How should Peachtree try to fix its IT infrastructure problem? • Four commentators offer expert advice. See Case Commentary

harvard business review • managing for the long term • july–august 2007

page 5

Too Far Ahead of the IT Curve? • HBR C ASE S TUDY

Case Commentary by George C. Halvorson

How should Peachtree try to fix its IT infrastructure problem?
Major systems projects are hard enough to support when your head of information technology is fully and enthusiastically on board. In Peachtree Healthcare’s situation, a risky business case is being hesitantly recommended to senior management by an IT chief whose strongest positive feeling is that it might work. The proposed technology is untested in a health care environment, the cost load is undetermined, and the benefits are uncertain. It’s pretty hard for a CEO to bet the farm on a major systems initiative that has no obvious upside or business case for implementation. The fact that the current systems environment at Peachtree Healthcare is clunky and marginally functional should cause the systems staff to look for a better approach. But building a plan that uses untested methodology in a pioneering rollout effort is not a good decision— particularly because the stakes in a health care work environment truly can be life or death as well as financial. So, what should happen next for Peachtree Healthcare? For starters, Max Berndt and the rest of the company’s senior managers need to envision exactly what they want to accomplish with their systems. They also need to be closely involved in developing and finalizing that vision. Clear intent is essential, coupled with an equally clear strategic pathway to achieve that intent. The Peachtree IT-planning process skipped that step and started with a tool rather than a desired outcome. The right approach for the organization’s leaders is not to implement something and then see if it works. It is to figure out exactly what they want their systems to do and then construct a plan for achieving those goals in a reasonable time frame and at an affordable cost. In health care today, there are a few elements that must be included in any major IT plan. Extremely high levels of systems availability are an absolute necessity. Completely computerized clinical information will soon be essential, too, as will the ability to track care performance and patient outcomes. But standardizing care into a particular set of protocols is not a current necessity. Paul Lefler, the nonmedical board chair at Peachtree Healthcare, is eager to standardize care—in part because standardization has created efficiency, cost savings, and higher-quality products in settings outside the health care industry. In some operational areas, that kind of standards-based thinking can be transferred to health care delivery; in other areas, however, it is entirely premature. Why premature? Because the evidence needed to insist on standardization isn’t there yet for many areas of care. Some of the best thinkers in American health care are now working on an initiative to have 90% of health care decisions based on best medical evidence by the year 2020. If that is the goal, the evidence now available is not sufficient to use a computer to force standardized care on physicians. So the CEO of Peachtree is right in resisting rigid standardization. That said, the company’s systems should include a database that will allow for tracking of care performance—both to identify which care delivery approaches work best and to ensure that those that don’t work are identified and can be corrected. Overall, the Peachtree team needs to go back to the drawing board. The company is definitely not ready to go down the serviceoriented architecture path that the CIO has so tepidly recommended. It can do a lot better by starting with a broad vision for its systems results and then building a complete plan to achieve each objective within that vision. Systems in a health care environment should be a tool that is used to improve performance in the context of a well-considered strategy. George C. Halvorson is the chairman and CEO of Kaiser Permanente, based in Oakland, California. Over the next three years, KP will spend more than $3 billion to convert all its medical and other administrative records to digital files, linking them to electronic tools for care and connectivity.

A risky business case is being hesitantly recommended to senior management by an IT chief whose strongest positive feeling is that it might work.

page 6

harvard business review • managing for the long term • july–august 2007

Too Far Ahead of the IT Curve? • HBR C ASE S TUDY

Case Commentary by Monte Ford

How should Peachtree try to fix its IT infrastructure problem?
The first thing I would ask is, why is this Max Berndt’s decision? If the CEO can override the technical recommendation of the CIO, and the CIO’s going to have to implement whatever the CEO decides, it’s very possible there will be problems. But let’s table that question for now. One thing that’s not spelled out is Peachtree Healthcare’s risk profile. It would help to know how tolerant of risk the company is. But the fact that management is considering serviceoriented architecture when others in the health care industry have steered clear suggests some willingness to get out ahead of the curve. It’s also obvious this is a time-bound situation. The company doesn’t have the luxury of waiting for a lot more certainty; its infrastructure needs a solution now. A trap organizations can fall into is to see the choice as much more stark than it has to be. This shouldn’t be an either-or situation. Elements of both options may have value in combination. What Peachtree could do—and, in fact, what we are doing at American Airlines—is to move gradually in the direction of SOA. The company doesn’t have to make a wholesale, knife-edge change from its legacy infrastructure. Instead, it can (as Candace Markovich suggests) divide the transformation into calculated, well-prioritized chunks. Chip away at the edges of old systems and replace them over time with SOA-built services. An incremental approach not only minimizes risk but makes the project more flexible and easier to control, and it allows IT to shift priorities at logical break points. The best SOA implementations will take full advantage of the legacy system’s functionality but not just reinvent the older system in a newer SOA form. Peachtree has traded in many of its old manual core business processes for IT-supported ones. Once that bridge has been crossed, there’s no going back. Peachtree’s clinical systems are, like American Airlines’ reservation system, indispensable for carrying out the company’s mission. Doctors and patients depend on them, so reliability is crucial. Whatever approach Peachtree implements has to be operationally sound. Obviously, part of the urgency the company faces is that its current technology keeps conking out. I would reassure Max and Candace that SOA can be brought along in a way that manages down the risks and respects the need for reliability. In the end, the company must have systems that will work dependably. And an SOAbased environment that is not functionally rich is a failure. In that case, Peachtree would be better off with a monolithic system. Because the stakes are so high, the company must err on the side of getting the job done, and only then bring along the flexible systems and architecture. It doesn’t do any good to have a totally flexible architecture that either doesn’t properly address business needs or takes so long to implement that the company misses opportunities in the meantime. For an organization like Peachtree, I don’t think there’s a time penalty for either choice— it wouldn’t take any longer to get SOA up and running than it would the monolithic system. But it’s important to remember that people often start out thinking of SOA as a project. Done correctly, the “project” never ends—it just turns into the way you do business. It becomes the way your IT capability is built, and that represents long-term value. Candace should recommend that Peachtree turn toward an incremental implementation of SOA. And my strong advice to Max is to accept Candace’s recommendation. The question of how to replace which pieces of the infrastructure should come in at a distant second to the overall decision to adopt SOA. Peachtree should follow the commonsense approach of retaining what still works and adds value to the enterprise, as long as it will accommodate a modular SOA scheme. Monte Ford (m.ford@aa.com) is a senior vice president and the chief information officer at American Airlines, based in Fort Worth, Texas. Since joining American in December 2000, he has rebuilt the company’s IT function, consolidating more than 40 disparate groups and aligning all IT projects with the airline’s business objectives.

The company doesn’t have to make a wholesale, knife-edge change. It can chip away at the edges of old systems and replace them over time with SOA-built services.

harvard business review • managing for the long term • july–august 2007

page 7

Too Far Ahead of the IT Curve? • HBR C ASE S TUDY

Case Commentary by Randy Heffner

How should Peachtree try to fix its IT infrastructure problem?
Max Berndt has a clear read on Peachtree’s highlevel choices—a well-worn path of high-cost, rigid business standardization versus a new path of incremental, flexible business evolution. He senses that if service-oriented architecture can truly deliver on its promises of incremental change, it can provide the technological foundation for surgical standardization. But his CIO, by “goofing around” with SOA as a vendor-driven product category instead of looking at it as a methodology, has missed key perspectives on SOA’s maturity and its relationship to business dynamics and change management. To begin with, SOA’s industry penetration is deeper than Candace Markovich realizes. According to survey data from Forrester Research, about 60% of North American, European, and Asian-Pacific enterprises say they are now using SOA or will be by the end of 2007, including 22 of 38 public-services organizations surveyed. More important for Peachtree’s consideration is that about 40% of current SOA users say it is helping them to achieve strategic business transformation. Why does SOA garner so much credit? Its design models, when done right, are the best yet at preparing a firm’s technology to change with the company. Each major business task (like ordering a diagnostic test or entering clinical notes in a patient’s record) has a separate, simplified software interface called a “business service.” With business services—the Lego-like blocks used to construct and change processes—alignment with the business is built in; the technology and products are secondary. Some firms have for 15 years or more built software as business services, but the label “SOA” has gained prominence only within the past five years, with the rise of SOA as a product category. Candace views SOA as a product category based on emerging industry standards for connecting applications across a computer network—so-called Web services. Widespread support among technology vendors and users is creating a broad industry ecosystem of products, skills, and services. So far, only the core standards have achieved critical mass, and the market landscape is still rapidly changing. Even so, the trade publications are replete with positive user testimonials about Web services. SOAbased design does not require Web services, but their combined benefits provide strong potential for business integration and flexibility. Max’s greatest asset is his grasp of the business dynamics of health care. In the swing of the pendulum to the side of efficiency, the ruthless standardization option risks limiting doctors’ choices too much. By contrast, SOA’s modularity provides a range of standardization choices. For example, a single business service for clinical notes could accommodate physicians’ different note-filing preferences— whether doctors want to enter patient information directly on a computer or dictate it for later transcription. Another big risk of ruthless standardization is that it requires an all-or-nothing approach to replacing Peachtree’s existing software. SOA would allow Peachtree to replace only the most broken parts of its existing technology base. Retrofitting older systems with businessservice interfaces is generally much cheaper than replacement. The benefits of broad standardization depend largely on the success of one large, multiyear project. The best approach with SOA is a series of small but independent projects within an overall portfolio of improvement initiatives. This provides many opportunities to assess, adjust, reprioritize, and redesign along the way. Furthermore, after SOA-based systems are implemented, the organization can continue to improve them. SOA’s business design models are the best match for Peachtree. They will allow the company to manage the risks of business and technology change (including SOA’s own risks). Max should direct Candace to redo her decision analysis and strategy planning, looking at SOA through a business lens. Randy Heffner (rheffner@forrester.com) is a vice president at Forrester Research, where he covers technology architectures for computer-based business systems. Formerly, he was a chief architect at Sprint, where he led the development of component technologies that are forerunners of service-oriented architecture.

By “goofing around” with SOA as a product category instead of looking at it as a methodology, the CIO has missed key perspectives.

page 8

harvard business review • managing for the long term • july–august 2007

Too Far Ahead of the IT Curve? • HBR C ASE S TUDY

Case Commentary by John A. Kastor

How should Peachtree try to fix its IT infrastructure problem?
One of the problems facing Max Berndt is all too familiar to leaders of health care systems: To what extent can or should the work of physicians in the various hospitals be standardized? Max and his colleagues will probably be frustrated if they try to herd doctors into a corral made of the latest computer technology. Many students bent on careers in medicine see a future in which they will work for themselves and control their professional lives in a way unlike their friends in other careers. That vision was a reality generations ago, but today it is a seldom-realized fantasy. Very few doctors work in solo practice—most are either in private groups or employees of medical schools or large networks like Peachtree. Having lost the mom-and-pop character of practice administratively, doctors adamantly protect independence in their relationships with patients and in their other day-to-day activities. Most did not enter medicine interested in, or equipped for, administrative responsibilities. Unlike Max, many do not want to run a company and will rebel against the regimentation that they see as a part of the corporate culture. Within a health care system like Peachtree, consisting of community hospitals and major teaching institutions, the terms of employment take several forms. Many of the doctors in the teaching hospitals are probably members of a “practice plan,” a multispecialty group practice controlled by either the medical school or the teaching hospital. These doctors—each of whom, we can assume, has an appointment in a clinical department of one of the medical schools (such as medicine, surgery, pediatrics, or radiology)—are salaried, perhaps with a bonus based on clinical productivity. They have chosen this form of work because they want to participate in the teaching programs of the medical school, in some cases perform medical research, and care for their patients in a well-known institution and with the collaboration of talented colleagues. Most of Peachtree’s facilities, however, are not teaching hospitals. They are community hospitals, established by citizens and doctors to provide health care for their communities, and are probably structured as not-for-profit corporations. Most of the physicians who admit patients to this kind of hospital are self-employed. Some—particularly in hospital-based specialties such as radiology, emergency medicine, and laboratory medicine—may be employed by the community hospitals directly or by contract with private group practices. Given the differences in how Peachtree’s doctors are employed, and considering how they value their independence, one can understand how difficult it would be to persuade them to follow regimented patterns in their work. The transition to a computerized system for charting clinical information presents a problem to those charged with establishing a workable IT strategy. Younger doctors who are well versed in computer technology will have less difficulty accepting such a system. Older doctors who are not particularly computer literate will have a harder time adjusting. Making the work of doctors more computer compatible is only one factor that management and the board should consider. They must accept that many physicians will resist applying sophisticated technology to their dayto-day activities. Peachtree should not attempt to change the essential features of how doctors work in its community hospitals. That spark of independence still glows in the psyche of many doctors, and trying to regiment them will only increase its intensity. John A. Kastor (jkastor@medicine.umaryland.edu) is a professor of medicine at the University of Maryland School of Medicine, in Baltimore. He is the author of Mergers of Teaching Hospitals in Boston, New York, and Northern California (University of Michigan Press, 2001). Reprint R0707A Case only R0707X Commentary only R0707Z To order, call 800-988-0886 or 617-783-7500 or go to www.hbrreprints.org

The spark of independence glows in the psyche of many doctors, and trying to regiment them will only increase its intensity.

harvard business review • managing for the long term • july–august 2007

page 9