CGanesh Natarajan: Leading Innovation and Organizational Change at Zensar (A)

timer Asked: Jan 6th, 2018
account_balance_wallet $35

Question description

For this assignment, you serve as a business analyst for a company (real or fictitious) in an industry of your choice. Develop a high-level summary of the case. In addition to the high-level summary of the case, your paper should include the following:

  • How could the change management be handled differently at Zensar?
  • How successful was the implementation of the new technologies?
  • How did the technologies improve economic performance within and outside the organization?

Include an introduction, conclusion, and references page.Include at least five scholarly or peer-reviewed articles. Please follow APA format and your paper should be at least 4 pages in length.

CGanesh Natarajan: Leading Innovation and Organizational Change at Zensar (A)
CGanesh Natarajan: Leading Innovation and Organizational Change at Zensar (A)
9 -4 1 2 -0 3 6 REV: OCTOBER 21, 2014 MICHAEL TUSHMAN DAVID KIRON Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) On a hot Indian afternoon in February 2005, 47-year-old Chief Executive Officer Ganesh Natarajan was about to meet with his top management team to discuss changes to the organizational structure of Zensar, a Pune, India–based IT software firm with $76 million in annual revenues. The team had been planning to consolidate staff and resources into three business units: Application Portfolio Management, Business Process Outsourcing, and Enterprise Application Services. Natarajan was going to suggest a fourth business unit, a proposal that he knew would be controversial. He believed this additional business unit would enable the firm to explore new markets for the company’s most promising innovation, Solution BluePrint (SBP), a software development framework that, among other things, automatically generated software code. Zensar project teams had already used SBP to improve productivity by as much as 25% on some projects. Although SBP was a process innovation, which helped software developers produce higher-quality code—it also promised to transform Zensar’s service offerings, interactions with customers, and the firm’s positioning in the global IT market. SBP had also helped Zensar acquire new customers and was playing an important role in ongoing negotiations for a new multimillion-dollar account with a large British retailer. Natarajan anticipated that some would resist his proposal. Zensar’s U.S. sales executives were not yet comfortable with the stability and scalability of the current version of SBP. Existing customers were less than enthusiastic about experimenting with an unproven technology. And, the person who had led SBP’s development efforts and would likely lead the new business unit, Chief Technology Officer Dilip Ittyera, was widely viewed as having managerial instincts that were no match for his technical skills. Even so, Natarajan was anxious to place SBP technology in the field as quickly as possible. Nothing else seemed more likely to spur adoption of SBP than having a dedicated business unit and no one seemed better equipped to sell the new technology than Ittyera. Natarajan explained that Zensar’s future was inextricably tied to growing SBP-related business activity: For the past four years, we have been trying to develop something that will give us a “different point of view” in the market. At the start, it was not clear SBP would be that difference maker. But now it’s clear. We just need to figure out how to organize ourselves to make this a commercial success. Some executives may object to making a business unit out of a ________________________________________________________________________________________________________________ Professor Michael Tushman and Senior Researcher David Kiron, Global Research Group, prepared this case. HBS cases are developed solely as the basis for class discussion. Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management. Copyright © 2011, 2014 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-800-5457685, write Harvard Business School Publishing, Boston, MA 02163, or go to This publication may not be digitized, photocopied, or otherwise reproduced, posted, or transmitted, without the permission of Harvard Business School. This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) group that is basically part of the chief technology officer’s department, has no revenues, and has limited sales experience. They will have a point. However, we cannot risk moving too slowly with this innovation. Others will surely follow us. I can’t allow SBP to wallow away inside one of the other business units and dawdle away our most precious growth opportunity. Industry Background1 The Indian IT industry climbed onto the global stage during the 1990s, expanding from $150 million in 1991 to $5.7 billion in 2001.2 Spurred by the availability of a young, highly educated, English-speaking technical workforce, India became a global technology and outsourcing hub. In the latter part of the 1990s, an expert reputation for fixing the Y2K, or “millennium bug,” that threatened the world’s computers accelerated industry growth. With the dot-com crash and the end of the Y2K problem, growth continued but at a slower pace. Spending slowdowns in the U.S., the industry’s largest market, and competition from other low-cost countries in Eastern Europe and Asia were among several factors plaguing the industry. By 2005, the Indian IT industry had three broad segments. At the low end were services such as “body shopping”—supplying overseas firms with information technology workers and contracting out their services on a short-term basis to take advantage of India’s low labor costs and large pool of engineering talent. Business process outsourcing, in which operations and business functions such as customer service were fully provided in dedicated centers, was a second, more costly set of services. At the high end of the industry were the most analytical, value-added services such as consulting and research and development. Many Indian software companies were beginning to move upmarket into consulting, business analysis, and systems integration, the traditional domains of global consulting companies such as IBM, Accenture, and Capgemini. Six players—Tech Mahindra, Wipro, Infosys Technologies, Tata Consulting Services (TCS), Cognizant Technology, and HCL—dominated the Indian IT industry. They were known collectively as the TWITCH companies. Each had annual revenues in excess of $1 billion. As a group, the TWITCH companies managed, because of scale and reputation, to attract the best talent and win the largest deals. A second tier of Indian IT companies had yet to breach the $500 million revenue mark. (See Exhibit 1 for a market breakdown of Indian IT companies.) Most Indian IT Tier 2 companies were based in Bangalore or Mumbai—e.g., MphasiS, Hexaware, L&T Infotech, Patni, Mindtree, Sonata Software, and Syntel. Some industry experts believed that these midsized, Tier 2 companies were “too late” for the big leagues, while others believed that they could compete only through lower price or by focusing on niche segments. Some observers, for instance, claimed that lower overhead and agile decision making enabled Tier 2 companies to offer more competitive prices on some projects than Tier 1 competitors could.3 1 This section draws from David Garvin and Rachna Tahilyani, “Zensar: the Future of Vision Communities (A),” HBS No. 311- 024 (Boston: Harvard Business School Publishing, 2010). 2, accessed April 15, 2011. 3 Adapted from Amneet Singh et al., “‘Survival of the Differentiated’—The New Mantra of Success for Tier-2 Service Providers,” Everest Research Institute Report, 2010; and Garvin and Tahilyani, “Zensar: the Future of Vision Communities (A).” 2 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) 412-036 In 2005, two trends were forcing the Indian IT industry toward another inflection point. Macroeconomic conditions were increasing the risks of relying on a single IT vendor; in response, many larger companies were mixing Tier 1 and Tier 2 providers. “Many IT customers are looking to ‘de-risk’ their portfolio,” said Vivek Gupta, Zensar’s head of U.S. sales. At the same time, an increasing number of customers wanted their IT vendors to be close by—to handle on-site emergencies, be more readily accessible, and be more easily held accountable. As a result, near-shore outsourcing was a budding phenomenon that encouraged industry participants to establish human resource networks beyond India. Company Background4 Zensar was founded in 1922 as a tabulating machine manufacturer and eventually became a subsidiary of International Computers Limited (ICL), a U.K. firm specializing in mainframe computers. ICL was later taken over by Fujitsu. In the 1980s, the RPG Group, an Indian conglomerate, acquired a stake in the company, and in the late 1990s, a software subsidiary was established. In 2000, the hardware business was sold off, and the software subsidiary, after receiving additional private equity funding, was listed on the Indian stock exchange. With its 30% stake, RPG retained management control of the new company, renamed Zensar, or “essence of knowledge.” At the time, Zensar had 850 staff; most were Pune-based software engineers under the age of 25. Software Business Similar to other software firms, Zensar had a service delivery model that relied on a pool of software engineers who were put onto projects on an as-needed-basis, then returned to the pool when their part in the projects wound down. Understanding, estimating, and managing the flow of software engineers on and off projects were important to pricing and extracting profits from a given project. To price a given project, sales managers worked with delivery managers, who managed the engineers responsible for executing a project. Most contracts—especially those for maintenance and support—were based on estimates of time and materials. With some of its larger customers, such as Cisco, Zensar had annuity-based contracts and allocated engineering resources to these accounts on a long-term basis (rather than a project basis). Zensar’s engineering groups had expertise in applications (e.g., Oracle or Microsoft) and software languages (e.g., Java or C++). Software engineers included software developers, typically younger programmers skilled in several programming languages, and more experienced software designers with five to eight years of experience writing code. Software designers and architects were able to write code at a higher level of abstraction than basic software engineers. Other software engineers included project leaders, program managers, and sales representatives. Poor Timing The focus on software was poorly timed. Natarajan explained, “At the time we were listed, the industry inflexion point, which came with the millennium bug, was over. Customers already had their dance partners lined up.” The “Pune-centric” firm quickly began to suffer severe financial problems. The company’s CEO, chief financial officer (CFO), chief technology officer (CTO), and head of delivery soon quit—all on a single day. One manager recalled, “The culture back in 2000 and early 2001 was complacent. People were confused by the rapid turnover in senior management and lacked 4 This section draws from Garvin and Tahilyani, “Zensar: the Future of Vision Communities (A).” 3 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) a sense of purpose and direction, since the mission at the time—‘Nothing short of everything’—was vague.” Although Zensar managed to retain a few good customers and even acquired several new ones, revenues and profits had both fallen significantly. With the company reeling, the Zensar board recruited Natarajan, who had recently earned a “CEO of the Decade—Knowledge Award” from India’s Ministry of Information Technology for transforming a small Indian computer training company into a global leader. Natarajan arrived on the last day of February 2001. He discovered that many employees in the delivery centers, the bulk of Zensar’s staff, had nothing to do (51% utilization rate). Several senior team members were underperformers, including the head of U.S. sales. The company had not paid a dividend to shareholders in 16 years. A month into his new job, Natarajan began to recognize the full scope of the internal issues he would need to address. With only $5 million left in Zensar’s cash reserves, Natarajan asked himself, “What have I gotten into?” Ganesh Natarajan Natarajan grew up in a small village in eastern India near Ranchi, Bihar. His mother was a teacher, his father a scientist. On weekends, Natarajan helped his father run a volunteer milk program for less advantaged families. His early schooling was, with the exception of an English teacher, “terrible,” according to Natarajan. Natarajan’s secondary education began at a second-tier Indian engineering school. He earned top marks while obtaining a mechanical engineering degree from the Birla Institute of Technology, which was shut down for six months, in the midst of his studies, by a political movement. He later earned a postgraduate degree and a gold medal in industrial engineering from the National Institute of Industry and Engineering (NITIE) in Mumbai. In 1991, Natarajan headed a small, unprofitable, Indiafocused computer training company. He grew the firm’s revenues from Rs. 1 billion to Rs. 50 billion (roughly $1.1 billion), transforming it into a profitable firm with a leadership presence in 45 countries. Leadership qualities Natarajan, one Zensar manager observed, was a leader with a “very high emotional quotient” who knew each individual “360 o.” She recalled that when her mother was ill and she wanted to resign, Natarajan refused and suggested that she take as much leave time as necessary, a period that ultimately amounted to two months. A senior manager added, “Ganesh has a genuine interest in the people, in their families, and in what their non-work talents are.” Another noted, “He has the ability to connect with people at all levels of the organization. He is comfortable sitting with management trainees, and equally comfortable interacting with the board.” A third manager observed, “Ganesh is a connector—he is the glue that ties together the organization.” An accomplished singer, Natarajan hosted a karaoke event on Friday nights at his home that included 10 to 15 staff. Several managers emphasized that Natarajan was very performance oriented, and toughest on those with the strongest connections to him. “After many years working with Ganesh and being a friend,” said one manager, “I still dread review meetings with him. He is very tough during interviews.” Another manager added, “Ganesh is a visionary leader who gives you lots of space. But he has a front-end style and a back-end style. When things are going well, he is participative, but when things go wrong, he can be dictatorial.” A member of the senior team added, “Ganesh has zero tolerance for political shenanigans, or anything that might hurt our reputation or is disrespectful. Once, a senior manager was making a female staff member feel uncomfortable. When she complained 4 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) 412-036 about his behavior, Ganesh fired him. You know where you stand with him.” 5 “The people who succeed at Zensar are those who reach out to others,” observed one senior manager. “Ganesh says, ‘Trust is zero or one.’ Either you have trust and work with him or you do not.” Another executive added, “He will not accept the status quo. If things stabilize, he starts asking questions. He is always pushing for change.” Growing the Organization (2001–2005)6 Soon after he arrived in early 2001, Natarajan created a 12-month turnaround plan that focused on cost cutting. He fired 120 people (14% of the workforce) and replaced three members of his sevenperson executive team with veterans from multinational IT firms. He hired new sales executives with sector expertise, rather than technical expertise. Natarajan personally spent much of his time cultivating relationships with existing customers and improving support processes (such as invoicing). Natarajan implemented a management approach, successful at his prior firm, which set a new tone of participation and involvement. His 5-F framework emphasized Focus, Fast, Flexible, Friendly, and Fun. He called each employee individually and asked, “Tell me what is so good in this company. What should we throw out and what should we keep?” Focus meant a new business model concentrated on industry verticals—i.e., retail, telecom, and utilities, as well as banking, finance, and insurance, and near-shoring activities, which also encouraged fast and flexible responses to customer demands. The shift to near-shoring activities dramatically increased the number of staff based outside Pune, and gradually shifted the revenue mix in two ways. In 2001, 90% of revenues came from body shopping, the business with the smallest margins. By 2005, body-shopping revenues had been lowered to a more manageable 60%. In addition, most 2001 revenues were generated by Punebased staff. By 2005, 70% of revenues were coming from Zensar staff based in other countries, a much higher percentage than Zensar’s traditional competitors. As the total number of employees topped 2,000 in 2005, new staff came to outnumber veterans by a wide margin. HR policies to retain and develop key employees were put into place. Innovation-oriented incentives were also implemented. Some of these were explicit financial rewards; others were tacit. The annual Vision Community (VC), a volunteer forum in which Zensar staff met outside work hours to generate ideas about the company’s direction and discuss new ideas about products, services, and processes, provided an additional way to integrate old-timers and newcomers. In 2001, Natarajan led the first VC, which involved 60 to 70 people in middle and senior management positions and helped Zensar’s new leaders set a goal of $100 million in revenues by 2004. Eventually, VCs became a companywide platform for idea generation that gave even the most junior employees a say in the direction of the company. “If you want to advance in this company, you have to participate in a VC,” Natarajan said. “You won’t get promoted unless you show interest.” The sales function was reorganized. Top sales executives focused on growing “platinum” accounts, while sales teams were divided into two groups: “hunters” focused on obtaining new accounts and “farmers” focused on managing existing accounts. In the first year alone, the new division of labor helped add 34 new clients, including U.K.-based United Utilities, Ingersoll Rand of Hong Kong, American Insurance Group, and Credit Suisse Private Banking, among others. Over this 5 As in other Indian businesses, subordinates referred to the Zensar CEO as “Boss.” This term was also used up and down the management chain. By custom, the term conveyed a sense of both friendship and deference. 6 This section and the next draw from Garvin and Tahilyani, “Zensar: the Future of Vision Communities (A).” 5 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) period, revenues nearly doubled and profits quadrupled. Year-over-year revenues increased at a rate of 30%, due in large part to billings from large accounts, both new and existing, and from the firm’s strategic focus on near-shoring activities. (See Exhibit 2 for Zensar’s revenues and profits between 2001 and 2005.) Market Positioning “We do not want to be a poor man’s Infosys,” Natarajan said. “Our goal is to become the preferred Tier 2 supplier. Our strategy is built entirely around innovation,” added one executive. “The bigger IT services companies have three advantages—they get a price premium because of their brand, they benefit from scale economies and thus have lower unit costs, and they attract better talent.” A manager described how Zensar differentiated itself: “Compared to the larger players, Zensar is more nimble and has a higher level of executive involvement. People want to know that they can pick up the phone and call Ganesh if there is an issue.” Whenever he was in Pune, Natarajan made a habit of spending a few minutes with customers visiting Zensar’s office park. “Many customers do not get to meet the CEO of the company they are buying from,” Natarajan said. “It is a quick, powerful way to connect with our customers, and it encourages them to trust us a little more.” Zensar had also applied for (and ultimately received) the highest industry certification for a software developer company—Level 5 on the Enterprise-wide Capabilities Maturity Model Integration (CMMI) standard, which rates companies on efficiency, productivity, and continuous improvement.7 Zensar became the first company in the world to achieve this international certification level at the Enterprise level.8 By 2005, Zensar had successfully transitioned from a Pune-centric business and developed a revenue stream that in large part (80%) came from high-margin businesses involving application development, support, maintenance, and testing. During a 2004 VC, a Japan-based engineer suggested the company change its organizational structure to accommodate and exploit this business shift. (Exhibit 3 outlines Zensar’s organizational structure in 2004.) After careful consideration by Zensar’s leadership, Natarajan agreed to create three separate business units. (See Table 1 for proposed 2005 organizational structure.) Table 1 Zensar Organizational Structure to Be Adopted in 2005 Application Portfolio Management (APM) Application Development Application Support and Maintenance Testing Service Enterprise Application Services Business Process Outsourcing Enterprise Resource Planning services (Oracle, SAP) Voice—customer services and Helpdesks Business Intelligence/Data Warehouse Services Finance & Accounting back office Enterprise collaboration and content management Desk Research, Data analytics and Knowledge Services Infrastructure Management Services Source: Company documents. 7 The Capability and Maturity and Model Integration index was originally created by the Software Engineering Institute at Pittsburgh-based Carnegie Mellon University. 8 Eeaswaradas Satyan Nair, “Corporate Profile: The 5-F Mantra,” Dataquest, n.d., http://dqindia.ciol.commakesections. asp/02122703.asp, accessed June 6, 2011. 6 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) 412-036 Although the impetus for change was the acknowledgment of the new business orientation of the firm, there was another, less rosy reason. Despite changes to its business model, culture, skill set, systems, and processes, Zensar’s 2004 revenues fell short of the $100 million target (set in 2001) by $24 million. Further, Zensar’s primary market differentiator, three-year-old SBP, had yet to gain a strong foothold in the organization. Although the technology was supported by the top management team, and financial incentives were given to the sales team, none of the sales “farmers” had yet to convince an existing customer of SBP’s merits. SBP was primarily a sales tool for new accounts. The technology’s strongest proponent within the organization, Dilip Ittyera, was stretched thin; he was directing internal SBP trainings, evangelizing SBP both within the organization and to the external environment, and was being pulled into sales calls whenever he visited a region. Creating Solution BluePrint (SBP) In 2001, Ittyera had been looking to return to India after working for a year for a software development product firm in Silicon Valley. Natarajan described Ittyera: “He has a brilliant technical mind, is extremely passionate about what he believes in, and can be quite persuasive. When he told me he wanted to return to India, it was an easy decision to invite him to come to Zensar.” Ittyera joined Zensar in June 2001, becoming Zensar’s first CTO, “a role that few software companies had,” suggested Natarajan. As CTO, Ittyera’s mandate was to identify new technologies to help the company differentiate itself in the market. One of his first steps was to recruit a small team from within the organization. The first member of his team was a young engineer, Biswajit, who had made a presentation that impressed Ittyera. Biswajit became Ittyera’s first lieutenant and helped identify 20 other young candidates who met Ittyera’s profile for members of the new CTO office. Ittyera said: I wanted young programming talent who had influence within their teams and had influence on Level 3 managers, a group of mid-level project managers who directly supervised most of the resource utilization at the company. I did not want seasoned people. You push those guys to the wall and they seek what’s familiar. The new guys, you push them to the wall, they will find new ways out. All of my people wouldn’t simply accept what I said. They were questioning, quick learners, self-starters, a bit odd. They did not always take instruction well, but they were friendly and affable. Ittyera’s recruitment efforts were hampered by his perception that project managers had little interest in letting go of their most talented programmers. Ittyera did not recruit any of his team members directly from delivery team managers. “Ultimately, I had to ask Ganesh to help me form the team,” Ittyera said. “He helped me get 10 people from our list. They became the core of my team.” During this period, Ittyera was reporting to Sanjay Marathe, head of delivery, the department from which he was trying to recruit most of his team. By August 2001, Ittyera had his team in place and was reporting to the new chief operating officer (COO). Solution BluePrint Ittyera and his team explored innovation opportunities among Zensar’s several technology groups, which specialized in different software applications for popular systems and applications, including IBM, Microsoft, Sun, and Oracle. These groups provided services to customers through the 7 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) delivery unit. Ittyera planned on assessing current practices within these groups, add value where he could, and introduce new technologies or innovative approaches where appropriate. “A big part of my early efforts was just encouraging fresh attitudes toward finding productivity and quality advances,” Ittyera said. Another area of focus was a technology, renamed Solution BluePrint, from Ittyera’s former company, which had become a Zensar customer soon after Ittyera joined. Solution BluePrint was a software development tool that used unified modeling language (UML) to graphically represent business processes, designs, and architecture.9 Documenting business processes was typically the first step in the software development life cycle, and was often fertile ground for software bugs. According to Zensar managers, a graphics-based software approach that effectively represented business processes was the “holy grail” of the software industry because it would reduce delivery times, increase productivity, lower costs, and improve quality. At the time, the IT industry had promised, but failed to produce, this holy grail. As head of Engineering in his previous company, Ittyera had already spent a year developing the technology (in effect, searching for the industry’s holy grail). Ittyera contrasted the new technology with conventional methods: This is completely different from the way people have developed code for enterprise applications. In conventional software development efforts, you start with a documentation phase. Most coding does not begin until all of the business activities or use cases are written down in a text format. It is not uncommon for business requirements for large enterprise systems to consume thousands of pages of text. Software designers then create a plan for writing code to allow hardware and software systems to perform these activities. Programmers will subsequently write code for what is written in these plans and documents. The convention of going from documentation to design to programming is sometimes referred to as a waterfall approach. SBP is different. Using UML, you create a robust diagram of business processes and application designs, much like an architect who creates a blueprint for a house. This is more of a civil engineering approach to software development. Suppose you are developing software for an ATM machine. In the conventional model, you document all of the things that could happen from the time you put your card in to when you get your money and a receipt. Programmers will write code that corresponds to each use case. Basically, in this role, programmers are bricklayers, writing software for chunks of sections of documentation. Lay these bricks together and you finish the project. With SBP, all of the business processes are initially mapped out in the form of diagrams, a blueprint. Our software engineers write the models that generate these diagrams. They need to think about how the diagram they are making fits in with other diagrams. You need to be more of an architect, than a bricklayer. It’s a mental shift as much as anything else. Most programmers will have some exposure to software architecture design, but the younger developers with three or four years of experience won’t have much practice with these tools. Software architects and designers have seven or eight years of experience with these tools. The benefits of SBP, the automation, can be understood this way: each SBP diagram consists of models of what the application has to do. From these models, code could be automatically generated. We are creating a library of use cases, along with corresponding diagrams, that can be automatically generated over and over again. It turns out that many use cases are the same 9 While its roots could be traced back to the 1970s, UML became a formal language recognized by such industry stalwarts as IBM only in 1997. In 2006, Gartner estimated that 10 million IT professionals around the world were using UML. See:, accessed June 17, 2011; and Andrew Watson, “Visual Modelling: past, present and future,” Object Modeling Group, n.d. SBP were early forerunners of business process modeling notation. 8 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) 412-036 across industries. Banking and insurance, for example, share many business requirements. So, our library of SBP diagrams or blueprints can be used on other projects, and will help us complete projects faster and faster as the library expands. (Exhibit 4 provides details on the difference between the SBP technology and the conventional approach.) SBP clearly had implications for how Zensar would interact with its customers. Creating an accurate blueprint of relevant business processes required close collaboration not only with a customer’s IT department, but also with the end user. Customer CTOs and chief information officers (CIOs) welcomed the involvement of the end user earlier in the software development process because software development projects were often plagued by bugs given life by incomplete or inaccurate documentation. Ittyera expected Zensar’s customers to look favorably on Zensar for creating an environment where this was possible. “We expect SBP to deepen and enhance our relationship with the customer,” Ittyera said. The SBP approach to software development also had implications for the development of Zensar’s human capital and human resource utilization. A SBP could be transformed into the code of any languages, including Java or C++, which were most common. Learning to use SBP would enhance a programmer’s skill set and understanding of business processes, even if its market value beyond Zensar was uncertain. Programmers need not wait for projects that required their preferred software language. Training would be critical to add these skills across the organization, if and when SBP were to be rolled out on a large scale. Since utilization was a significant issue for any software company that had to ramp up staff for a given project and then ramp down as the project ended, excess capacity could be utilized on SBP projects. Early Development The relationship between Ittyera and Wagh, head of sales for Emerging Territories, was critical to SBP’s early development. Both had arrived at Zensar in July 2001 on the same day and became fast friends. Ittyera worked closely with Wagh to identify features that would drive customer demand. As SBP became more stable, Wagh brought Ittyera on sales calls to potential customers to promote the virtues of SBP. By the spring of 2002, Ittyera had begun discussions with Natarajan about licensing SBP. Ittyera and Wagh put together a slide presentation that Ittyera presented to the top management team. They argued that an enhanced version of SBP could immediately solve the utilization problem faced by the firm’s Microsoft group, which was significantly underutilized. With SBP’s platform-neutral approach to software development, Microsoft specialists could be used on SBP projects. Moreover, creating this new skill set across the Zensar developer community would drastically improve productivity and utilization. Given his review of technology development opportunities at Zensar and the fact that he had worked on the technology before, Ittyera believed SBP was Zensar’s best opportunity to achieve a “different point of view.” His final point was that the license could be acquired at minimal cost. In November 2002, Zensar acquired the rights to enhance SBP and use it in its services projects for a onetime fee of $400,000, about 1% of Zensar’s 2002 revenues. For the next six to eight months, Ittyera and his small team worked feverishly to stabilize the technology. His group operated in many ways similar to a start-up. Ittyera said: People would come to work at 11:00 a.m., and we would hear complaints from other groups asking why they were getting special treatment. What those groups did not know was 9 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) that my people had been working until 2:00 a.m. We were working together, living together, playing together. I got to know their families. There were sleeping bags in the offices. We played basketball in a nearby gym at all hours. We would go out for drinks together. We became a very tight-knit circle of friends working toward a single goal. To fine-tune SBP, Ittyera and his team had to work closely with a number of groups within Zensar in order to help them test, refine, and apply the technology in the field. Several obstacles emerged within the sales and delivery functions, and among customers. Sales resistance Many Zensar sales executives were reluctant to incorporate the unproven technology in sales calls with current customers, especially with those already satisfied with the service they were receiving from Zensar. For these executives, introducing SBP would bring too much risk into their accounts. Some managers simply did not believe Ittyera’s claims about the new technology. “Dilip would frequently talk about all the great things SBP could do,” said one manager, “but it was very difficult to get him to articulate what SBP was able to do today. When it came to SBP, he overpromised. I appreciated his passion for SBP, but that didn’t mean I wanted to sell it.” SBP threatened the pricing on projects based on time and materials contracts, the traditional type of contract both within the software industry and at Zensar. Because SBP promised to cut down the amount of time and the number of people it would take to complete a job, SBP threatened to reduce revenues from regular Zensar contracts, a prospect that made many sales managers on existing accounts apprehensive about incorporating SBP into their workflow. Delivery resistance Two groups within delivery operations were initially reluctant to engage with SBP. One group consisted of 100 Level 3 project managers who had at least five to six years of experience developing software and leading project teams. They were typically the final arbiters for how resources would be used on a given project and worked closely with sales to identify staffing requirements and pricing for deals. Retaining Level 3 managers was a strategic priority. Many had doubts about the commercial viability of SBP, while the product was being stabilized during 2003 and 2004. Ittyera relied on his young staff to influence the Level 3 managers to use their resources to test and help refine SBP. The other reluctant group consisted of Zensar’s young programmers, who had spent years in school developing an expertise in a specific programming language. Learning SBP (or UML) had an uncertain professional value for them, both within the company, which had just built a Center for Excellence around Java programming, and also outside the company, where India’s market for Java programmers was strong. Moreover, learning UML required a change in mind-set to a civil engineering approach that some were unwilling or unable to undertake. Customer resistance Customers also resisted the new technology. Industry applications of UML, of the sort Ittyera was evangelizing, had been promised for several years and had yet to materialize. One customer’s comment to the CIO, “SBP will be able to do all those things when pigs fly,” clearly indicated that the customer preferred to go the traditional proven route, rather than experiment with an unproven technology. Moreover, the customer segment of a midsized company, like Zensar, often preferred to have control over its projects. The SBP tool resulted in a perceived loss of control over such projects. Further, employing SBP required an initial investment, forging new communication mechanisms, and additional training. Though the long-term returns were higher than for existing processes, SBP involved a substantial change of mind-set for the customers—which they were not ready for at the time. 10 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) 412-036 Dilip the Evangelist Ittyera had two big breakthroughs in early 2003. Ittyera convinced a group of senior Cisco executives that SBP had merit. Later that year, Ittyera’s outreach to Fujitsu in Japan bore fruit. He convinced a senior Fujitsu executive, who was on the board of the Object Management Group, an international standards organization that supported industry activities based on UML and other modeling languages, to sponsor an evaluation of SBP. The evaluation was such a success that Fujitsu created a business unit to focus on selling SBP-based services to markets in Japan and the rest of Asia. As Fujitsu outsourced SBP-related parts of this work to Zensar, SBP was made available on Fujitsu’s internal computer system. Ittyera’s team began providing SBP training sessions to Fujitsu sales and support teams in Malaysia, Australia, Singapore, and Japan. “They believed this would enhance productivity and would be a differentiator in the market,” Ittyera said, adding, The Fujitsu evaluation changed everything for us in Zensar. The moment Fujitsu set up its transmigration department and began investing money to support SBP sales, SBP became a serious thing to people inside Zensar. It earned us supporters, some of whom had been questioning how much time I was spending in Japan. As the Fujitsu arrangement took off, SBP training became a significant activity for Ittyera’s small team. The Zensar top management team supported SBP training with an incentive program that identified SBP as a key result area (KRA). Incentives were given to delivery managers to ensure that developers were trained on SBP. Incentives were also given to the entire sales team to increase sales that included SBP. Despite the incentives, SBP was not included in any new sales to existing accounts in 2003 and 2004. Training young software developers became a time-consuming, more-difficult-than-expected exercise. “SBP was an entirely different approach to software that many programmers were simply not able to adjust to,” said one delivery manager. “You had to up-skill people who had recently completed their computer science degrees. They were competent software guys, but were not prepared to conceptualize software development like a software architect. We were making software architects out of programmers. That’s a jump that can take years.” At the same time, Ittyera and other technology experts in the firm had several exchanges over how SBP was being tested. One manager from a user community testing group noted, “Dilip would tell us that SBP could do one thing. And we found that it could not. The version we were working with couldn’t pass the stress test.” A Critical Win With SBP-related sales activities increasing, Ittyera took on the role of ambassador for SBP and began traveling extensively to train sales managers on SBP capabilities. Training Zensar software developers became the sole responsibility of his small core team. By mid-2003, SBP had become more stable, and developers achieved version 2.0. A few months later, Ittyera and Wagh’s sales team used SBP to land an account with a boutique mutual fund financial services firm in South Africa. Convincing the company’s CIO was less challenging than it appeared to be at the beginning: The company had never outsourced before, never worked with an Indian firm, and didn’t know anything about us. We’re 8,000 miles away, introducing a new technology that really had passed only the proof-of-concept stage and was just becoming stable. This guy’s job and 11 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) his firm’s future depended on a successful transition between vendors. If the IT goes down, trading would stop, and their reputation would be over. But we showed him SBP, and he was so excited he told us that if we could pass a demonstration we’d get the account. The company signed an initial project with Zensar at 200,000 South African rand (about $30,000) to develop a functionality using SBP. Knowing their work would be scrutinized as never before, Ittyera’s development team documented every step along the way. Four months later, the project was completed. Impressed, the CIO of the company gave Zensar his account. At around the same time, Ittyera was working closely with Wagh’s team to secure a large account with Marks & Spencer, the British retailer. Zensar was already engaged in a few small projects for Marks & Spencer, but these were likely part of its evaluation process for a new vendor. “They were probably giving similar types of small projects to other companies to see which vendor does the better job,” said Ittyera. This account would be the crown jewel in a growing number of new accounts acquired with SBP. “We have big wins in Japan, U.S., and Europe solely because of the SBP approach,” Wagh said. By the end of 2004, several project teams were working on SBP-related projects for companies in diverse industries, including retail banking, health and property insurance, technology products, and service engineering. Thus, there were dozens of developers within the Zensar community with enough expertise to use SBP effectively in the field. Another Business Unit? One evening in early 2005, Natarajan and Ittyera were at a restaurant discussing their families, Zensar, and the future. At one point, Ittyera suggested to Natarajan that they create a business unit around SBP—it would consist of sales and delivery teams, and Ittyera’s core group of roughly 12 product developers. As the night went on, their discussion focused on several points. Despite an aggressive effort to educate sales teams, few sales executives had enough technical expertise to sell SBP effectively to new customers. Ittyera was often brought in to help pitch SBP to new customers. On the delivery side, many of the younger software developers were having a hard time learning SBP. Their computer science degrees left them ill prepared to absorb a new approach to creating software. In the new business unit, Ittyera would report directly to Natarajan for the first time and manage a small group of perhaps 20 or so primary staff, dedicated to selling SBP-related services. Ittyera would have profitand-loss (P&L) responsibilities, with corresponding targets and incentives, and would drop his CTO responsibilities; longtime veteran Vijay Gaikwad could take over as CTO. Natarajan vowed to discuss a proposal for the new business unit at the next top management team meeting. (Exhibit 5 is the business unit–based organizational structure proposed for 2005 fiscal year.) Top Management Team Meeting The team meeting was a bit more contentious than other meetings. One executive summarized objections to the idea of a fourth, SBP-focused business unit, saying: Dilip has no sales experience. Under Ganesh’s proposal, Dilip’s sales team is going to have to work with sales teams in other business units. We will have to develop rules of engagement about how his team interacts, and shares revenues, with other sales teams. Moreover, since everyone is supposed to be selling SBP, we could have tensions with his group or be in competition with his group to get technical and delivery support. I don’t know. It is not at all clear that this idea can be implemented. Dilip has done very little outreach within the 12 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) 412-036 organization, and putting him at the top of a business unit, which will require a great deal of collaboration, may not work for the firm as a whole. Another executive added: Dilip is a great tech guy, great at making presentations, but a bad manager and a risk-taker. Putting him in charge of his own business unit with P&L responsibilities is just not a good idea. Plus, Dilip has a tendency to overpromise. He might do more damage to SBP’s prospects running his own business unit than if he were selling SBP under someone else’s leadership. Sure, SBP might not grow very quickly within one of the business units. But it might fail inside Dilip’s business unit if he gets in over his head. Plus, I have doubts that the idea makes sense from the standpoint of our overall structure. As a business unit, APM represents 80% of our total revenues: the other two, 20%. A fourth business unit with no revenues is hard to make sense of. Natarajan was startled by the heated discussion. Was it a good idea to create a business unit around SBP after all? The company could take a less aggressive path toward commercializing SBP. One executive had suggested that Ittyera’s group work within the new applications management group, which was headed by a widely respected Zensar veteran who supported rapid adoption of SBP. In this scenario, Ittyera’s team would be expanded and would work on supporting delivery and sales teams across the organization. Ittyera could hunt for new large accounts with Wagh and remain an ambassador for the SBP process. Creating a new SBP-focused business unit led by someone other than Ittyera was not discussed. After the meeting, Ittyera said: I am looking forward to leading our efforts around SBP. It is a truly disruptive technology, not just to Indian IT, but the entire global IT industry. Commercializing SBP is critical to us becoming a more global IT company, and solidifying our competitive advantage here among other Indian Tier 2 providers. I have had incredible success selling it to businesses in Asia, Africa, and Europe. No one is better suited to lead these efforts than me, and I have a fantastic team that is ready to go. Natarajan walked away from the meeting thinking: Dilip is not a great manager. That’s true. But, he knows more about SBP than anyone and has been very successful in converting this knowledge into new accounts. CIOs like talking with him, and he has been a very effective ambassador for the Zensar brand and SBP. He has had P&L responsibilities before, but not on this scale. The product development group he has put together is unlike other Zensar product groups, and may not perform as effectively within another business unit. They have a different culture, and it is not clear it will be to anyone’s benefit if that culture goes away. At the same time, I do not want to be seen as showing favoritism to these guys. We need to focus our efforts around SBP. I thought a dedicated business unit would be the right way. Now, I am not so sure. 13 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) Exhibit 1 Market Breakdown of Indian IT Service Providers, 2005 Global majors Description Examples  Large, diversified global IT-BPO majors (> US$5 billion in revenues) that have established presence in India and several other global locations to serve the local markets and also take advantage of low-cost locations for service delivery. Accenture, Capgemini, Dell Services, CSC, HP, IBM  Global majors have aggressively leveraged inorganic means to grow India delivery presence. Tier-1 Indian majors  India-based service providers with revenues over $1 billion.  From their legacy strength in IT ADM, these providers invested aggressively to build an end-to-end proposition spanning consulting, IT infrastructure, IT applications, and BPO. Tech Mahindra-Mahindra Satyam, Wipro, Infosys, TCS, Cognizant, HCL (TWITCH)  These providers are also building a global delivery footprint (including onshore presence) to compete effectively with global majors. Tier-2 Indian service providers  Midsized service providers with revenues in the range of $100 million to $500 million.  Select providers in this segment developed mature delivery capabilities around select verticals and specific services and increasingly compete with global majors and tier-one India majors. Headstrong, Hexaware, L&T Infotech, Patni, Microland, Mindtree, MphasiS, Sonata Software, Syntel  Delivery footprint is concentrated largely in India; however, these providers aspire to expand to other lowcost locations. Other service providers  Smaller players with less than $100 million in annual revenues.  Includes select “specialist” providers with narrow focus on a specific service line or vertical.  Segment also includes “generalists” that are focused on small buyer organizations with a limited proposition for midsized and large buyers. Source: Applabs, Aditi Technologies, InterGlobe Technologies. Kale Consultants, QA Infotech, Zensar Adapted from Amneet Singh et al., “‘Survival of the Differentiated’—The New Mantra of Success for Tier-2 Service Providers,” Everest Research Institute Report, 2010; and David Garvin and Rachna Tahilyani, “Zensar: the Future of Vision Communities (A),” HBS No. 311-024 (Boston: Harvard Business School Publishing, 2010). 14 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) Exhibit 2 412-036 Growth in Profitability and Revenues at Zensar, 2000–2001 through 2004–2005 75.8 80.0 70.0 60.0 56.5 $ Millions 50.1 50.0 Profit After Tax 41.1 40.0 Revenue 30.0 20.0 10.0 2.0 2.2 2.9 2000-01 2002-03 2003-04 8.6 0.0 2004-05 Source: Company documents. Exhibit 3 Zensar Organizational Chart, 2004 Source: Company documents. Notes: EAG = Enterprise Application Group; CGS = Customer Solutions Group; FSlG = Financial Services and Insurance Group; WTU = Wireless, Telecom, and Utilities. 15 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018. 412-036 Ganesh Natarajan: Leading Innovation and Organizational Change at Zensar (A) Exhibit 4 Solution BluePrint versus Conventional Methods of Software Development Source: Company documents. Exhibit 5 Planned Organizational Structure beginning FY 2005 Ganesh Natarajan CEO Parmod Bhalla Chief of Operations S Balasubramaniam CFO Vivek Gupta Nitin Parab Bala V Dilip I Hiren Kulkarni Head - GOS Head - EAS Head, ROW Head - ITS BPO Source: Company documents. Notes: In this structure, the CTO reported to the COO; GOS = Global Outsourcing Services; EAS = Enterprise Applications Software; ROW = Rest of World. 16 This document is authorized for use only in Kris Michaelson's MGT579 - WIB17 course at Colorado State University - Global Campus, from November 2017 to May 2018.

Tutor Answer

School: UIUC




Zensar Company
Institutional Affiliation:


The Zensar is an IT company that was founded in the year 1922 in India. The company
started off as a manufacturer of tabulating machines working as a subsidiary of international

organizations including the International Computers Limited which a U.K company specializing
in mainframe computers. Like any other business, Zensar utilized the use of a service delivery
model that had software engineers contracted by need. The group of engineers worked closely
with the sales and delivery managers to accomplish a particular project. The company was doing
well when it was established, but the sudden turnover of the senior management left the company
on the verge of collapsing (Tushman et al 2011). The arrival of Natarajan as the CEO in 2001,
however, changed the situation due to his high experience in information technology.
Summary of the Case
Having grown up in a small village in the eastern part of India, Natarajan attended both
his primary and secondary school where he obtained top marks and later a degree in mechanical
engineering from the Birla Institute of Technology. The leadership qualities that Ganesh
possessed is what attracted the management of Zensar to consider him for the Chief Executive
position. According to other managers, Ganesh acted as a connector or glue that helped to bring
the whole organization together. The front-end and back-end styles are what Ganesh used to lead
the entire company with no tolerance to political shenanigans. The other leadership quality that
Natarajan possessed was the ability of not tolerating the status quo (Tushman et al 2011). The
CEO always pushed for change even when things were stable.
After making his way into the company in the year 2001, Natarajan changed the
organizational structure by the first laying off some employees and hiring new ones in the



executive team. With this change, Ganesh believed that ...

flag Report DMCA

Outstanding Job!!!!

Similar Questions
Hot Questions
Related Tags

Brown University

1271 Tutors

California Institute of Technology

2131 Tutors

Carnegie Mellon University

982 Tutors

Columbia University

1256 Tutors

Dartmouth University

2113 Tutors

Emory University

2279 Tutors

Harvard University

599 Tutors

Massachusetts Institute of Technology

2319 Tutors

New York University

1645 Tutors

Notre Dam University

1911 Tutors

Oklahoma University

2122 Tutors

Pennsylvania State University

932 Tutors

Princeton University

1211 Tutors

Stanford University

983 Tutors

University of California

1282 Tutors

Oxford University

123 Tutors

Yale University

2325 Tutors