IT Reloaded: Reorganizing for the Ultimate Growth Partnership

Posted August 31, 2006 | Leadership |
x
In this issue:

The structure of the IT organization is an important factor in supporting a company's ability to respond to market forces and compete effectively. Clearly, IT should be organized in a way that will deliver the most value to the firm, but choosing an organizational structure is not easy. Next month, we'll examine the different organizational choices for IT so that you can determine which one will work best for your company. Is your primary strategic objective profit? Asset utilization? Growth? Find out which IT organizational structure best fits each of these strategic directions. Learn how pairing business product teams with their own dedicated IT units can produce high-output team velocity combined with ever-growing domain knowledge and experience. Finally, discover how adopting a sports team's approach to recruiting, specialized positions, coaching, and retention can turn your IT organization into a winning franchise.

Schlumberger (www.slb.com) is the world's leading oilfield services company, with over 60,000 employees and 2005 revenue of over US $14 billion. We operate in approximately 100 countries, with personnel of as many nationalities.

When what we now call "information technology" first emerged, Schlumberger was a diversified company that, besides oil and gas exploration, was involved in sensors, utility metering, semiconductors and chip testing, CAD/CAM systems, and smart cards. We had developed expertise in these technologies based on our oilfield work, and we sought to apply them in other vertical markets. This diversification culminated in the acquisition of a 26,000-employee IT services company in 2001, which obviously had a significant impact on the role of IT in the company, as well as its organization. Then, under a new chairman, Schlumberger adopted a growth strategy based on anticipating a boom in demand for energy. As a result, we focused back on our core business, and by 2004, through a series of divestitures, we had become a pure oilfield services company again. In response, the role and position of IT in the corporate structure was progressively adjusted. In 2006, the CIO launched a fundamental reevaluation of the IT organization to create better alignment with the business strategy in support of the company's growth.

This article highlights the ongoing efforts to transform the role, governance, and positioning of IT at Schlumberger; the rationale for the hybrid IT structure that we believe best aligns with the company's vision; and the initiatives being launched to contribute to business growth and best respond to business demands. While each industry has to address different imperatives, there are common business drivers that should render our strategies, and some of our organizational principles, relevant to others.

CREATING A FRESH VISION

"Classic IT": A Foundation

Throughout the 1970s, both our management information systems and our technical computing environments were centralized in a small number of locations, as was typical due to the cost of mainframes. During the 1980s and 1990s, the strong central controls of the mainframe era faded away as countless IT solutions were implemented. Mainframes were replaced by networks of minicomputers and PCs. Oilfield measurements were no longer sent back to Paris or Houston for processing on a couple of central computers but processed in "field log interpretation centers" equipped with minis. Thus, a decentralized IT organization developed, without the benefit of an explicit set of models such as those since developed by Guest Editor Jerry Luftman [3] and others.

In early 2000, Schlumberger realized that IT solutions and technologies had proliferated without enough guidance from a global corporate vision and strategy. This distributed environment contributed to increasing costs and missed delivery dates on IT projects. New systems were commissioned locally without verifying that they were not redundant with other initiatives launched elsewhere, and they were then designed without the benefit of a common enterprise architecture. Build-versus-buy decisions were often biased toward "build" because we had no common sourcing practices and little understanding of the total lifetime cost of a custom solution. It became clear that our growing IT structure would at some point collapse, so we decided -- with strong guidance from the CEO himself -- to bring IT under a centralized structure.

During the next three to four years, the IT function was progressively put under the control of a formal hierarchical structure led by the CIO. Due to the geographically diverse nature of the business, the execution of IT activities was distributed among a virtual team. This had the advantage of leaving some of the people brought into this structure where they were, instead of asking them to move, and it allowed easier communication with business managers who were themselves disseminated around the globe. Several initiatives were undertaken to rein in IT processes and institute controls, with direct reports to the CIO in charge of each function:

  • Portfolio management. Project submission, budgeting, and approval were formalized via an IT project portfolio portal. Systematic portfolio reviews enforced compliance with agreed criteria for starting (and stopping) projects. As a result, a number of nonessential projects were terminated.
     
  • Standards. Technology standards, involving everything from desktop and laptop computers and standard images to network equipment and software, were implemented in order to simplify the infrastructure, make support easier, and maximize volume discounts.
     
  • Operations and business applications. Central operations groups were created for the network infrastructure, core services (e-mail, directory, etc.), and common business applications.
     
  • User services. Regional help desks were established to ensure 24/7 coverage and support in multiple languages, rather than relying on direct contact with the IT staff at each location.
     
  • Enterprise architecture. To bring some order to our business applications (of which, at the height of their diversity, we had about 500), and following an assessment by a global IT consulting firm, we developed an enterprise architecture blueprint and introduced a common middleware product for enterprise application integration (EAI).
     
  • Sourcing. We outsourced some non-core activities and introduced procurement and vendor management strategies.
     

As a result of the above actions, we reduced our overall IT costs by over 40%, while greatly improving service delivery, reliability, and security of the infrastructure and applications. Centralized IT management also allowed for better alignment of IT capital spending with the real business priorities. This provided the foundation for the IT organization to be a professional and cost-effective "service company within the service company."

THE FALLACY OF COMMODITY

In his famous Harvard Business Review article "IT Doesn't Matter," Nicholas Carr argues that IT's strategic importance is not growing, as many have claimed or assumed, but diminishing [2]. As IT has become more powerful, more standardized, and more affordable, Carr argues, it has been transformed from a proprietary technology that companies can use to gain an edge over their rivals into an infrastructural technology that is shared by all competitors -- a commodity input that is necessary for competitiveness but insufficient for advantage.

If Mr. Carr were completely right, then by 2004 our IT organization would have fully met the needs of the company. However, several observations are inconsistent with this position and directly contradict his view:

  • The ability to manage the huge amounts of data acquired by our clients (especially during seismic surveys of the subsurface) requires novel computing solutions.
     
  • The oil and gas industry is going through a demographic crisis because of an aging population of experts who were not replaced during two decades of lower activity. As a result, remote operations of exploration and production are becoming vital in order to perform more work with a limited amount of human resources [5]. This capability to augment human resources is a competitive advantage directly dependent on the introduction of novel information technologies.
     
  • Knowledge management, in the context of a workforce that includes over 40,000 dispersed, intermittently connected employees, does not accommodate itself to commodity solutions.
     

If IT were not a business differentiator, then the centralized organization we had achieved by 2004 would have been satisfactory -- the documented drawbacks of such an organization would not have been significant. But if Carr is wrong, as we contend, then these drawbacks (lack of responsiveness to the business, insularity, "ivory tower" mentality) would surface -- and they did.

In the early days of our international data network (1981-1985), we had once established a strong differentiator based on non-commodity IT solutions. By 2004, we were hard-pressed to name equivalent examples. For example, we still had a worldwide IP network -- but so did everyone else. The fallacy of Carr's position is not that PCs, spreadsheets, and network connections have not become commodities -- they have -- it is that other information technologies have become the new potential differentiators for our business. Our IT organization needed to evolve again to enable this leverage, and I will explain in the next section how this occurred.

"IT RELOADED": PARTNERING WITH THE BUSINESS

In 2004-2005, we took modest steps to allow some innovation to take place in IT. We established contacts with specific academic groups in order to become aware of emerging technologies that could give us competitive advantages -- as we had long done in areas such as geophysics or chemistry. We saw an increased number of IT-related suggestions being made through our annual R&D input process. We gave our self-directed community of 2,400 technical experts in IT and software leeway to organize advanced workshops sponsored by business managers. And we started dedicating a special innovation fund to pursue the most promising initiatives submitted by employees, using a streamlined approval process.

But while these were useful steps, they still did not follow a vision or strategy of explicitly tying IT programs to the overall business of the company. Moreover, the innovation program was created without a concomitant organization change. As a result, these "skunkworks" projects received little support or recognition from the managers of the employees involved, leaving the projects starved of resources.

After I was named CIO in April 2006, my team and I directly addressed the need to rethink our IT in order to ensure business alignment. The first step was to set the vision. We aimed high, stating that the role of IT was to:

  • Produce business value -- create a competitive advantage
     
  • Facilitate agility -- streamline and accelerate business processes to achieve faster, better informed decision making
     
  • Encourage innovation -- stimulate new ideas and thoughts
     
  • Establish collaboration -- instill a culture conducive to seamless knowledge capture and sharing
     

Looking at these high-level goals, we created a new mission statement for IT:

Enable profitable growth though cost-effective processes and technologies that will securely automate and manage information flow and knowledge, delivering them to the right people at the right time and at the right place.

The next step was to look critically at the scope of tasks performed by the IT organization in light of this vision and mission. We defined what we called the "new IT maturity stack" (see Figure 1). The shape of the diagram is meant to convey two things: each level relies on the previous one, and as one goes up the stack, the importance increases.

Figure 1 -- The new IT maturity stack.

"Deliver" consists of providing our people with computers, connectivity, security, and basic productivity tools in response to business demand. We need to make sure that this level continues to be delivered flawlessly, but it is only one part of the picture.

"Harvest" entails extracting information and knowledge needed by people to make informed decisions, and it fulfills the part of the mission that talks about "delivering to the right people at the right time and at the right place." To be efficient and effective with information, we need to enter it only once, validate it, warehouse it, retrieve it, and combine it easily. Too often, people spend 80% of their time looking for information and only 20% of their time exploiting it, when the proportions should be reversed. We need better-integrated business applications, content management, knowledge management, and e-learning, which can lead to true "business intelligence."

Finally, the "Align" level contains the activities through which IT delivers real business value, either by increasing revenue through innovative products and/or services that incorporate emerging technology or by increasing productivity and reducing costs through business process simplification and automation. While it is the role of the business groups to determine their market strategy, it is the role and responsibility of IT to present to the business new opportunities based on technologies and methodologies with which business managers may not be familiar. We have selected two key business needs for our IT alignment efforts: Real-Time and Automation/Augmentation. 1

ORGANIZING TO FULFILL THE VISION

How can we organize ourselves to maintain our effectiveness at the Deliver level, complete our offerings at the Harvest level, and move toward the Align level of the stack?

The basic principle for the organization we are putting in place is to have an owner within the IT organization for each high-level corporate business goal with which we need to align. Each of these owners shares objectives with his or her internal clients, which motivates them to work as a team -- especially for objectives that have a performance incentive (bonus) attached to them. Our compensation system used to allow for annual incentives only; recognizing that some of the business transformation initiatives in which IT takes part may take multiple years to achieve results, we are in the process of changing the system to allow for multiyear objectives.

Figure 2 shows the new organization chart. The three perspectives (business, technology, governance) explicitly outlined in this diagram are orthogonal. For example, real-time activities need to be concerned with all four technology areas: architecture, security, business processes, and software methods. Similarly, this business-focused activity needs to follow common policies in terms of personnel, communications, sourcing, and budgeting and tracking. However, to represent these three dimensions as the orthogonal directions of a cube would imply a matrixed organization, which is not what we implemented. Instead, each of the 11 boxes in the diagram constitutes a separate team (sometimes just a team of one) that coordinates with the other teams as required.

Figure 2 -- CIO's direct organization.

This is still largely a centralized organization, but two aspects of it provide the necessary alignment with the business:

  • The business-oriented functions (top row) directly correspond to priorities of the CEO and senior business managers. Therefore, for example, the manager of the Global Real-Time Initiative (GRTI) will end up talking more to the business group presidents, his direct internal clients, than to the CIO about what his team needs to provide. At the same time, creating a single GRTI team avoids the temptation to staff a real-time team in each business group, with the inevitable redundancy that would ensue.
     
  • In addition to the above structure, we will see later that we initiated "business-IT liaisons" that introduce an explicit hybrid component to the organization.
     

The following sections review some parts of this organization, outlining their roles and responsibilities.

INNOVATION AT THE CORE

We added a responsibility for innovation to the role of the IT chief architect. Given the company's overall dependence on technology and commitment to innovation, IT needs to look outside of the company (to academic and industrial research centers, consortia, etc.) to identify the most promising directions, match them with business needs, and introduce the innovations into our processes and tools through pilots and prototypes.

To succeed with innovation ideas, we need a pervasive culture that rewards appropriate risk taking, but we also need a clear process to identify, fund, and, if necessary, terminate experiments. Managing this process is the key responsibility we added to this role. This process will be supported by regular meetings between business groups and IT, collaborative tools to foster a dialogue on new initiatives (R&D input database, blogs, etc.), and a CIO Innovation Award.

The innovation role must be performed in close coordination with the research organization, where emerging technology is identified (often through relationships with academic research centers) and prototyped, and with the other parts of the IT organization, which are responsible for rolling out and supporting these innovations when they become stable enough to be incorporated into solutions and deployed. Overall, our innovation process is similar to those that exist at companies like Shell ("GameChanger" process) and Intel ("Concept Cars").2

ENABLING THE REAL-TIME ENTERPRISE

In our business, real-time operations encompass data acquisition with smart sensors, the delivery of this data to the client, production surveillance, automated alerts, and, ultimately, semiautomated control of oilfield equipment, with remote operations to minimize the number of engineers and specialists actually needed on site. We created the GRTI to consolidate the somewhat disconnected efforts we had going in multiple business segments and to provide a consistent real-time infrastructure, covering the whole flow of information and control, with a clear business model and go-to-market strategy.

BUSINESS PROCESS IMPROVEMENT

IT organizations, regardless of the organizational model they follow, tend to respond to business needs by creating new applications to fulfill the requirements presented to them. This typically results in a proliferation of disconnected "silo" systems. There are about 470 different applications at Schlumberger, and this number is small in comparison to what we have seen at other companies.

If we look at business processes rather than at individual applications, however, we can often streamline these processes and implement linkages that simplify the user's job and improve the quality of the data (e.g., by eliminating multiple entry). In the words of a major IT analyst firm, "the growing focus on improving business process has led IT leadership to rethink organizational structures and craft more proactive process-enabling roles." Concretely, we addressed this need by adding in the organization chart a separate Business Process Automation team, which will work with the business groups to adapt processes when needed, automate them when possible, or eliminate those that turn out to be unnecessary. This team will have as an objective to make process modeling into a recognized discipline, with people trained in applying established methodologies and tools.

ENTERPRISE ARCHITECTURE

A key role of the Architecture and Innovation group is to enable the connection of business processes by mapping them to a service-oriented architecture (SOA). An internal study performed in 2005 concluded that SOA should play a significant role in enabling the connection of business processes within Schlumberger as well as between Schlumberger and our clients and business partners. In terms of organization, this has led to two key recommendations. We believe we must:

1. Consolidate the management of our revenue-making commercial software and IT services with that of our internal business information systems. The CIO's involvement is as critical to the architecture of our technical software products as it is to the architecture of our ERP applications.

2. Start an R&D activity in ontology (the formal, computer-readable specification of terms and their relationships within a knowledge domain) so that integration across enterprise boundaries becomes possible. To ensure acceptance, the ontology needs to be developed with our clients and partners or by an industry consortium. We're looking into working on this with a university that has both a business school and a petroleum engineering department.

These two initiatives will result in further organizational evolution, not yet reflected in Figure 2. The first initiative in particular (combining internal and commercial software development) will be a significant organization change, not just for IT, but also for the business group concerned. A dual-reporting structure is probably the most appropriate way to avoid the drawbacks of a fully centralized organization under the CIO, but this is yet to be determined.

The existing Program Office will ensure proper governance and coordination of our application roadmap. In addition, the existing "network of architects" that guides our commercial applications will be expanded to reach beyond its current scope and cover real-time applications and business systems.

SOURCING

We have created a framework that helps make the decision to outsource an activity on a more objective basis, enabling the company to focus on value-added activities and identify opportunities for outsourcing non-core, non-mission-critical tasks.

Related to this decision framework, we also formalized the roles involved in managing this process. We have split the sourcing function into two roles:

1. Global IT Strategic Sourcing (GISS) -- focuses on applying a rational sourcing process worldwide and selecting the appropriate vendor for each product or service

2. Service Contracts -- focuses on administering contracts and services once a supplier is selected and managing the vendor's performance against service-level agreements

In terms of organization, the GISS manager has dual responsibility to the CIO and to the supplier relations manager for the whole company, and the Service Contracts role is assigned to the IT controller (who himself has dual reporting to the CIO and the finance organization).

COMMUNICATION AND EDUCATION

There is no point in complaining that the business treats IT purely as a "PC fixer" if IT does not explain what else it can do for the business. Conversely, IT personnel must be educated to become valid interlocutors to the business -- all too often, IT would be welcome at the discussion table, but it does not show up. To address these issues, we added the responsibility for communication and education to the IT personnel manager's mission. An education program is being designed, including a one-day executive seminar on IT. In addition, we have created a communications coordinator position, reporting to the personnel manager, to focus on communication efforts within IT (newsletter, IT "one-stop shop" portal, etc.).

BUSINESS-IT LIAISONS

The overall organization of Schlumberger is itself a matrix between the types of services we render (composed of three business groups, further divided into business segments) and the operations organization, which is divided into geographical areas and "geo-markets." In each of these organizations, we are naming an IT manager who will not only be aware of the business goals of his or her group or area, but also of the new capabilities of the IT organization. These individuals' responsibilities are:

  • Acting as links between the business and the IT function, providing "operational alignment" and avoiding duplication of efforts
     
  • Ensuring that IT provides the business with the appropriate tools to reach its goals
     
  • Informing the business of developments and innovations in IT that may present opportunities
     

Figure 3 depicts the "dotted-line" relationship between these positions and the CIO.

The organization of a company's operations as a matrix of business segments and geographical territories is not unique to Schlumberger or to our industry. Therefore, the creation of IT managers in each of these dimensions, who report functionally to the CIO, should be applicable to other organizations whose size can support these positions.

Figure 3 -- IT liaisons in the business groups and areas.

SOFTWARE AUTHORITY

While Schlumberger generally prefers to buy rather than build internal-use software, it also develops a significant amount of domain-specific software for sale to its clients. There is an increasing need to coordinate this development to ensure consistent technical architectures, human interfaces, interoperability, and quality. In 2005, the Schlumberger Software Authority group was formed to meet this need. This group reports both to IT and to the business segment that sells software. Thus, the Software Authority is itself a hybrid organization tool -- a role that compensates for the divergences between software methods and practices that would occur if the software organization were fully decentralized.

The key goals for the Software Authority are to harmonize the technical architecture of the products through a network of software architects; to define, disseminate, and teach common software methodologies and tools; to define career paths and arbitrate resources globally; and to animate our worldwide community of software professionals.

CHALLENGES AND NEXT STEPS

The key challenge, not unique to us, is that many business users (and managers) do not yet understand what IT does, or worse, they do not value what IT can accomplish for them (as Cutter Senior Consultants Bob Benson, Tom Bugnitz, and Bill Walton note in their article "Why CIOs Are in Trouble" [1]). One challenge will be helping the business change its attitude toward IT. A similar challenge is to prepare IT personnel for this transformation. Both of these challenges should be addressed, at least to some extent, by the focus we put in the organization on communication and education.

The new positions required by our strategy will increase IT costs. How can we correctly assess IT's contribution so that we can prove there is a positive return on this investment? Will this still be a case of "If things go well, it's thanks to the business manager, and if things go badly, it's IT's fault"? IT must be able to show its value to its internal clients just as an external service provider would have to. Speaking the same language as the business helps, but it is not enough. It will help more concretely if we conduct successive pilot projects (jointly chosen with business stakeholders) and institute a policy of incremental deliverables that constantly provide and demonstrate additional value to the business. This is essentially the application of agile project management, which originated in the software development field, to a broader range of IT activities.

To improve our ability to measure success and correct deviations, we are now working on an "IT Capability Maturity Model" derived from the Software Engineering Institute's Capability Maturity Model® (CMM®). The objective is to list every significant capability that an IT organization should have and assess objectively whether the organization is at the "initial," "repeatable," "defined," "managed," or "optimizing" level. While the CMM may seem to impose on software organizations a set of processes that agile project management proponents may find overly constraining, we believe that when discussing IT organizations, there is no contradiction between a CMM-based approach to assessing the maturity of the organization and an agile approach to demonstrating the value of IT to the business. Once we reach sufficient confidence that our model is applicable and useful, this work will be the subject of another paper.

AVOIDING THE EXTREMES

From the mid-1970s to the mid-2000s, we have gone through a full pendulum swing from a centralized organization model to a decentralized one and back again. As pragmatists, we are less worried about the correctness of the organization model per se than with the imperative of making IT business-driven rather than technology-driven. We are doing this in several ways, such as selecting a CIO with a background in oilfield services; redefining a vision, a mission, and a strategy; and communicating with senior executives. But we are also addressing the imperative through organization changes that result in a "cautiously hybrid" organization: one in which all the key IT managers report to the CIO, but where several key positions are directly linked to major company goals, and other positions ensure coordination with the geographical and functional structure of the company. We expect continual adjustment of this organization as time passes and we gain experience. We welcome feedback and comments to help us in this endeavor.

NOTES

1We add the word "augmentation" to "automation" because our strategy is to grow our activities without increasing headcount in direct proportion -- not to cut down on headcount while doing the same amount of work. See [4] for a discussion of automation and augmentation concepts as they relate to IT.

2 Shell's GameChanger is "a company-wide system for encouraging and funding technical innovation at Shell. GameChangers are ideas whose implementation in the business have the potential to effect a quantum improvement in the profitability of the business, or which open up opportunities for growth. They must contain a novel perspective on a problem, a new source of information, a new product or a new vision" (www3.imperial.ac.uk/engineering/about/strategicalliances/shell/gamechanger). Intel Corporation uses the phrase "IT Concept Car" to imply the same intent as the automotive industry's concept car methodology: to stimulate breakthrough innovation and to create and test out the "next generation plus one" IT and computing concepts.

REFERENCES

1. Benson, Bob, Tom Bugnitz, and Bill Walton. "Why CIOs Are in Trouble." Cutter Consortium Business-IT Strategies E-Mail Advisor, 31 May 2006.

2. Carr, Nicholas G. "IT Doesn't Matter." Harvard Business Review, May 2003.

3. Luftman, Jerry. "Organizing IT: What's the 'Right' Structure?" Cutter Consortium Business-IT Strategies Executive Update, Vol. 7, No. 8, April 2004.

4. Schrage, Michael. "Automation, Augmentation, and Innovation: Redefining the Future of Delegation in the New World of Work." MIT White Paper, April 2005.

5. Sheridan, Thomas B. Telerobotics, Automation, and Human Supervisory Control. MIT Press, 1992.

ABOUT THE AUTHOR

Saad Bargach joined Schlumberger as a field engineer in South America in 1987 and worked in various operations positions on all continents. From 1990 onward, Mr. Bargach occupied successive management posts in Libya, Indonesia, the US, the UK, and Egypt. After a brief stint in the IT division of Schlumberger in 2001-2003, he rejoined its oilfield business as President of the Well Completions and Productivity unit in 2004. Mr. Bargach became the company's CIO in April 2006. He holds a bachelor's degree in electrical engineering and control systems and a master's degree in computer science and robotics. Mr. Bargach can be reached at saad.bargach@slb.com.

About The Author
Saad Bargach