Organizational change for enterprise growth: IBM had to change its organization and development processes to survive the 1990s.
Market innovation was an important aspect of IBM's turnaround. By market innovation, we refer to how the company changed the way it segmented its markets, defined compelling user needs and frustrations, and drove these into new product designs in both hardware and software. IBM moved from a transactions processing orientation for all large corporate users, to an e-business consumer and focus within specific vertical markets.
Technological innovation was hugely important. There were two distinct generations of product line architecture in IBM's mainframe renewal. The first was to replace its old 31-bit bipolar processor architecture (known internally as the H series) with 31-bit CMOS designs (known internally as the G Series). IBM's old bipolar circuits required constant electric charge and extensive cooling that, in turn, required masterful but hugely expensive engineering. These bipolar processors were used pervasively with IBM's old architecture for task management, computing, and input/output to storage devices or communication networks.
The CMOS processor architecture changed all this. CMOS integrated circuits use metal-oxide-semiconductor transistors, which consume energy only in switching transitions, and virtually no energy in wait state. Consequently, much less electricity--and cooling--was required. This reduced significantly the electrical power and physical size requirements of the first generation of IBM's new mainframes. This new mainframe architecture was introduced in 1994.
The second generation of IBM's high-end product line architecture was equally dramatic. In 1995, just one year into the launch of the new architecture and with a number of derivative product developments well underway, IBM assembled the "best and brightest" from across the company to develop an even more powerful systems architecture and marketing strategy, focused expressly on the client server, Web-centric world. Senior management named the group the ES2000 team, representing "enterprise systems in the year 2000." The team consisted largely of mid-level managers with proven records of accomplishment in technology and product line performance. They were the thought leaders in their respective fields within IBM, yet none had yet achieved executive rank in the company. Senior management felt that placing an executive on that task force might have imposed dated approaches on the rest of the team. "Turf" was set aside to create a robust growth plan for IBM's server business. The ES2000 team focused on next-generation hardware and open systems software; it completed its work in just three months, delivering a plan to senior management in the Spring of 1995.
In many ways, IBM has been executing to that plan ever since. First, new hardware and software developments were implemented in the derivative products offerings based on the new CMOS G Series architecture. Second, IBM undertook a major parallel R&D effort to create an entirely new architecture. In 2000, the company introduced this architecture, calling it the zSeries, based on 64-bit, RISC-based CMOS processors (2). IBM also introduced dynamic resource management through complex microcode, needed for the most demanding applications such as stock market trading spikes.
The combination of the new processor and resource management system made IBM's new servers very powerful. The last version of the prior 31-bit CMOS architecture introduced in 1999 provided 1,600 MIPS (millions of instructions per second) in standard configuration. The new z900 achieved 2,600 MIPS. By 2001, the zSeries cracked the 3,000 MIPS barrier; and in 2004, IBM introduced a 32-processor machine that provided 9,000 MIPS for the most demanding applications.
With the new zSeries architecture, IBM also offered Linux as a native operating system. This positioned IBM's high-end servers to use, for the first time, substantial amounts of third-party applications software developed for open systems, e-business computing. The Linux software change affected far more than product; it has had profound implications for IBM's brand, business model and partnerships. At the same time, IBM's engineers made these new servers backward-compatible with COBOL programs written for mainframe programs more than a decade earlier.
If the story of corporate renewal were to end with only innovation in markets and technology, then any firm that developed a robust market strategy and employed great engineers might succeed. However, we know that is not the case. Organization and communication processes enable innovative firms to deliver new products in a timely and efficient manner. Robust strategy is for naught without strong execution. IBM had to change its organization and development processes to survive the 1990s. In the pages to follow, we will examine the concepts and impact of these changes.
A Traditional Functional Organization
A logical question is why the G transition to CMOS did not happen 10 years earlier, 1984, instead of 1994. Many other computer manufacturers had been using CMOS to create powerful workstations and servers during the 1980s. Part of the answer lies in the design of IBM's organization and its processes. Figure 1 shows IBM's organization of mainframe development before 1993, when the company was simply not organized for disruptive, generational product line innovation.
[FIGURE 1 OMITTED]
For decades until the 1993 turnaround, IBM had maintained a strict functional organization for all its server product lines. Each product line was a division, and each division had respective departments for hardware development, software development, manufacturing, and quality control. Each department was an empire unto itself, with thousands of employees and budgets ranging upwards of hundreds of millions of dollars. Decisionmaking for big decisions was completely hierarchical. A fundamental change in product architecture--such as CMOS architecture--would require all four functional executives to agree on strategy, product design, resources, and rollout, and to adjust their budgets accordingly.
Multifunctional integration of planning, project management and development would be essential for overhauling the old mainframe architecture. However, the existing functional organization did not allow engineering staffs from different groups to work closely with one another. Teams had to be responsible for planning and integrating changes in processor architecture, electronics, networking, and operating systems, and this was simply not possible within the functional organization. IBM "program managers" tried to lead different staffs to work toward common goals, much like their counterparts in other corporations. However, without real budget or performance review authority, the program managers had little power in the traditional functional organization. Disputes would go back into the functional groups for resolution; problems involving a different functional group would work their way up the management ladder, eventually reaching executive levels. This placed executives in the role of project managers who resolved multiple crises. There are only so many problems that any single set of executives can resolve in a given week.
The bottom line was that the old IBM functional organization turned next-generation product line initiatives into "death marches." No executive would want to take responsibility for such a project unless he or she was told to do so; even then, they might try to put it on someone else's plate. Also, note that in Figure 1, marketing was not even at the table in the S/390 division. Marketing had no formal direct report to the senior executive team managing mainframes. How was the S/390 division ever going to grow beyond systems that served traditionally understood transactions processing needs?
Developing a Platform-Centric Organization
As executives running the S/390 division confronted the realities of getting from the H to the G series, they knew they needed a new organization strategy as much as a new product strategy. The separation between Poughkeepsie and Boeblingen (Germany) mainframe development organizations had to be transformed into a working partnership. Multi functional teams that owned the results of their decisions would be the driving organizational design factor. Executives would influence these teams to favor time to market over everything else. "Ultimate" or "ideal" designs would be implemented over time as a series of successive product releases.
It is easy to take a given organization design for granted simply because it has always existed and communication processes have been developed around that structure. However, products have an uncanny way of looking like the organization that makes them. If an organization is smokestack in design, it is unlikely that product lines will share common subsystems, or that specific products will even share a common architecture.
To solve this problem, the S/390 executive management team turned the IBM development organization on its head. They wanted to create three fundamental elements in the new structure: 1) differentiate between development teams for specific products and those for underlying core subsystems; 2) create a real focus on architecture, including next-generation architectures; and 3) bring marketing directly into the game to develop new product requirements. Thus, IBM created the new organization design shown in Figure 2 and generalized in Figure 3. The new design was an organizational matrix that IBM found necessary to create and leverage common subsystem platforms into specific product lines. The hardware and software products are linked to the hardware and software core technologies through a pervasive systems architecture, explicitly designed and enforced by senior management.
[FIGURES 2-3 OMITTED]
The organization design in Figure 3 illustrates a powerful organizational principle: if a business strategy relies on architecture and shared subsystem platforms, as well as products tailored to specific market segments, the organization structure must have teams focused on different parts of the business strategy. This means specific teams focused on individual products, subsystem platforms, and the architecture that integrates individual products and subsystem platforms. Otherwise, the strategy will not take root in the firm's products.
IBM had to focus explicitly on defining product line architecture. Under the old structure, the responsibility for defining and improving product line architecture was largely consensus-driven and shared across different groups. Therefore, it rarely changed. IBM attacked this problem by creating dedicated Systems Design Teams. These teams include marketers as well as technologists. The architecture they create becomes the focus of specific model development and subsystem requirements by teams in other parts of the organization. Most important, the architecture team provides the explicit technical interfaces by which all the different pieces of a complex system are attached to the overall system.
Under the old functional design, subsystem developments were not decoupled from product developments. Therefore, engineers created subsystems for their own product needs, with little explicit planning for how these subsystems might be used by other product teams. Again, this led to long development cycles for new computer products and poor cost of goods because the reuse of any given component was rare.
To attack this flaw, IBM created distinct subsystem teams and distinct product line teams. For the subsystem teams, IBM followed a center of excellence model in which responsibility for a major subsystem was focused and resourced to a particular development center. These subsystem teams develop modules for use by multiple product line development teams. For example, there is one cache development team developing technology for all IBM server product lines--large, mid-range and small. Similarly, there is one microcode group and one microprocessor development group working toward different delivery requirements of the server product lines. In addition, IBM formed a central Linux Technology Center.
Product line teams provide subsystem requirements to these subsystem development teams at the front end of development, and later, integrate the engineered subsystems back into their own products. The product line teams then develop the value-added programs and integration needed to produce their final products. IBM typically offers about 25 models for each new version of its high-end servers.
Decoupling next-generation R&D for a given subsystem from an imminent product launch is an important risk management strategy. For example, the microprocessor R&D team started development of the Blueflame processor (a 64-bit CMOS processor) at the same time that a product line development team was working on the G6 (which used the existing 31-bit CMOS processor). The Blueflame was "ready for prime time" a year later for the new z900. By then, it was fully tested and stable. Similarly, IBM's first Linux port was done in 1998 on a G5 processor but first deployed two years later in the z900.
Empowering the Program Manager
To help integrate product line development teams and subsystem teams, IBM created empowered program managers. While these teams report to a single executive, they are matrixed to product line directors and subsystem directors. The program managers are the "glue" between platform subsystems and specific products. Real people are behind the communications process. Executives must enforce the discipline expressed in an organizational structure. In IBM, there is zero tolerance for nonconformance by any particular e-server model to the base architecture for the product line. In other words, senior management makes the architecture stick.
IBM also created an Integrated Portfolio Management Team, consisting of division executives with responsibilities for marketing, finance, product line development, and subsystem R&D. It is explicitly multifunctional and is responsible for the division's P&L. It selects its target market applications, balances resource allocation between current and next-generation projects, and enforces the discipline of the organization structure and its processes.
IBM implemented these organizational changes decisively in the S/390 division, literally over the course of six months. In 2003, the company took its reorganization to the next logical level: the consolidation of activity across all server groups (including the AS400 division in Rochester, Minnesota and the RS6000 division in Austin, Texas). Even the storage systems group, historically its own entity and developing its own technologies, is now viewed as another type of server and has been integrated into this new structure. Going forward, all servers and storage systems will share many technologies and common subsystems.
Two Phases of Growth
We have described IBM' s renewal in two distinct phases. The first phase was to create a much needed CMOS architecture, replacing bipolar circuitry. While the target market application remained largely the same, high-volume on-line transactions processing, CMOS was the platform that would allow IBM to achieve the new levels of price/performance needed to regain market share. The second phase of IBM's renewal focused both on a much more powerful, scalable hardware architecture (64-bit CMOS and the Intelligent Resource Director), and on a new software strategy that featured Linux. While IBM was executing on the first phase of its turnaround, it was also planning and starting R&D on the next phase of growth. Management had learned its lesson all too well; it could not afford to let the G series "run out of gas" before developing its next generation of servers.
From a strategic perspective, IBM's second phase of growth focused on new market applications. These new market applications were new functional uses for the technology by largely the same set of customers--very large corporations. These new uses included client server enterprise software, data mining and business-to-business Web-centric transactions.
Rarely can a corporation undertake complete renewal "all at once." A phased approach makes even the most difficult challenges more manageable.
Planning for Enterprise Growth
IBM's zSeries is a story of market-driven innovation, even though on the face of it, one might just see faster processors, complex microcode and Linux. The zSeries and Linux were not the result of single customer, opportunistic product development. The ES2000 team identified sweeping changes occurring across distinct market segments, comprising thousands of corporations and tens of thousands of users, and translated these into very specific hardware, software and service requirements for the zSeries and its related product offerings. Today, IBM's executive Integrated Portfolio Management Teams are constantly searching for new user needs and competitive activities in their target markets and channeling the implications of these findings into the organization.
To meet the marketing challenges of leveraging technologies to new market applications, executives must, at a minimum:
1. Assign a multifunctional team to do the planning (3).--If it is only R&D that identifies new segments and customer needs within those segments, the rest of the corporation will typically be reluctant to embrace the strategy (even if it is the correct strategy). IBM's ES2000 team had mid-level managers from across the company, with different skill sets and industry experiences.
2. Require the team to look at the industry and competitive dynamics, and talk with users.--The first step toward gathering these data is to create a growth-oriented market framework. This type of pragmatic segmentation of current and potential markets should be based on three key dimensions: 1) the potential users of the company's products, 2) how or for what purpose they use the products, and in certain instances, 3) the channels through which they purchase the products. If there are no new segments on that market framework--current users and users that the company does not yet serve--the team must think some more.
Then, within this new segmentation of users and uses, gather data on total sales volume, segment leaders, the company's own position, and new competitive entrants, and portray it in an easy-to-understand manner. Talking to users, actual or prospective, remains essential--too many development teams rely on consultant's reports, the company's advertising agency, or the traditional wisdom from corporate marketing. Instead, teams must "go to ground" with users.
Much has been made of identifying and observing the activities and behaviors of "lead users." We have seen the powerful insights generated when team members from different disciplines--engineering as well as marketing--participate in that activity. It is these insights that drive exciting new product designs (4, 5).
Teams also too often ignore the experience of their sales-force in developing growth strategies. Seasoned sales staff can quickly share user frustrations with the company's current products and the strengths of competitors' products. Strongly consider assigning a senior account executive to your next-generation product development team to lend a dose of reality and urgency to its efforts.
3. Require the team to consider new channels as well as brands.--For many firms, channel competencies can be just as powerful as technological competencies, and serve as a lever for entering a new customer segment, or to bring new functionality or problem solving to existing customers. In IBM's case, the primary target customer remained the Fortune 400 corporation. IBM could use its own direct sales force with training on the new applications. In other cases, however, a company must consider new channels for the new market application. For example, EMC, the storage systems leader and an IBM competitor, has been developing new smaller-scale storage systems for small businesses. Its own direct sales force channel is well suited for large corporations. To gain access to small business users, EMC signed a distribution agreement with Dell Computer. In some industries, developing a new channel can be even more complex and expensive than developing new technologies.
The same applies to brands. A planning team has the responsibility for understanding the attractiveness of current brands for new target market applications (6). New products for new uses, branded and marketed in the same old way, often fail to excite customers. IBM reconstructed its marketing programs to do justice to the combination of the zSeries architecture and Linux, and to reflect its belief that these technologies would fundamentally enable business competitiveness. Innovation teams in consumer products should also consider their current store displays and other forms of merchandising. These can be just as much in need of renewal and innovation as the product itself!
4. Require that the team not shy away from defining new business models if warranted by the new market applications.--We find much confusion about the term "business model" in industry. A business model is neither a strategy alone (e.g., target users, uses and products for them) nor is it simply a projected statement of income and cashflow. Rather, it consists of the essential factors linking a strategy with the financial outcomes of that strategy. These factors typically include where revenues begin and how they ramp; the products and services of the business, and how one charges for or prices products and services; the size and changes to operating margins with volume; the time to achieve profitability and how that profitability improves over time; the stages of capital infusion; and the return on these investments expected over time. New business development teams should create their projected pro-forma financial statements only after carefully considering these key factors.
5. Require the team to work fast.--The ES2000 team completed its work in three months! Russell Ackoff observed that most corporations often take too long to develop their corporate strategies (7). By the time the strategy is "done," market and competitive conditions have changed, making the strategy out-of-date. The desire to achieve the "perfect" gets in the way of accomplishing the "good." To plan enterprise growth by necessity means to plan it fast, to rapidly develop prototypes for in-use market testing, and to launch the first versions of the new product line within a reasonably short period of time. Then the company can adjust its strategy and refine its products based on actual market learning.
Managing the Technological Dimension
IBM's renewal is representative of basic principles of organic, next-generation technology and solutions development. While these principles are relatively easy to identify, implementing them takes creativity, persistence and leadership.
1. Develop platform-focused architectures, and products based on those architectures, that use common subsystems and manufacturing processes.--IBM has become a truly platform-focused company (8,9). It considers the subsystems, and the interfaces between subsystems, as its basic platforms. The product architectures for different-size servers and storage systems use these common platforms. Common subsystems also translate into large-volume procurements of the components used within those subsystems and other types of lower variable costs in manufacturing. Reuse, higher-volume procurement, and larger production runs help drive down the cost of goods. Management can use that cost-of-goods advantage to offer lower prices to customers or maintain prices and offer more money to channel partners. IBM has found that robust product line architecture has allowed it to more rapidly leverage its technologies in microprocessors, microcode and operating systems to new market applications.
IBM is not the only company that does this: consider Honda (with its engines), Gillette (with its blades) and large services companies such as State Street (with its back office processing systems that serve hundreds of mutual funds).
2. Be receptive to working with new technology partners.--In IBM's case, vendors of the Linux operating system and software programs that operate on Linux have become important new technology partners. Similarly, pharmaceutical companies seeking enterprise growth are on the constant hunt for new research partners, just as consumer products companies seek new suppliers of product designs and materials.
3. Create balanced system design in your design teams.--Balanced system design has become a distinctive competency of the IBM server development team. Balanced systems design means that when IBM's engineers increased the speed of the microprocessor, they knew that they had to also increase the speed of the cache memory, and the throughput of its Input/Output adapters. Doing one without the other can degrade systems performance and lead to systems failures in high demand situations (10). This may seem obvious to the reader but during the critical years of the 1990s, the rest of the industry was focused primarily on adding more and more microprocessors to their respective systems. In high-volume applications, this additional microprocessor computing capacity chokes the other important subsystems in the machine. IBM lives in the world of high volume. Its studies have found that users push zSeries servers on average to 75 percent of capacity, and that spikes occur frequently, particularly in the financial services industry.
4. Create a safety value for cutting-edge innovation.--IBM's R&D managers decided early to create a safety valve for technical risk in its new computer processors. This was microcode. Also known as firmware, microcode consists of computer instructions that are permanently inserted into processor chips. These programmed chips complement the general purpose microprocessors within the computer. For example, the instruction set for the initial CMOS processors in the first G series and the earliest zSeries computers did not have all the capabilities specified in their respective design documents. However, IBM's engineers delivered that capability by adding special code to the general purpose microprocessors. Then, as each product line evolved, the functionality of that special purpose microcode was introduced into the instruction set of each respective microprocessor. If your company wishes to continuously develop best-in-class solutions, and also employ common subsystems, you must find your own way to incorporate "the latest and greatest" technology without jeopardizing the common subsystems upon which many product lines rely.
5. Work hard to keep your installed base across multiple generations of technology.--This was part of the magic of IBM's turnaround during the 1990s. IBM's management insisted on binary compatibility for customers' software programs across multiple generations, e.g., the H, the G and the zSeries. For example, a bank can run a decade-old S/390 database application on its new, open systems, Linux-based z900 server today. This also makes it easier for that same bank to try a new Linux-based solution, such as customer service on the Web. Achieving binary compatibility across multiple generations of a product line requires good architecture and tremendous attention to detail. Within IBM, this was one of the great technology challenges in the product line renewal.
Organizational Redesign: Prelude to Effective Innovation
This is perhaps the hardest for the R&D executive. Yet, IBM managers will tell you that the traditional organization itself was one of the great barriers to product line renewal. IBM's products lend themselves naturally to shared subsystems, a strong architecture to integrate these subsystems, and market-driven, value-added engineering to create final products. It made sense for IBM to have distinct groups responsible for each of these respective entities.
These changes go directly to the heart of IBM's development activities. The assignment of managers and staff to platform groups, architecture groups, and product development teams is largely full-time. IBM invests substantial time and effort to make these organizational units integrate their needs and technology roadmaps. This communication is enforced by program managers working between groups. IBM's team structures and the communications processes between teams represent a distinct organizational strategy.
While this organization might seem obvious to some readers, implementing these changes in a decisive manner required courage and conviction on the part of senior executives. If R&D executives wish to foster organic enterprise growth, they must first have a clear organizational strategy that suits the products that they wish to create. All too often, corporations seek enterprise growth by creating new business units that work outside the mainstream of the company's activities. More often than not, such units start with great fanfare but then become orphaned within a year and are starved for resources when the time comes to scale up manufacturing and distribution. We believe that new product line development for new market applications must become the business of the corporation, not a side-show.
Perhaps most important, company executives must be committed to putting the company's best minds to work on enterprise growth. The team needs to possess that special combination of industry experience, technical brilliance and market shrewdness required to develop and execute a robust growth strategy. If the team comes up with answers that challenge the corporation' s conventional wisdom, senior management must hear it out and give the proposals careful consideration. If the team succeeds, it should be rewarded substantively and visibly. This makes revenue-generating innovation a goal to which employees aspire for career advancement. IBM's current CEO, for example, was the shepherd of Linux and the new business model it represented for IBM during the late 1990s as the leader of IBM's Server Business. Many of the mid-level managers who comprised the ES2000 strategic growth team in 1995 proceeded to become senior executives in various parts of the corporation.
We encourage readers to take heart and find encouragement from IBM experiences. IBM was the most traditional of companies and was literally on its deathbed. It saved itself by its own market insights and internal R&D. Once an insular technology culture with hard-to-scale bipolar processors and proprietary operating systems, IBM transformed itself with an entirely new architecture based on CMOS, dynamic and scalable resource management, and open systems software. Managers at IBM will tell you, "If we did it, you can do it." Vision, teamwork, and a commitment by executives to face up to reality and place careful strategic bets on new technologies and new market applications are the essence of innovation that drives enterprise growth.
References and Notes
(1.) Meyer, M. H., Anzani, M. and Walsh, G. Innovation and Enterprise Growth. Research- Technology Management July-August 2005, pp. 34-44.
(2.) IBM, S/390, AS/400, RS6000, zSeries, e-business, and e-business infrastructure are registered trademarks of IBM. Solaris and Java are trademarks of Sun Microsystems.
(3.) Wheelwright, S. and Clark, K. Revolutionizing New Product Development. New York: The Free Press, 1992. (In particular, see the chapter on "heavyweight teams.")
(4.) Von Hippel, E. The Sources of Innovation. Oxford, England: Oxford University Press, 1988.
(5.) Leonard, D. and Rayport, J. Spark Innovation Through Empathic Design. Harvard Business Review Nov Dec 1997, pp. 102-113.
(6.) Aaker, D. Should You Take Your Brand to Where the Action Is? Harvard Business Review Sep/Oct 1997, pp. 135 143.
(7.) Ackoff, R. Re-Creating the Corporation. Oxford: Oxford University Press, 1999.
(8.) Meyer, M. and Mugge, P. Make Platform Innovation Drive Business Growth. Research-Technology Management January February 2001, pp. 25-39. Meyer, M. H. and Lehnerd, A. The Power of Product Platforms. New York: The Free Press, 1997.
(9.) Johnson, H. T. and Broms, A. Profit Beyond Measure, New York: The Free Press, 2001.
(10). Deming, E. Out of Crisis. Cambridge: MIT Press, 1982.
Translating Technology into a New Brand: e-business
Market development is the hidden genie of next-generation product development. New products branded and marketed in the same old way tend to fail to excite customers. To complement these new open-systems servers, IBM fundamentally changed its marketing programs and created a new brand, dubbed "e-business." Since IBM sells solutions, this change had to occur at the corporate--not division--level.
Lou Gerstner asked staff to reexamine IBM's product positioning and promotional activities in light of the changes in the company and its marketplace.
He was prepared to place $1 billion on the table to build the new brand. First, however, management wanted to improve how that money was going to be spent. All divisions would have to work with one instead of 100 advertising agencies, and through this, the single, consistent, global e-business brand would be enforced. This was to be as big a change for career marketing veterans as any of the new systems architectures developed in R&D.
The marketing team also decided not to copyright "e-business." Other computer companies could use the term in their own marketing. In fact, IBM hoped they would, thereby building credibility around the brand even as it would spend heavily to preserve its image as the brand leader. Most companies would have pursued the more traditional route of protecting brand identity. Within five years, Hewlett Packard's brand became "eServices," Compaq's "non-stop e-Business," Oracle "the engine of E-Business." EDS created an e-business solutions unit, Intel's marketed its "e-Business" efforts as driving the Internet economy, and Microsoft started plugging "the Business Internet."
The snowball effect was far greater than the IBM marketing team could have predicted. In fact, within three years of the e-business brand launch, IBM found itself having to differentiate. In 2000, the company launched "e-business infrastructure" and allocated another $300 million to this campaign. The brand has been further enhanced with an "e-business on demand" campaign.--M.M., M.A. and G.W.
Marc Meyer is director of the High Technology MBA Programs and the Matthews Distinguished University Professor at Northeastern University in Boston, Massachusetts. He was a 2002 recipient of the Maurice Holland Award from the Industrial Research Institute for the best article published in RTM in 2001 ("Make Platform Innovation Drive Enterprise Growth," coauthored with Paul C. Mugge). Meyer is writing a new book on strategies and methods for leveraging platforms to new market applications (forthcoming from Oxford University Press.) He holds an A.B. from Harvard and an M.Sc. and Ph.D. from MIT in the fields of business and technology management. email@example.com.
Mark Anzani is the vice president of zSeries Hardware Products at IBM in Poughkeepsie, New York. He is responsible for the development and launch of the hardware products within the zSeries portfolio, comprising IBM's large-scale servers. He holds a degree in electrical engineering from the University of Bath (United Kingdom).
George Walsh is the vice president of On Demand Systems Environment at IBM in Poughkeepsie, New York. He is responsible for delivering IT solutions that assist customers in creating efficient, flexible and resilient IT infrastructures. He is also responsible for managing the Advanced eBusiness Council, which IBM uses to understand future customer requirements and
|Printer friendly Cite/link Email Feedback|
|Author:||Meyer, Marc H.; Anzani, Mark; Walsh, George|
|Date:||Nov 1, 2005|
|Previous Article:||Formulating optimal R&D portfolios: here's a simpler version of a rigorous method for generating portfolios that minimize risk for a given level of...|
|Next Article:||Craig takes crash course in time management.|