CIO Best Practices: Enabling Strategic Value with Information Technology

CIO Best Practices

CIO Best Practices Enabling Strategic Value with Information Technology Joe Stenzel

John Wiley & Sons, Inc.

∞ This book is printed on acid-free paper. ●

Copyright © 2007 by John Wiley & Sons, Inc. All rights reserved. Published by John Wiley & Sons, Inc., Hoboken, New Jersey. Published simultaneously in Canada. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978–750–8400, fax 978–646–8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, 201–748–6011, fax 201–748– 6008, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information on our other products and services, or technical support, please contact our Customer Care Department within the United States at 800–762–2974, outside the United States at 317–572–3993 or fax 317–572–4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our Web site at http://www.wiley.com. Library of Congress Cataloging-in-Publication Data: Stenzel, Joseph, 1957CIO best practices : enabling strategic value with information technology / Joseph Stenzel. p. cm. Includes index. ISBN: 978–0-470–04868–9 (cloth : alk paper) 1. Chief information officers. 2. Information technology—Management. 3. Information resources management. 4. Management. I. Title. II. Title: Chief information officers’ best practices. HD30.2.S7827 2007 658.4'038—dc22

2006025195

Printed in the United States of America 10

9

8

7

6

5

4

3

2

1

Wiley and SAS Business Series

The Wiley and SAS Business Series presents books that help senior-level managers with their critical management decisions. Titles in the Wiley and SAS Business Series include:

Business Intelligence Competency Centers: A Team Approach to Maximizing Competitive Advantage, by Gloria J. Miller, Dagmar Bräutigam, and Stefanie Gerlach Case Studies in Performance Management: A Guide from the Experts, by Tony C. Adkins Credit Risk Scorecards: Developing and Implementing Intelligent Credit Scoring, by Naeem Siddiqi Customer Data Integration: Reaching a Single Version of the Truth, by Jill Dyché and Evan Levy Information Revolution: Using the Information Evolution Model to Grow Your Business, by Jim Davis, Gloria J. Miller, and Allan Russell Performance Management: Finding the Missing Pieces (to Close the Intelligence Gap) by Gary Cokins For more information on any of the above titles, please visit www.wiley.com/go/sas

Contents Preface About the Contributing Authors chapter 1 chapter 2

chapter 3

chapter 4 chapter 5

chapter 6

chapter 7 chapter 8 Index

Harnessing IT to Drive Enterprise Strategy By Michael Hugos

ix xix 1

Architecture, Portfolio Management, Organizational Development—Integrated Foundations for Strategy Realization By Anthony Hill

43

A Strategically Focused, Tactically Agile IT Organization By Michael Hugos

83

The Sum of IT Can be Greater than its Parts By William Flemming, SAS, and Alan Stratton

139

IT Performance Management Using the Balanced Scorecard By Paul Niven

185

How to Measure and Manage Customer Value and Customer Profitability By Gary Cokins, SAS

225

Consider the Outsource: Right from the Start By Karl Schubert

275

Managing for Returns on IT Investments By Michael Hugos and Joe Stenzel

321 349 vii

Preface

Anyone working in information technology today feels the opportunities for creating and enabling lasting value, and the CIO helps define those opportunities so that they can be turned into realities. That’s what this book is about. Humanity has discovered an evolutionary tool that allows us to realize our true potential—intellectually, artistically, socially, and above all, creatively. But we must be circumspect as we explore the uses of this new tool that works as an extension of our own minds. Living as we do on the edge of an evolutionary horizon, we must learn to respect the two native forces that have pulled human creativity in opposite directions since the beginning: (1) the drive to understand more about ourselves and our world, and (2) the desire for safety and security. Some part of us craves the entirely new; another part longs to be safe and is uncomfortable with change. No senior executive feels the disjointed pull of these two forces more than the chief information officer,1 who seeks to create new frontiers of strategic information technology value for the enterprise while working in an environment of service and stewardship for other people’s interests. New strategic frontiers demand that the CIO take bold, decisive risks as new technologies offer competitive opportunities. Service and stewardship responsibilities demand that the CIO also take care of the day-to-day needs of people that depend on more basic information technology resources to perform what the enterprise requires of them. Other forces distinguish the world of the CIO from executive team peers. More than any other member of the enterprise, the information technology professional works with products and services built according to designs that represent the most current understanding of the ways our ix

x

preface

world is organized. While people from other functional areas of the enterprise work within organizational structures marginally evolved from the beginning of the industrial age, IT organizations embody the principles that underlie information technology products and services—selfreferencing, chaotic, morphogenic systems. The CIO must work to reconcile IT’s more mature, inclusive perspective on the enterprise with the traditional views of peers that prefer the illusory safety and security of departmental silos that use command and control management policies. Then there’s the matter of the emerging role of the CIO in terms of the myriad expectations of the many people throughout the enterprise, which often boils down to a simple three-word question of focus: Business or technology? This book acknowledges and addresses these disruptive forces by incorporating a few basic premises in each chapter. Premise 1: The business of the IT organization is technology, and the business of the CIO is the business of the enterprise. As such, the best practice CIO works and makes decisions in a realm of strategy, customer value creation, cost and performance management, and outsourcing partnerships while building and maintaining an IT organization that can develop and manage enterprise technology that enables strategy. Premise 2: As a new executive role with an evolving set of responsibilities and expectations, CIOs cannot prepare themselves to learn what they need to know about the business of the enterprise without the help of non-IT experts. In addition to the chapters written by experienced, practicing CIOs acknowledged for their excellence, this book includes chapters written by performance management, accounting, and customer relationship management experts familiar with leveraging IT value. Premise 3: The CIO is an investor of enterprise resources accountable for realizing a return on those investments. This premise acknowledges that the rest of the executive team depends on the CIO’s specialized understanding and insights of information technology value opportunities. All the chapters discuss how the CIO can realize a return on IT investments— including the investment of IT’s many intangible resources. Premise 4: All enterprises are unique, and their IT organizations must align to the specific needs of the enterprise. Each chapter includes considerations for small, medium, and large enterprises across all sectors. Inherent in this premise is the understanding that all enterprises have one thing in

preface

xi

common—success depends on the articulation and implementation of a clear business vision and strategy. As such, the IT organization must be aligned with the enterprise vision and strategy so that it can align its products and services to realize strategic objectives. Each chapter discusses ways that the best practice CIO works to align IT products and services to fit enterprise vision and strategy. Premise 5: All CIOs live and work in a competitive world, and customer relationship management excellence has become one of the most important competitive advantages in all sectors. The chapters in this book consistently address the importance of the IT organization’s internal and external customers, and the book includes an entire chapter on customer relationship management best practices. Premise 6: There can be no comprehensive treatment of the CIO’s role as leader of the IT organization at this point in the development of this new executive office. At the same time, building on Premise 4, there are common elements to CIO best practices that apply to enabling strategic value from IT in any enterprise: • Aligning information technology with evolving business needs and devising IT strategies that mesh with enterprise strategy • Designing and maintaining an enterprise architecture that reflects and enables enterprise strategy • Organizing, motivating, and managing IT organizations to focus on agile strategy execution and deliver consistently outstanding performance • Strategic cost management practices for IT Finance that transparently reveal the operational costs of IT services to the CIO and IT customers • Strategic performance management practices that align the work of the IT organization with enterprise strategy • Customer relationship management practices that reflect enterprise strategy as the build value for internal and external IT customers • Carefully selected outsourcing relationships managed according to enterprise strategy • Calculating and managing for continuous improvement for the return on investments of tangible and intangible IT resources

xii

preface

The chapters in this book incorporate all these premises with a deliberate sequence that reflects the movement of strategically interpreted information technology value creation from the core of IT organization throughout the enterprise. Just as when an object hits the surface of a calm body of water and waves of influence propagate concentrically from the point of impact, this book begins at that point of impact—interpreting enterprise strategy in terms of how the IT organization can enable the strategy and deliver enterprise value through information technology resources.

chapter 1 executive summary Harnessing IT to Drive Enterprise Strategy by Mike Hugos Chapter 1 lays the foundation for the entire book by describing how the CIO and the IT organization use information technology resources to drive enterprise strategy starting with the relationship between IT strategy and enterprise strategy. The chapter discusses how to formulate an IT strategy for the high-change environments and then addresses practical strategic guidelines for designing IT systems and tactical methods for the IT organization. From this foundation, the second part of Chapter 1 describes ways that the best practice CIO communicates enterprise and IT strategies to IT organization staff members with a focus on participatory teamwork for accomplishing work according to schedule. Part 2 also directly addresses elements of risk in the decisions CIOs make for their enterprises and IT organizations and provides guidelines for addressing those risks. The chapter ends with a comprehensive system for evaluating new projects from inception through implementation.

chapter 2 executive summary Architecture, Portfolio Management, Organizational Development—Integrated Foundations for Strategy Realization by Anthony Hill Continuing with Chapter 1’s theme that the goal of every good CIO is to align IT strategy to enterprise strategy, Chapter 2 describes the ways that the CIO optimizes the strategic interrelationships of four key tools—

preface

xiii

enterprise architecture, IT governance, IT project portfolio management, and IT organizational development—to align and execute the IT contribution to the realization of enterprise strategy and bridge the gap between the goals of enterprise strategy and the current information and technology structure of the organization. Part 1 of Chapter 2 demonstrates how a strategically aligned enterprise architecture enables IT governance, portfolio management, and organizational development practices with a step-by-step discussion of CIO best practices for enterprise architecture development and maintenance. The second part of this chapter describes ways that the CIO can integrate strategic IT governance and portfolio management processes into the enterprise architecture. Part 3 addresses CIO best practices for IT organization development for individual staff members and ways to achieve balanced capabilities from the entire organization to address the enterprise’s strategic IT requirements.

chapter 3 executive summary A Strategically Focused, Tactically Agile IT Organization by Mike Hugos Chapters 1 and 2 establish the necessary foundations that the IT organization needs to accomplish enterprise strategy. Chapter 3 discusses the ways the IT organization works with its processes throughout the enterprise, characterizes IT agility as a process, and lists agility skills that the IT staff can practice to become more strategically focused. Tactical agility depends on skills and techniques, so this chapter discusses six core techniques that the CIO and IT staff can use to make the IT organization more agile. Agile IT organizations work most efficiently and remain strategically focused when they have clear frameworks for dealing with the processes they manage. With a detailed focus on process management best practices, Chapter 3 provides a step-by-step system for process monitoring and decision making that allows the IT organization to appropriately discontinue, maintain, and improve existing processes. This chapter also provides a detailed, deliberate, disciplined system to define the need for new IT processes, design strategically aligned solutions, and build them according to budget and deadlines.

xiv

preface

chapter 4 executive summary The Sum of IT Can be Greater than its Parts: The Role of Strategic Cost and Performance Management in IT Maturity by William Flemming, SAS, and Alan Stratton More than any other member of the senior executive team, the CIO runs a business within the enterprise and accordingly answers to two distinct sets of customers who require very different forms of financial information. Chapter 4 discusses strategic cost management in terms of the operational information that IT Finance needs to offer the IT organization’s internal customers so that they can make more informed decisions about the IT services they request. This chapter presents models developed by SAS that characterize the maturity of the IT organization and help the CIO and IT staff strategically map the costs and performance of IT’s service-level agreements. Because the General Ledger, budget, and other traditional accounting tools lack the operational cost information that nonfinancial employees need to gauge the value of their IT services, this chapter describes the deployment of a more mature method, Activity-Based Costing and Management, and ways that IT Finance can use readily available data sources to illuminate enterprise costs so that people can make more informed IT resource and capacity decisions.

chapter 5 executive summary IT Performance Management Using the Balanced Scorecard by Paul Niven Performance management is another highly effective way to align and communicate strategic intent throughout the organization. Rather than using an ad hoc set of performance measures borrowed from another enterprise, best practice CIOs use flexible performance management systems like the Balanced Scorecard and design a custom set of strategically aligned measures to gauge and communicate the performance of the IT organization. After providing a complete description of Balanced Scorecard principles, measurement perspectives, and management processes, Chapter 5 gives a detailed account of how the CIO and IT staff can develop a

preface

xv

customized Balanced Scorecard that reflects IT organization strategy for communicating IT performance within the IT organization and to its customers inside the enterprise. This chapter describes a step-by-step approach to the two phases of building a Balanced Scorecard for the IT organization.

chapter 6 executive summary How to Measure and Manage Customer Value and Customer Profitability by Gary Cokins, SAS Customer relationship management (CRM) is one of the newest management frontiers as enterprises seek to use information about customer behaviors to refine their competitive advantage. As stewards of the enterprise systems and applications that house and process customer information, the best practice CIO works to stay as informed as possible as customer relationship management practices evolve. Parts 1 and 2 of Chapter 6 give the CIO a comprehensive update on the most current CRM practices with discussions of shareholder wealth creation, measuring the ROI on Sales and Marketing, customer value and profitability drivers, targeted selling and retention programs, effective Marketing delivery systems, and preparing customer analytics integration. Parts 3 and 4 of this comprehensive chapter explore ways that enterprise systems distinguish between high and low economic customer value and lifetime customer value by focusing on customer data management. Parts 5 and 6 discuss the decision-making processes that senior executives use to balance trade-offs between customer value and shareholder values with an analysis of how the best practice CIO works with other senior executives to get the most out of enterprise business intelligence and performance management tools to optimize the balance between customer and shareholder value.

chapter 7 executive summary Consider the Outsource: Right from the Start by Karl Schubert Chapter 7 addresses the ways that the CIO enables enterprise strategic value through outsourcing by describing a comprehensive, systematic

xvi

preface

approach to ensure a strategically aligned relationship. This chapter begins with a discussion of strategically valid reasons for outsourcing relationships followed by an analysis of activities appropriately and inappropriately outsourced. Perhaps the chapter’s most important contribution is a step-bystep system for first defining an enterprise outsourcing rationale consistent with its strategic goals and then selecting an outsourcing partner committed to working with the enterprise to meet those goals. Chapter 7 gives practical, concrete solutions for establishing an outsourcing project timeline and detailed descriptions of outsourcing processes such as surveys, requests for information, requests for proposal, site visits, contract negotiation, and outsourcing relationship management with a set of communication templates that the CIO can use for each step in the selection process.

chapter 8 executive summary Managing for Returns on IT Investments by Mike Hugos and Joe Stenzel This book concludes with a discussion of resource decision making that ties together the ever-widening circles of IT influence from its strategic core. IT architecture, tactical agility, and strategic cost, performance, customer relationship, and outsourcing management each enable an organization to align, implement, and realize its strategic objectives. Chapter 8 demonstrates the ways that the CIO can use conventional ROI calculations to improve decision making for IT project proposals and explores new perspectives on IT investments with ways that the CIO can help other executives manage and maximize more broad-ranging, elusive organizational resources and achieve a return on intangibles. Part 1 addresses the essential elements that the CIO uses to see a conventional ROI process through from start to finish, including the joint development process between IT and Finance, a cost/potential benefit analysis, an IT ROI benefit audit, ways to weight tangible benefits, and the reapplication of anticipated resources freed up by the proposal. Part 2 explores the rapidly emerging importance of intangible IT resources from the marketplace to the boardroom. Building on intangible management best practices from IT, Human Resources, and previous chapters, this discussion addresses

preface

xvii

practical ways that CIOs can help their executive teams define, identify, measure, valuate, and renew their intangible IT resources.

■ notes 1. This book uses the term “chief information officer” (CIO) to stand for any title the enterprise might use to designate the leader of its information technology organization, such as chief technology officer, and acknowledges that a person may serve more than one executive role in some enterprises.

About the Contributing Authors Gary Cokins (Chapter 6) is an internationally recognized expert, speaker, and author in advanced cost management and performance management systems. He is a manager in performance management solutions with SAS Institute, Inc., a leading provider of business intelligence and analytical software headquartered in Cary, North Carolina. Gary received a BS degree in Industrial Engineering/Operations Research from Cornell University in 1971 and an MBA from Northwestern University’s Kellogg School of Management in 1974. Gary began his career as a financial controller and operations manager for FMC Corporation and he has been a management consultant with Deloitte, KPMG Peat Marwick, and Electronic Data Systems (EDS). Gary was the lead author of the acclaimed An ABC Manager’s Primer sponsored by the Institute of Management Accountants (IMA). Gary’s second book, Activity Based Cost Management: Making it Work, was judged by the Harvard Business School Press as “read this book first.” Gary’s third book, Activity Based Cost Management: An Executive’s Guide, has ranked number one in sales volume of 151 similar books on BarnesandNoble .com. Gary has also written Activity Based Cost Management in Government. His latest book is Performance Management: Finding the Missing Pieces to Close the Intelligence Gap. Gary can be reached at [email protected]. Bill Flemming (Chapter 4) works in a thought leadership position for SAS’s Organization Infrastructure Intelligence where he identifies, defines, and applies technology to solve IT management problems. Bill has more than 20 years of experience with both hands-on IT projects and product thought leadership. His hands-on work includes managing the implementation of xix

xx

about the contributing authors

large IT System Management and Quality Control projects. In addition, he has marketed system management products and services for some of the industry’s leading vendors. His current projects include IT Strategic Performance Management and IT Financial Management, and he has published extensively about each subject. As a thought leader in IT Governance, he embraces the opportunity to effectively manage IT. Bill currently resides in Florissant, Colorado. He can be reached at [email protected]. Anthony Hill (Chapter 2) is Chief Technology Officer for Golden Gate University in San Francisco, where he architected an e-business transformation of the university. He has more than 24 years of experience in all facets of information technology as a CTO, software developer, consultant, project manager, and systems integrator. Anthony was included among those named as the nation’s “25 Most Influential CTOs” of 2002 by Infoworld Magazine and was selected to the Infoworld 100 in 2003 and the CIO 100 in 2004. He received his MS in Information Technology from Golden Gate University and his BA in Political Economics from the University of California, Berkeley. He lives in Berkeley with his wife and son. Michael Hugos (Chapters 1, 3, and Part 1 of Chapter 8) is a partner in AgiLinks LLC. He has 25 years of corporate and consulting experience in all aspects of information technology. He recently spent six years as the CIO of Network Services Company, a national distribution cooperative. He designed and built the suite of supply chain and e-business systems that transformed the company’s business model and drove its growth. Prior to this he was a Practice Director at a publicly traded global IT services firm. In 2003 and 2005 he was awarded the CIO 100 Award for bold and resourceful use of information technology and in 2006 he was awarded the Premier 100 award for career achievement. He holds an MBA from Northwestern University’s Kellogg School of Management. Mr. Hugos is also the author of two books, Essentials of Supply Chain Management, 2nd Edition and Building the Real-Time Enterprise: An Executive Briefing, both published by John Wiley & Sons. He is a columnist for Computerworld and CIO Magazine and a frequent speaker. Paul R. Niven (Chapter 5) is a management consultant and noted speaker on the subjects of Performance Management and the Balanced Scorecard.

about the contributing authors

xxi

As both a practitioner and consultant he has developed successful performance management systems for organizations large and small around the globe. His clients include Fortune 500 companies, public sector agencies from all levels, and nonprofit organizations. His books include Balanced Scorecard Step by Step: Maximizing Performance and Maintaining Results (translated in more than a dozen languages), Balanced Scorecard Step by Step for Government and Nonprofit Agencies, and Balanced Scorecard Diagnostics: Maintaining Maximum Performance. He can be reached through his Web site at www.senalosa.com. Alan Stratton (Chapter 4) is president of Stratton Associates LLC and is a Certified Management Accountant and a Certified Public Accountant. He is also a Board Member and, since 1991, an active participant in CAM-I, a consortium leading development of management methods and techniques in cost, process, and performance management. He currently chairs CAM-I’s Planning and Budgeting interest group. Previously, he chaired its Activity Based Planning & Budgeting interest group that published The Closed Loop: Implementing Activity-Based Planning and Budgeting. He is the author of An ABB Manager’s Primer, and coauthor of An ABC Manager’s Primer (the leading introduction to ABC/M) and Capacity Measurement & Improvement. He was formerly a product strategist and subject matter expert at SAS Institute. Alan’s work has also been published in Management Accounting, Journal of Cost Management, Corporate Controller, CMA Magazine, and As Easy As ABC. Previously, he was an independent ABC/M consultant, Director of Customer Advocacy at ABC Technologies, and held financial management positions at Cost Technology, National Semiconductor, Atari, General Instrument, and GTE. He earned a BS in Accounting and a Master of Accountancy from Brigham Young University. Dr. Karl Schubert (Chapter 7) is Corporate CTO and Vice President for Xiotech Corporation, Vice President & General Manager of Daticon (a Xiotech Company), and Chairman of Xiotech India, Ltd. He has a proven track record of developing leading-edge hardware, software, and combined product families and delivering them to existing and new market areas. Prior to joining Xiotech, Karl served as a technology consultant to startup companies associated with Austin Ventures, New Enterprise Associates, and Sierra Ventures. As CTO, COO, and Senior VP of Engineering for Zambeel Inc., he was responsible for driving technology, engineering, and

xxii

about the contributing authors

operations teams to produce the first enterprise-class, 4D-scalable, NAS subsystem. As VP and CTO of Dell Inc., he architected Dell’s entry into the storage business and was responsible for guiding the storage practice through its first several billion dollars of revenue. Prior to Dell, Karl spent 14 years at IBM, during which time he created the company’s OEM open storage subsystems unit. Karl has been awarded a number of patents for leading-edge technological innovation in storage systems architecture, storage area networks, and other technology areas. He obtained a Ph.D. in Engineering from the University of Arkansas, an M.S. in Chemical Engineering from the University of Kentucky, and a B.S. in Chemical Engineering from the University of Arkansas. His most recent book, published by John Wiley, is The CIO Survival Guide and he is a guest speaker at professional conferences and a regular panelist in the areas of technology, innovation, and distributed international development.

CIO Best Practices

chapter

1

Harnessing IT to Drive Enterprise Strategy by michael hugos

To put it plainly, the chief information officer (or CIO) in any enterprise is the person responsible for two things. One is a thankless task and the other is a high-risk undertaking. The thankless task is to make sure the enterprise systems infrastructure is operating correctly and efficiently 24 hours a day, seven days a week. The high-risk undertaking is to continually evolve and enhance that infrastructure so that it remains properly aligned and able to deliver what the enterprise needs to drive its evolving business strategy. This chapter explores ways that strategically minded CIOs respond to and handle the many elements of risk that come with IT leadership positions. It has become abundantly clear that successful CIOs figure out ways to delegate systems operations tasks to others so that they can devote most of their time to that second thing, the high-risk task of alignment and use of systems infrastructure to drive enterprise strategy. This is where successful CIOs bring the most value to the enterprises that employ them. High risk also means the potential for great rewards, and CIOs who effectively collaborate with other executives to reap those rewards for their enterprises are indispensable players on any senior management team. In most enterprises it is useless to discuss IT strategy without simultaneously discussing business operations strategy. As operations evolve and grow, they must be effectively supported and enabled by a company’s IT infrastructure. If the IT infrastructure does not evolve to deliver the needed 1

2

chapter 1

harnessing it to drive enterprise strategy

capabilities, the enterprise will be unable to change and grow its business operations. The CIO is the “C”-level executive best positioned to develop an overall understanding of a company’s operations and the systems that drive those operations. Successful CIOs use this understanding to be key players in shaping both business and IT strategy.

part 1 relationship of it strategy to enterprise strategy Just as the chief financial officer (CFO) is the senior person responsible for devising the capital structure best suited to an enterprise’s business needs, the CIO is the senior person responsible for making sure that the enterprise’s IT infrastructure best supports its business needs. The CIO is the senior-level liaison between the business and technical sides of an enterprise. The CIO is the person who helps define and translate business goals and strategies into systems performance requirements and oversees a portfolio of IT development projects to deliver systems that meet these requirements. In the information age, the competent and dynamic use of information technology is a requirement that all enterprises must meet in order to succeed. IT underpins every operation within an enterprise, and in fact it is hard to speak of operations and IT as separate entities any more. They are so intertwined and most business operations are so utterly dependent on information technology that it is usually pointless to think of them separately. Therefore any valid business strategy rests on assumptions that the enterprise already has or can soon acquire the information systems it needs to achieve performance levels called for by the strategy. Strategies calling for operating capabilities and performance levels that cannot be attained are strategies doomed to fail. Perhaps in the 20th century IT considerations were of secondary concern to business strategists; in the 21st century IT considerations are central to any viable business strategy. As we discuss strategy and tactics for effective use of IT we will use precise definitions for these terms that provide a framework for clear thinking and communication (see Sidebar).

relationship of it strategy to enterprise strategy

3

IT Strategy Follows Enterprise Strategy All enterprises have a set of goals either explicitly stated in a formal business plan or implicitly stated in the culture and conversations within the senior management team. The CIO needs to know these business goals. Make sure you know them by heart. Once the CIO discovers the enterprise’s goals, the next step is to define an IT strategy or strategies to accomplish these goals. Remember, a strategy is simply a way of using the means or capabilities available to a business to achieve its goals. Often, a business executes its strategy by building or enhancing systems to do the things called for by the strategy. Strategic IT Questions—Starting from Scratch Good strategy starts with asking the right questions. Strategy is the result you get from answering the questions you ask. Strategy that comes from answers to the wrong questions is useless strategy even if the answers themselves are correct. This is what is meant when people say generals often have great strategies to fight the last war instead of to fight the war they are in. Generals, and all the rest of us as well, have a tendency to ask questions that are no longer all that relevant. We ask questions pertaining to the details of a situation that is now passed. We tend to ask these questions because we already know the answers. We learned them from our past experience. The trick is to learn from our experience and yet remember that the future will be different in some important respects from our experience in the past. Here are some questions to ponder as you think about your IT strategy:

• What can IT do to enable my enterprise to accomplish its goals? • What business initiatives are planned over what time period? • What operating capabilities does the enterprise need to successfully carry out these initiatives? • What is the conceptual design of the IT systems infrastructure that will enable the enterprise to possess the operating capabilities it needs? • How can the existing IT infrastructure best be leveraged to meet enterprise needs?

4

chapter 1

harnessing it to drive enterprise strategy

Defining the IT Strategy To define your IT strategy, begin by listing a set of desired performance criteria that IT should meet in order to enable the enterprise to accomplish its goals. Robert Kaplan and David Norton in their landmark 1992 Harvard Business Review article, “The Balanced Scorecard—Measures That Drive Performance” defined four perspectives that create a comprehensive view of an enterprise’s performance (see Chapter 5 for specific applications of the Balanced Scorecard to IT performance measurement and management). Define the desired performance criteria that you expect IT to meet from these four different perspectives: 1. Financial Perspective—What financial measures do we want IT to achieve? 2. Customer Perspective—What do external and internal customers want from IT? 3. Business Perspective—What business processes must we excel at to accomplish the company’s goals? 4. Learning Perspective—How do we continue to learn and improve our ability to accomplish our goals? Brainstorm a large list of criteria under each of the four perspectives. Then review the lists and select four to eight of the most important performance criteria. If you can position IT to deliver capabilities that meet these criteria, the IT organization has accomplished its mission. For instance, the CIO may define financial criteria such as build the new systems for X dollars and be able to operate them for Y dollars per year. Customer measures could track activities that provide customers with Web-based capabilities to do a range of activities such as look up products, enter orders, and pay bills. Business criteria track things such as how well systems handle a certain level of transactions per minute, how well they scale up to manage additional transaction volumes, and how quickly they can be learned by new users who need them to do their jobs. Learning measures demonstrate how well a system provides users with the data and reports they need to assess and improve their performance on an ongoing basis. Next, look for ways to achieve these performance criteria in dramatically new ways. Ask the question, “What seems currently impossible, but

relationship of it strategy to enterprise strategy

5

if it could be done, would dramatically change the way we do business?” Look for ways to use systems to change the business landscape, to give the enterprise a significant competitive advantage by doing something new and different. Systems can be used to open up opportunities to either increase revenue or decrease costs. Systems can increase revenue by: • Creating new distribution channels • Erecting barriers to entry by competitors • Reducing customers’ ability to substitute another product for your product • Helping the company anticipate and respond quickly to market demands Systems can decrease costs by: • Improving product quality • Increasing production rates • Decreasing production and operating costs The ways in which systems accomplish these opportunities will either create structural change in the way an industry operates, or it will support and enhance traditional industry products and procedures. Great competitive advantages can be gained if ways are found to create structural change in an industry. This is what changes the business landscape; it is said that all you need to do is to be 10 percent new in any field to start a fortune. Companies that create structural change become leaders in their industries. Remember, a system is always people, process, and technology—not just technology. Define and design the process first, and then put the people and technology into place to support it. At the same time, keep in mind the capabilities of the people and technology available, and design a process that is realistic given those capabilities. In other words, adjust your ends to your means. Good strategy starts with a clear understanding of what is possible. One last point to remember about strategic IT projects is this: The executive sponsors on the business side need to remain actively involved with the project in an oversight and advisory role throughout the project’s life cycle. If no senior managers take an interest in this role, then either the goals that the IT strategy addresses are not really that important to the

6

chapter 1

harnessing it to drive enterprise strategy

a framework for clear thinking Before we go further let’s define our terms. What exactly do we mean when we say strategy—especially in the context of the CIO’s two main responsibilities? Strategy, tactics, goals, objectives, missions, and milestones—we often toss these words about in various vague, undisciplined, and confusing combinations. Most of the time terms such as goals and objectives or strategies and tactics are used interchangeably. The precise meaning of the words gets lost and so the clarity of thinking that these words can support is also lost. If we hope to gain any real value from these words then we owe it to ourselves to be very precise and clear in the way we use them with both our executive peers and our staff members. Otherwise, they become trite phrases, macho imagery, or smokescreens for incompetence. business vision—This is a statement of the company’s purpose, why it exists, what it aspires to. The business vision of the company is articulated by a set of goals that define what the company will strive for and where the company will invest its resources. goal (or mission)— A goal is a qualitative statement that describes a state of affairs or an accomplishment necessary for the business to become what it wants to become (the business vision). An example of a goal is, “Excel at customer service to strengthen and grow the national accounts sales program.” Another example would be, “Develop an e-business infrastructure to capitalize quickly on market trends.” strategy—Strategy can be defined as simply, “the deliberate application of means to achieve business vision and goal-related ends ”. Strategy is the art of using the means—business capabilities—available to a company to achieve its ends—its business goals. The degree to which a strategy is effective depends on a clear understanding of what is possible. The purpose of strategy is to maximize possibilities for success by effective use of the means available to an organization. Strategies are used to coordinate the accomplishment of goals or missions. objective (or milestone)—Unlike the business vision or a goal, an objective must be quantitative—it is a specific, measurable achievement necessary to accomplish a goal. The strategy that a business uses to accomplish a goal defines the objectives that must be achieved along the way. Objectives are the specific, measurable milestones that must be reached to accomplish a goal or mission. Objectives must be measurable; progress,

formulating strategy in high-change environments

7

toward and achievement of objectives should be easily determined by use of appropriate metrics. An example of an objective is, “Increase sales in the healthcare sector this year by 15%.” plan—A plan is a non-repetitive set of tasks that leads to the achievement of a new objective. A plan is not to be confused with an operating schedule, which is a repetitive set of tasks that are used to perpetuate an already existing state of affairs. The situation, the objectives defined and the tactics being applied guide the creation of a plan. The sequence of tasks shown on the project plan reflects the tactics and techniques that are being used. (See Exhibit 1.1.) tactics—Tactics are the execution and control of actions needed to carry out the business strategies and achieve objectives. Tactics effectively coordinate people, processes, and technology to achieve objectives that are defined by the business strategy. Tactics are the methods used to get things done. techniques—A technique is a well-defined action or behavior producing a pre-defined result. A technique is a systematic procedure by which a task is accomplished. Combining techniques into useful sequences creates tactics. See Exhibit 1.1 A Framework for Clear Thinking

business or people believe the strategy is flawed and doubt that the goals can be accomplished. In either case, you as the CIO should be aware of this. If that is the case, change your goals or your strategy if you want to remain part of senior management in your enterprise.

formulating strategy in highchange environments Formulating IT strategy in the high-change, high-risk environments we live in today is an iterative process of definition and redefinition. Our enterprises may go through formal strategic planning cycles every three or four years, but every year in between and every quarter of each year CIOs must update and adjust their IT strategies to best respond to the way their world evolves. Gone are the days when IT strategies could be rigid, multi-year plans that laid out each activity in detail and then simply required people to do as they were told. People may actually be able to do the things they are

8

chapter 1

harnessing it to drive enterprise strategy

The vision of what the business wants to become is articulated by a set of goals.

GOAL 1

Objective A

Objective B

Business Vision

GOAL 2

Objective C

Project Plan & Budget Objective A Task 1 Task 2 Task 3 Objective B Task 4 Task 5 Objective C Task 6 Task 7 Total Project

EXHIBIT

$

Cost 999 99 999 999 99

999 99 $99,999

1.1

The goals and the strategies to accomplish them are designed to make maximum use of the company ’s capabilities.

GOAL 3

The strategy devised to accomplish a goal defines the objectives that are necessary and sufficient to do so.

Tactics are used to achieve objectives. Tactics are the methods you use to get things done. The sequence of tasks shown on the project plan reflects the tactics and techniques being used.

A Fr a m e w o r k f o r C l e a r T h i n k i n g

told, but with rigid plans they inevitably find themselves performing tasks that no longer relate to the real world and the real needs of their enterprise. The point to understand is that an enterprise’s goals remain reasonably steady over a two to four year period but the IT strategies employed to accomplish those business goals may need to be changed every year or even more frequently. Like setting a ship’s course, a strategy is a way of steering toward a goal—of getting from here to there. The real world unfolds in unexpected ways that may push you off your expected course so you make mid-course corrections (strategy corrections) as needed. But you are not

formulating strategy in high-change environments

9

just flailing about because you are always steering the IT organization toward a steady destination (the business goals). Therefore, the IT strategy formulation process has a sequence of four steps to guide people through the cycle (see Exhibit 1.2). These steps are: 1. Map out the big picture 2. Decide how to get from here to there 3. Act effectively to manage risk 4. Evaluate changes Map out the big picture means literally creating a map that shows the territory in which your enterprise operates. Use the map to identify the facility locations of the enterprise at present and the locations that the company wants to open in the future. Usually the maps you create will be more than just geographical maps. The CIO also needs to create maps of the markets the company serves, maps that compare enterprise systems capabilities to competitors’ capabilities, and maps that describe and compare the IT infrastructure of the enterprise and its competitors.1 These maps, charts, diagrams, and lists define and identify where the enterprise is at present and where it wants to be in the future. This future destination is the destination that all IT strategies aim to reach. There can be no coherent strategy until people understand where they are trying to go. Decide how to get from here to there means just that. Understand where you are at present and where you want to go. Then you can make calculations about how far you have to go. Also define the milestones or interim destinations along the way. The past several decades of experience in the IT profession teaches CIOs not to attempt “big bang” strategies. These types of strategies try to move IT organizations directly from where they are to where they want to go in one mighty leap and they usually fail. Instead define a sequence of interim destinations that creates a path to follow to the desired final destination. Then make calculations for getting from where you are currently to the next interim destination on your path. Act effectively to manage risk requires that a CIO makes sure the journey between these interim destinations can be accomplished in three- to nine-month steps and that each step produces value in its own right. An interim destination cannot be just some midway point that still requires

10

chapter 1

harnessing it to drive enterprise strategy

IT strategy evolves over time with each cycle though this process

1. MAP OUT THE BIG PICTURE

•

• 4. EVALUATE CHANGES

•

• •

Interim IT destination provides new capabilities to move to the next destination Look for new opportunities or threats Assess ways to use new capabilities to seize opportunity and counter threat

• 3. ACT EFFECTIVELY TO MANAGE RISK

•

•

1.2

2. DECIDE HOW TO GET FROM HERE TO THERE

• Define the best

•

EXHIBIT

Show the enterprise facilities that IT supports and the capabilities that it needs from IT Identify present state of IT infrastructure and desired future state

sequence of interim IT destinations Determine how to reach the next interim destination in the sequence

Reach successive interim destinations every 6–9 months Interim destination provides value in its own right Changes in staffing, operations, and technology are manageable

Fo u r St e p s t o St r a t e g y Fo r m u l a t i o n

more work in order to be of any tangible value. In the context of IT this means that the interim destination must be a functioning system or operating process, not just an analysis document or a set of specifications. The system delivered at an interim destination must be able to go into production and begin repaying the cost of the work to produce it. Design each three- to nine-month step so that changes in staffing, operations, and technology are affordable and manageable. Remember that systems are people, procedures, and technology combined in a coordinated way. Do not attempt changes in these three areas that are beyond the capability and capacity of your organization. Be honest about what is possible and what is probable. Evaluate changes happens upon completion of each three- to nine-month step. The interim destination at the end of each step provides a base from which to take the next step but does not lock the IT organization into any rigid, preset sequence of next steps. The world will probably have changed in the past three to nine months. Take the opportunity to pause for a moment and check out the lay of the land again. Reaching an interim destination gives the CIO a new position and new

strategic guidelines for designing it systems

11

capabilities. How can you best use this position and your new capabilities to capitalize on the opportunities that change may have brought your way? Or you can consider how best to counter a threat that just emerged. Either way, make decisions in light of the need to continue steering the IT organization toward delivering the capabilities needed by the enterprise to reach its stated goals.

strategic guidelines for designing it systems System designs reflect the IT strategies being used to enable the enterprise to achieve its performance targets. Good strategies and good system designs are two sides of the same coin. All system designs are not created equal. Some designs and the strategies they support are clearly superior to others, and there is an objective way to identify these superior designs. This section discusses seven guidelines for designing systems that reflect IT strategies (see Exhibit 1.3). The best system designs follow all seven of these guidelines. A passable design can ignore one of them as long as it isn’t the first guideline. However, any design that disregards more than two of these guidelines is fatally flawed and will lead to failure.2 The seven guidelines are discussed in the following sections. Positive Guidelines Guideline 1: Closely align systems projects with business goals. For any systems development project to be a success it must directly support the company to achieve one or more of its goals. No new system can be effective until the CIO has first identified or created the business opportunity that will make the system worth building, and no new system will bring any sustained benefit to the company unless it supports the efficient exploitation of the business opportunity it was built to address. Guideline 2: Use systems to change the competitive landscape. Look for tasks and activities that seem impossible today, but if they could be done, would fundamentally and positively change the ways the enterprise does business. Put yourself in your customers’ shoes. In the words of the Nordstrom’s motto, think of what would “surprise and delight” your customers. Look for opportunities to create a transformation or value shift

12

chapter 1

harnessing it to drive enterprise strategy

POSITIVE 1. Closely align systems development projects with business goals and specific performance targets. 2. Use systems to change the business landscape. 3. Leverage the strengths of existing systems. 4. Use the simplest possible combination of technology and process to achieve the maximum number of objectives. 5. Structure the design so as to provide flexibility in the development sequence used to create the system.

NEGATIVE 6. Do not try to build a system whose complexity exceeds the organization’s abilities to support it. 7. Do not renew a project using the same organization or the same system design after it has once failed. EXHIBIT

1.3

Strategic Guidelines for Designing Systems

in your market. Find ways to do things that provide dramatic cost savings or productivity increases. Then place yourself in your competitor’s shoes and think of what course would be the least likely to be foreseen or quickly countered or copied. As long as you are able to do something of value that your competitors cannot, you have an advantage. Guideline 3: Leverage the strengths of existing systems. System design embodies strategy. When existing systems have proven to be stable and responsive over time, find ways to incorporate them into the design of new systems. The purpose of strategy is to use the means available to the organization to best accomplish its goal. Build new systems on the strengths of older systems. Nature uses the same principle in the evolutionary process. New systems provide value only insofar as they provide new business capabilities. Time spent replacing old systems with new systems that do essentially the same things will not, as a general rule, provide enough value to justify the cost.3

strategic guidelines for designing it systems

13

Guideline 4: Use the simplest combination of technology and business procedures to achieve as many different objectives as possible. A simple mix of technology and process that can achieve several different objectives increases the probability that these objectives can actually be achieved. This simple mix reduces the complexity and the risk associated with the work and spreads the cost across multiple objectives. Using a different technology or process to achieve each different project objective multiplies the cost and the complexity and reduces the overall probability of project success. Guideline 5: Structure the design so as to provide flexibility in the development sequence used to create the system. Break the system design into separate components or objectives, and whenever possible, run the work on individual objectives in parallel. Try to prevent the achievement of one objective from becoming dependent on the achievement of another objective. In this way, delays in the work toward one objective will not impact the progress toward other objectives. Use people on the project who have skills that can be applied to achieve a variety of different objectives. Using the same technology to achieve several different objectives makes it much easier to shift people from one objective to another as needed because they use the same skill sets. The project plan should foresee and provide for an alternative plan in case of failure or delays in achieving objectives as scheduled. The design of the system you build should allow you to cut some system features if needed and still be able to deliver solid value to the business.

Negative Guidelines Guideline 6: Do not try to build a system with a level of complexity that exceeds the organization’s capabilities. The beginning of wisdom is a sense of what is possible. When defining enterprise goals and the systems to reach those goals, aim for things that are within reach. Set challenging goals but not hopeless goals. The people in the IT organization need to have confidence in themselves in order to rise to a challenge. Avoid exhausting their confidence in vain efforts to reach unrealistic goals. Guideline 7: Do not renew a project using the same organizational approach or the same system design after it has once failed. Re-doubled

14

chapter 1

harnessing it to drive enterprise strategy

hard work and effort are an inadequate response for ensuring the success of a project after it has once failed. People are usually demoralized after the first failure and will not rise to the challenge of doing the work again unless there are meaningful changes in the project approach. The new approach must clearly reflect what was learned from the previous failure and offer a better way to achieve the project objectives. Using these Guidelines: A Real-World IT Strategy For six years I was the CIO of a member-owned, national distribution cooperative named Network Services Company (NSC) that served customers such as national restaurant chains, national property management companies, and healthcare companies. NSC provided products and supply chain services related to food service disposables, janitorial and sanitary supplies, and printing paper. The strategic use of IT resulted in significantly increased sales revenues by enabling the company to enter several new markets. It also reduced operating expenses and provided the internal productivity needed to handle the business growth with only minor increases in staffing levels. During a four-year period the company’s operating model went from almost no electronic commerce except for a little EDI activity to most of its revenue coming in as electronic transactions—from customer order entry to final invoice payments. During this time the company’s revenue more than doubled and customers began requiring supply chain services they had never asked for in the past. We had to find new ways of operating if the company was to survive and thrive. This necessity brings out the CIO’s resourcefulness and creativity, two essential components of good strategy. Resourcefulness demands that the CIO work more efficiently and take new approaches. Sustainable creativity requires the discipline to adhere to the seven strategic guidelines mentioned earlier. Otherwise creativity becomes an end in itself, and it can take a CIO on fantastic voyages and flights of fancy that have no chance of success. The past 20 years of business are littered with highly creative, yet strategically irrelevant uses of IT that never achieved success. NSC retained a prestigious management-consulting firm to assist in its strategic planning exercise. This exercise identified five goals for the business

strategic guidelines for designing it systems

15

and suggested some strategies for accomplishing these goals. One of the business goals was to develop the e-business systems infrastructure needed to further integrate the member companies into the cooperative organization and allow NSC to better serve national account customers. At the end of the strategic planning process, the consulting firm very strongly recommended that we build and operate our own state-of-the-art, Web-based, order entry and product catalog system. They offered to begin work on it immediately. That was what everyone else was doing at the time. It is what our biggest competitors were doing. I, however, strongly advised against this course of action because it violated four of the seven strategic guidelines. The first guideline this approach violated was, “Use systems to change the competitive landscape.” Web-based order entry systems were already in use by our competitors and it wasn’t clear how much immediate demand there really was for them. It would only be a catch-up or a “me too” move on our part and yet, at the time, would have required the bulk of our IT development budget to build our own system. It seemed far more consistent with this guideline to make our major effort and expenditure in a different area that gave us potential to acquire new business capabilities not then possessed by our competitors. The next guideline this approach violated was, “Leverage the strengths of existing systems.” Web-based order entry systems were already available from e-commerce service providers who would let us lease the use of their systems for a small per-transaction fee and a modest up-front cost to get started. Another violated guideline was, “Use simple combinations of technology and business procedures to meet the system’s performance requirements.” Building and operating our own Web-based order entry and catalog system meant a significant amount of technical complexity, and it was much simpler to use an e-commerce service provider for this. “Do not try to build a system with a level of complexity that exceeds the organization’s ability to support it” was the fourth guideline ignored by this advice. Initially, NSC had a relatively small IT group that focused on supporting a basic set of business systems running on a mid-range IBM computer. There were also a few people devoted to supporting e-mail, a simple Web site, and office productivity software running on a local area network. The sudden leap from what then existed to an expanded IT staff

16

chapter 1

harnessing it to drive enterprise strategy

and state-of-the-art systems infrastructure operating 24/7 in real time over the Internet was clearly beyond the capability of the company to do all at once. It was better to grow into this over time. So I used the seven guidelines to facilitate a process of selecting and combining different ideas until a truly resourceful and creative IT strategy emerged. The strategy called for construction of a suite of four systems that each provided value in their own right and worked together to deliver an e-business infrastructure with the performance capabilities we needed. Those systems were built with a mixture of simple technology and offthe-shelf software packages. As a consequence, we spent only a fraction of what our competitors did. The first version of our e-business infrastructure was up and running in nine months, whereas our competitors took much longer to get their infrastructure in place. The four systems were: 1. A computing and communications infrastructure and data center to run the e-business systems and provide a virtual private network (VPN) to ensure data security for people using the systems. 2. An enhanced Web site (Web portal) with a link to an outside service provider for Web-based order entry and an internally developed sales history reporting system for use by customers. 3. A data warehouse to store and retrieve data needed by the sales history reporting system and to support our internal business intelligence needs. 4. An Internet-based data delivery system to provide electronic, two-way data transfer between the different computer systems of our members, customers, and suppliers. We named this system “NetLinkNSC”™. In the following years we continued to enhance these systems with new features as needed. We used the capabilities these systems provided to form supply chain partnerships with new and existing national account customers. These systems allowed us to work cooperatively with them to lower their overall cost of purchasing and using our products without requiring us to just reduce prices on the items we sold them. The company was able to command slightly higher gross margins than its competitors because customers were willing to pay a bit more in order to get the

match strategy execution to the tempo of your business

17

customized bundle of value-added services that we could provide them thanks to the IT infrastructure we developed. This strategy was particularly successful in growing the business in a new vertical market segments. One segment was the national building service contractor (BSC) market. These are companies that contract with property managers to clean office buildings, shopping malls, healthcare facilities—a very fragmented market that was consolidating into national chains. Our systems provided BSC customers with both e-procurement capabilities and daily updated sales history reporting. Their managers could get online reports that showed consumption of supplies by job site, by product, and by manufacturer over any time period they specified. Our e-business systems provided customers with key tools that allowed them to manage operating expenses and realize the economies of scale that supported their profit margins. By partnering with us, customers avoided the expense of building their own supply chain management systems. I structured the development and rollout of these systems into phases that each took three to nine months, as shown in Exhibit 1.4. Each phase created a set of production subsystems that became the basis upon which to build further subsystems or enhancements. As these phases were completed, we were able to take stock of the changes in our markets and respond appropriately to opportunities as they presented themselves.

match strategy execution to the tempo of your business Just as farmers and people who make their living from the land have a rhythm to their lives that is set by the four seasons, so too do corporate CIOs (whether they know it or not). Instead of the four seasons we in business have the four quarters. Each quarter has its demands and opportunities. Like good farmers who prosper by responding appropriately to each season, effective CIOs make the best use of the opportunities and risks presented by each quarter if they are to prosper. The rhythm of the quarters isn’t quite as well defined as the rhythm of the seasons, but there is a certain tempo in each quarter’s activities for most enterprises. The first quarter’s tempo is quick—get out of the gate and get started on the year’s major development projects. The second

The strategy was broken into four phases. Each phase provided value in its own right and built upon the previous phase.

PHASE 1 Build version 1.0 of supply chain system (9 Months) PHASE 2 • Build Internetbased system to link to customer and member computer systems

Assist member companies (3 Months)

• Build data warehouse

PHASE 3

• Build sales history reporting system for use by customers • Enhance NSC Web site to provide customer order entry and sales history reporting

• Connect new e-business system with members’ systems • Enhance data warehouse and sales history reporting to support member companies

Build version 2.0 of supply chain system (9 Months) PHASE 4 Enhance • e-business system with ability to handle EDI, FTP, and XML • Enhance data warehouse and sales history reporting with additional requested features •

YEAR ONE EXHIBIT

Strateg y

18

1.4

Introduce use of EPC numbers for product ordering and sales history reporting

Integrate into supply chains (Quarterly)

• Connect with systems of customers and manufacturers in the markets we serve

YEAR TWO

Supply Chain Systems Development

match strategy execution to the tempo of your business

19

quarter’s tempo is more measured—to achieve the first round of project milestones and make any needed mid-course corrections. In the third quarter, work on the new systems and enhancements needs to be completed and put into production. In the fourth quarter the successful CIO reaps the benefits of a good harvest and begins planning projects for the coming year. In the first quarter, the CIO has 30 days to finalize IT project selection agreements with business executives. That means understanding the business strategy and the IT alignment needed to support that strategy. In the last 60 days of the first quarter the CIO needs to see to it that project teams of qualified people are assigned to each finalized project and that they get off to a fast start. Each team has to understand the business goals of their project and define the performance requirements for the system they will build. The team comes up with a conceptual system design showing high-level business processes and the technology they will use to support those processes. They also do an ROI analysis and adjust their conceptual design as required so that the cost of the system doesn’t exceed the value of the benefits it will deliver. Although the CIO may not actually do all this work, the CIO still provides guidance and makes sure it gets done in a timely fashion. In the second quarter project teams flesh out their conceptual system designs and prototype the system user interfaces and technical architectures. A prototype either verifies a system will work as expected or the system has to be rethought and prototyped again. Then the team produces a set of detailed design specifications to build the system. Those design specs are the workflow process maps, the system data model, the user interface, and the system technical architecture. The CIO should watch this process like a hawk. The CIO guides, assists, and cajoles the teams as necessary to keep them on track and on time. By way of analogy, when farmers in the American Midwest talk about their corn crop they say, “It needs to be knee-high by the fourth of July.” If it isn’t, there’s not much hope of a good harvest in the fall. If project teams haven’t finished their detailed system design specs by the end of the second quarter, there isn’t much hope that they can deliver anything by the end of the third quarter or even the fourth quarter. In the third quarter the project teams focus on building their systems. By

20

chapter 1

harnessing it to drive enterprise strategy

the end of the third quarter the first versions of the new systems and business processes should be rolling out to people who will use them. If this isn’t happening by the end of the third quarter, there won’t be any rewards for the CIO to reap in the fourth quarter. In the fourth quarter the CIO assesses the impact of the new systems and begins discussions with fellow business executives about next year. The CIO needs to produce a good harvest of system deliverables in the current year so that people feel good about fully funding an IT budget proposal for the year to come.4

tactics are the methods that get things done Once strategy has been defined, the game is all about tactics. The execution of any strategy depends on the effective use of tactics. Our profession has had enough experience by now to know that there is a right way to run projects, and the CIO is responsible for ensuring that development teams use appropriate tactics. Every CIO should understand and use a short list of six tactical principles. These principles apply whenever the CIO and IT organization perform development work to deliver a new system or enhance an existing system. Appropriate project tactics follow these six principles, and there is no convincing reason to violate any of them. Follow these principles and you can tailor specific tactics for any project and enjoy consistently good results. Ignore any one of them and you undermine the effectiveness of the others—so use them all. Principle 1. Every project needs a full-time leader with overall responsibility and the appropriate authority—the system builder. There must be a single person responsible for the project’s success who is totally focused on getting the job done. This person must also have the authority within the project to make decisions and act quickly without having to get permission from senior management. System builders always appreciate having the backup of a steering committee or management oversight group to which they report, but a committee cannot make decisions in a timely manner. If a qualified system builder is not in

tactics are the methods that get things done

21

place, the progress and cost of the project will reflect the absence of such a person—progress will be slow and costs will be high. Principle 2. Define a set of measurable and nonoverlapping objectives that are necessary and sufficient to accomplish the project goal or mission. It is crucial that the CIO and the ststem builders define clear project objectives so that the people who are assigned the responsibility to achieve these objectives know what is expected of them. It is very important that the boundaries of these objectives do not overlap because if they do, the overlap will cause confusion and conflict between the teams assigned to achieve these overlapping objectives. Make sure each objective is absolutely necessary to the accomplishment of the project goal. Do not pursue an objective just because it seems like a good idea. Finally, when all the objectives have been achieved, that must be sufficient to accomplish the mission or the goal set by the CIO. The set of objectives must cover everything that needs to happen. Principle 3. Assign project objectives to teams of 2–7 people with hands-on team leaders and the appropriate mix of business and technical skills. Put together a project team of two to seven people who in your judgment have among them the necessary business and technical skills and experience to address the issues that you expect to arise in achieving the objectives you delegate to them. A team is a self-organizing group of people with complementary skills such that all members contribute their strengths without being penalized for their weaknesses. Each member of the team concentrates on the aspects of designing and building the system that they are best at and/or most interested in. A properly configured team enables the team leader to delegate tasks to people who are interested in these tasks. People spend most or all of their time doing tasks they are interested in and little or no time doing tasks they are not interested in. Within a team, the operative word is “we”, not “me”. The whole team is rewarded for successes and takes responsibility for mistakes. Singling out superstars or scapegoats undermines team morale and performance.

22

chapter 1

harnessing it to drive enterprise strategy

Principle 4. Tell the teams WHAT to do but not HOW to do it. Point a project team in the right direction by giving them a well-defined project goal and clearly identify the project objectives for which they are responsible. The objectives define the outcomes that they must deliver to be successful. The project goal and the objectives that the CIO delegates to a team define the game that the team should play. The team itself must then go through the process of creating their plan to achieve the objectives that the CIO has defined for them. General Patton said, “Tell people what you want but don’t tell them how to do it—you will be surprised by their resourcefulness in accomplishing their tasks.” The teams can make changes or additions to the objectives they are given as long as you and they agree that the modified objectives are still necessary and sufficient to accomplish the project goal. Principle 5. Break project work into tasks that are each a week or less in duration and produce something of value to the business every 30–90 days. Encourage project teams to structure their project plans so that each task can be accomplished within a week or less and has a well-defined deliverable. Track these tasks as either started, delayed, or finished. Do not fall into the trap of tracking tasks by their percentage of completion because it is unclear what “percent complete” really means. A task is either started or not; if started it is either completed or delayed; and completion occurs when the task deliverable has ben created. The system builder must be able to track progress at the task level of detail in order to keep accurate projections of the time to complete and the cost to complete for each of the project’s objectives. Multi-week tasks make progress hard to measure, and they are the ones that suddenly surprise the system builder. Multi-week tasks reported by the percent complete method often seem to show good progress, but then in the last week they suddenly turn out to be nowhere near completion. Project tasks should combine to produce something that is of value to the enterprise every 30 to 90 days. This provides the opportunity for the business to verify that the project is on the right track. It also provides subsystems that the business can start to use even before the entire project is completed and begin to see some return on the cost of the project.

getting things done and delivering value

23

Principle 6. Every project needs project office staff to work with the system builder and team leaders to update plans and budgets. The project plan and budget are analogous to the profit and loss statements for an enterprise. They must be updated continuously and accurately in order to provide the people running the project with the information they need to make good decisions. There is a common but misguided notion that the system builder and team leaders should be the ones who keep the plans updated. This is analogous to the idea that the president of a company and its managers should spend their time keeping the enterprise’s books. Just as there is an accounting department to keep the enterprise’s books, there needs to be a project office group that keeps the project’s plans and budgets current. The project office staff reports to the system builder and works with the team leaders on a weekly basis to review and update the plans and budgets associated with each team objective. In this way the system builder can accurately monitor project progress and the team leaders are able to focus on running their teams rather than filling out reports (see Exhibit 1.5).

part 2 getting things done and delivering value The hallmark of successful CIOs is that year after year they consistently get things done and deliver value to the enterprises that employ them. These successful CIOs have in common a handful of characteristics. The short list here comes from my own experience and from talking with and reading about other CIOs over the past 20 years. If you feel I have left out an important activity I invite you to contact me (my e-mail address is mhugos @yahoo.com). My short list contains these activities: • Illustrate and quantify the IT strategy • Communicate constantly • Explain and train • Use a participatory decision-making process • Master the “operational art” • Know the difference between boldness and recklessness

24

chapter 1

harnessing it to drive enterprise strategy

1. Every project needs a full-time leader with overall responsibility and authority. 2. Define a set of measurable and non-overlapping objectives that are necessary and sufficient to accomplish the project goal or mission. 3. Assign project objectives to teams of 2–7 people with hands-on team leaders and the appropriate mix of business and technical skills. 4. Tell the teams WHAT to do but not HOW to do it. 5. Break project work into tasks that are each a week or less in duration and produce something of value to the business every 30–90 days. 6. Provide project office staff to work with the project leader and team leaders to update plans and budgets. EXHIBIT

1.5

Ta c t i c a l P r i n c i p l e s f o r R u n n i n g P r o j e c t s

Illustrate and Quantify the IT Strategy A strategy is not worth much if people do not understand it. One of the main purposes of strategy is to provide a common framework that everyone can use to organize their activities and visualize how their own actions move the company toward its stated goals. People need to see how the strategy translates into a believable sequence of steps that gets the enterprise closer to its goals. The best way to do this is with charts and diagrams. Something is wrong with either your strategic understanding or with the strategy itself if you cannot illustrate it in a few clear diagrams. The next two exhibits illustrate and quantify an IT strategy that could have been used at NSC to move the company toward its new business model. Exhibit 1.6 shows how the four e-business systems components would develop from existing IT infrastructure and evolve over several years. Exhibit 1.7 shows more detail to illustrate the activities in a particular year. It also quantifies the timelines and budgets for development projects in the second year of this proposed strategy.

Phase 11 Phase

Phase 22 Phase

Phase 33 Phase

Phase 44 Phase

Build supply chain & e-business systems

Assist Members

Enhance Links to Customers, Suppliers, & Members

Integrated Supply Chains

Existing IT infrastructure

NSC Web O/E NetLink NetLink Ver. 1

NMS

Sales Rpts

Data Whse Ver. 1

Old Web Site

New Web Site

Web, EDI, FTP, XML

Mbr Web O/E

NetLink Ver. 2

Mbr Data Whse

Data Whse Ver. 2 NSC Internet Portal

New Part #s & EPC #s

Year 1

Year 2

EXHIBIT

1.6

Qtr 1

Year 3

Phases of IT Strateg y and Systems

Qtr 2

Qtr 3

NETLINK UPGRADES Routing of all incoming POs to NetLink from EDI, buy sites, etc. Automated operation, XML and FTP capabilities EDI UPGRADE Install new package and automate operations

Qtr 4

$999,999 IT Project Team “A”

$99,999 EDI Support Group

ENHANCEMENTS TO SALES HISTORY REPORTING Flexible roll up logic defined by customer, more report formats

$999,999 IT Project Team “B” $999,999 IT & Inventory Mgmt Team

NEW NSC PART NUMBERS Re- engineer the NSC part numbering system. Make part numbers vendor specific, provide one-to -one translation between NSC and members part numbers, maintain computerized translation tables.

AR / AP ENHANCEMENTS Other modifications requested ASSIST MEMBERS USING TIBERSOFT FOR LOCAL CUSTOMERS Work with members to help set up their product catalogs and prices on Web O/E via NetLink TRANSITION MEMBER COMPANIES TO NETLINK FROM NMS Work with members to help them set up NetLink in their companies RE -WRITE REBATE SYSTEM Re -engineer data collection process and re -write system

$99,999 System Vendor $99,999 IT & Customer Service Team

$99,999 IT & Customer Service Team $999,999 IT & Product Mgmt Team

DATA WAREHOUSE INFORMATION ACCESS Enh ance data whse and train NSC staff to access data they need for their work

EXHIBIT

1.7

$999,999 IT Project Team “C”

T i m e l i n e s a n d B u d g e t s f o r Ye a r Tw o 25

26

chapter 1

harnessing it to drive enterprise strategy

The actual strategy used by NSC was different from the one depicted in these exhibits. The point is that, as CIO, I was able to play an important role in shaping the company’s strategy by presenting my ideas in this kind of graphic format. This format allows people to quickly grasp the essential outline of a proposed strategy, and it facilitates productive discussions about possible modifications or alternative strategies. Note that the phases of this proposed strategy are each three- to ninemonths long. Good IT strategies deliver tangible benefits within time frames like this. Note also that each phase builds upon the deliverables of the previous phase to continue to build out the systems infrastructure needed to support the enterprise’s changing business model. Communicate Constantly After illustrating and quantifying the IT strategy it becomes the CIO’s message to the world—a message to be communicated constantly to a range of different audiences. When you do this job well you begin to feel like a candidate running for elected office because in a sense you are. You must solicit the approval of enough people to make your strategy a reality. The execution of strategy is all about getting things done. And to get things done you need the active cooperation and participation of a lot of people, all of whom have slightly different agendas. The CIO must constantly explain what is in the IT strategy for them and why they should actively, vocally support the IT strategy. The CIO also listens to people’s responses and makes adjustments to IT strategy when necessary. Remember that the business goal (the destination) usually remains steady over a two- to four-year period but the way to reach that goal (the strategy) can change as the situation unfolds. Listening to how people respond to your message is the other half of sound communication. The message needs to evolve so that people buy into it. They buy in and become supporters of your strategy when they know you are listening to what they have to say. Explain and Train Inside the universe of groups with which the CIO communicates, a smaller subset of people either builds or uses the systems called for by IT strategy. The CIO must pay even more focused attention to these groups.

getting things done and delivering value

27

With these people the CIO moves beyond communicating the strategy and listening to feedback. Spend considerable time one-on-one and in small group settings explaining the details of the tactics being used and why those tactics can deliver success, and make sure people get the training they need so they can perform the tasks that the tactics demand of them. People want to be part of a winning project. They want to understand how the work will be done (the tactics being used). When they understand the tactics and believe those tactics can bring success they buy into the project wholeheartedly. Then the CIO steps back and lets them do their jobs. When people do not buy into a project they require constant supervision and cajoling to get anything done. An unwillingness to participate also tells you something very important. It tells you that your tactics may well be flawed. Remember, tactics are composed of sequences of techniques. Every job and profession has a core set of techniques; in the IT profession some of the core techniques are process mapping, data modeling, and object-oriented design and programming (see more about these core techniques in Chapter 3). Make sure you know what techniques are required for the tactics you use, and make sure people receive adequate training in those techniques. Use a Participatory Decision-Making Process CIO leadership styles are judged by the decision-making processes they use. The more open a CIO’s decision-making process, the more opportunity to get the commitment and active participation of those who will actually do the work. If done effectively, an open decision-making process is an extension of the communication, explanation, and training you provide. The CIO, however, remains ultimately responsible for setting and carrying out the IT strategy, and some decisions need to be made by the CIO alone. People expect the CIO to make the tough calls when there is no consensus among lieutenants, when there is not enough information, and when time is short. But otherwise people do not like dictators. The best, most competent people in particular, want an active voice in the decision-making process. As the leader of the decision-making process, the CIO’s role is to see that timely and accurate information is available and that people get a chance to examine it, ask questions, and voice their

28

chapter 1

harnessing it to drive enterprise strategy

opinions. The CIO’s role is to ask questions that focus people’s attention on the important issues. Keep people from wandering off subject, bemoaning past mistakes, and discussing personalities instead of issues. When the CIO acts as a participatory leader, consensus decisions usually emerge that combine the collective wisdom of the entire management team. Encourage people to take ownership of their decisions and act on them without your constant oversight. In my experience there are five elements that create an effective decisionmaking process. They must all be present because their cumulative effect produces the best participatory decision-making process. Those five elements are: 1. A functioning project management office (PMO) 2. Relevant data displayed in easily understandable “dashboard” summaries 3. Regular weekly meetings 4. Obligation to dissent 5. Trust Much has been said and written about the need for a project management office or PMO. In actual practice many IT organizations pay lip service to the idea and do not have full-time qualified staff devoted to the PMO. They expect already overworked project leaders to also do the work of the project office. The PMO provides weekly updated project plans and budgets as well as accurate reports of operating expenses to date. As discussed in the section on the six tactical principles for running projects, these activities are a full-time job. Expecting project leaders to do this in their spare time is like expecting business unit managers to also do the business unit’s bookkeeping and accounting in their spare time. Dashboards are a way of displaying the most important information about a project in a layout that can be quickly scanned and understood by everyone, not just data analysts, engineers, or accountants. Project leaders should not be overloaded with detailed data or have to spend the time and effort reading through reports and piecing together data just to get a clear picture of what is happening. By way of an analogy, a racecar driver needs a quick display of the car’s key performance indicators, not a detailed dump of engine statistics.

getting things done and delivering value

29

Regular weekly meetings are the forums where project leaders responsible for implementing IT strategy come together, review up-to-date project plans, budgets, and dashboards, and make decisions. The CIO has frequent informal, one-to-one meetings throughout the week with individual project leaders, but projects also need regular full group meetings so that everyone can stay current with the big picture and understand how their individual projects combine to enable effective execution of the full IT strategy. The CIO sets the tone and the pace of these regular meetings. The tone must be positive, focused on issues not personalities. Everyone must feel empowered to voice their opinions and share their ideas. The pace of these meetings should be brisk. These are not leisurely (or boring) recitations of routine reports. The CIO focuses discussion on important issues with the aim of making decisions and taking action. If not much has happened in a given week the meeting can be short. If much has happened, the meeting is longer. Attendance is mandatory because the group only discusses serious issues and everyone lives by the decisions made at these meetings. Leaders who really want the benefits of a participatory decision-making process encourage and respect the obligation to dissent. I tell my own staff that part of their job is to make sure I don’t go off on a tear and do something stupid. That means they need to speak up if they see something I miss. I may be so focused on one aspect of a situation or so in love with some idea that I miss something that could lead to serious trouble. This concept is put to good use by organizations such as the U.S. Marine Corps.5 These organizations have learned over time that only a frank discussion of issues and options can consistently produce competent results. Decisions lose consistency when people believe that their role is merely to keep their opinions to themselves and rubber stamp whatever the boss thinks is a good idea. If that is the case, lots of bad ideas will find their way into actions that only lead to failure. Trust is the glue that holds any group together—a glue that is hard to create and very easy to destroy. People speak up when they trust they will not be penalized. People follow a leader when they trust that the leader will not set them up to fail. Leaders get things done because they delegate authority and resources to people they trust to do the jobs that need to be done.

30

chapter 1

harnessing it to drive enterprise strategy

When trust breaks down action grinds to a halt. Nobody makes a move without first getting written permission. Nobody grants permission without first doing a full investigation. Matters soon deteriorate into superficial public posturing and conspiratorial whispering in private. Everyone becomes afraid of being made into a sacrificial victim to atone for the mounting list of failures that inevitably result from the breakdown of trust. Master the “Operational Art” Strategy is about defining a way to reach a desired destination. Tactics are about competently executing your chosen projects. Somewhere between high strategy and the tactical details embedded in the operations of any particular project lies that place where you must first choose your projects. This is a place where the CIO learns to see opportunities and risks from an operational perspective and develop an appreciation of their potential. CIOs can choose from many potential projects to implement their strategies, but how do they select the project with the best strategic fit? Time teaches successful CIOs how to master this operational art. Mastering the operational art has been described as “knowing when a tactical move can deliver strategic results.”6 Effective CIOs develop a keen sense of the operational art. They see opportunities to employ available means to achieve breakthrough results. Where others see only obstacles, masters of the operational art see openings. To illustrate this, I once worked for a company that had just won a contract with an important new customer. But to get the contract we lowered our prices and agreed to a 12-month contract term instead of the threeyear term we usually requested. We also agreed to only a portion of the customer’s business because they had already awarded the other portion to one of our competitors. By playing us off against our competition, they wanted to see how we both performed before awarding a longer exclusive contract to either of us. At a senior management meeting one day we heard that this new customer was showing up on the slow pay list. They had agreed to pay us within 15 days, but were actually taking from 45 to 60 days in some cases. We knew they were not a credit risk, so why were they taking so long to pay? It impacted our cash flow, increased borrowing against our bank line of credit, tied up collections staff, and further lowered profitability on the account.

getting things done and delivering value

31

Upon hearing this the CFO said the customer had violated the terms of their contract and they should either pay all of their past due amounts right away or he was going to put them on credit hold and we would not ship them any more product. The sales VP protested the harshness of that recommendation and began arguing for extended credit terms. He said part of the problem was that the customer’s line managers who ordered our products had to personally review all our paper invoices and type them into their accounts payable system before they could be paid. Many of those managers were so busy handling their rapidly growing business that they sometimes had to work evenings and weekends just to complete administrative tasks like approving our invoices. I saw an opening. I saw an opportunity to use our IT capabilities to provide a service that would help the customer streamline their ordering, receiving, and payment process. I saw a way to increase their managers’ productivity, differentiate us from our competitor, and help us win all their business without having to further drop our prices. What was this opportunity? By using our EDI system we could send them electronic invoices that arrived before our delivery trucks. The electronic invoices would be automatically imported into their payables system. Then their managers could call up our invoices on their system and check off line items as they unpacked our shipments. If everything was consistent, the press of a button released the invoice for payment. If there were problems we would learn about them sooner and could fix them faster. Once this new receiving process was in place we could then move on to provide the customer’s managers with our online product catalog and order entry system to speed up the ordering process and further reduce errors. Implementing this idea cost me no more money than what was already in my operating budget. The customer liked the idea. We had a pilot program up and running within 60 days. The customer began to see us as a true business partner and not just an anonymous supplier. CIO Risk: Know the Difference Between Boldness and Recklessness In my own experience and in talking to and reading the works of people who know even more than I do, I find that boldness is based on the ability

32

chapter 1

harnessing it to drive enterprise strategy

to understand the difference between a smart, calculated risk and a foolish gamble. A smart, calculated risk is an action that is not a certain success but one that has potential to deliver extraordinary rewards compared to the risks taken. A foolish gamble is one that delivers a small reward at the cost of risks bearing dire consequences. CIOs need to clearly understand the potential upside of a project in comparison to the magnitude of its downside. Unless there is literally nothing to lose, never take a risk where the magnitude of the downside could overwhelm your ability to recover and exit from the situation intact enough to try again another day. To illustrate, let me relate the story of the “great generator gamble”. I have run the IT operations at several companies. I was once in charge of the IT group at a company where the CEO had gone on a tear about cutting expenses. He denied requests from managers to replace broken office lamps, he checked to see that people booked tickets on the cheapest airlines, and he began micromanaging everyone’s operating budgets. One hot summer day we experienced power brownouts in the office park where we worked. Then suddenly the power went off altogether and the building went dark and quiet. The computer room stayed lit and our systems stayed up, but we should have immediately heard the roar of the generator out back as it kicked in to power the office. The generator did not come on and we realized our systems were running on the batteries of the UPS unit (uninterruptible power supply). We had only about 30 minutes of power. If the power grid did not come back on in the next few minutes we would have to start an orderly shut down of the systems while we still had time to do so. The power did come back on. We looked at each other and thanked our lucky stars. We called a service technician to check out the generator right away. He found that although the generator turned on when we ran our monthly tests, the fail over switch that sensed when the power grid went down was not working. We replaced the switch. Then we ran another test that weekend. We turned off power to the building to see if the generator came on. The generator came on but within minutes it overheated and shut itself down when subjected to the full load of carrying the office. This started a sequence of tune-ups, repairs, and tinkering to try to get the 18-year-old generator to actually work

getting things done and delivering value

33

under real conditions. After another few days and several more tests my staff and I realized the old generator could not be trusted. I drew up a budget request for a new generator. The CEO refused to spend any money. He insisted that we find a way to make do with what we had. In a meeting to discuss the situation he told me the generator light in his new Cadillac car had recently come on and the dealer wanted him to spend a lot of money to fix it, but he had ignored the advice and the problem went away. For the next month and a half we saw more studies, more tests, more generator part replacements, and more meetings. Under the CEO’s direction, the CFO got involved and started an inquisition to determine what he called “the true facts of the case”. Everyone, including me, retreated to their offices and began writing CYA (cover your a--) memos. It was clear that if anything went wrong everyone would be potential scapegoats in the finger-pointing that would ensue. The CEO was determined to hold the line on spending and make his profit targets for the quarter. Deferring a new generator purchase was one way to do this. The upside was that he looked good and made his budget numbers. The potential downside of his choice would have been catastrophic. It was bad enough if the power went off during the day, but what if it went off at night or on a weekend? The batteries of the UPS unit would last for half an hour and then our systems would experience a hard crash. All our service warrantees explicitly excluded coverage for damage from a hard crash, and we would probably have to replace much of our systems hardware infrastructure. Because our off-site disaster recovery project was also not fully funded it would take weeks to restore our systems. In addition, several of our most important customers had begun using certain of our systems to support their own internal operations. And we had promised them they were properly backed up and covered in the event of power or equipment failure. The CEO did not use participatory decision making nor did he encourage or respect an obligation to dissent in his meetings. Any trust that might have existed among members of the management team quickly disappeared. After two months of high risk and drama a decision was finally made at the beginning of the next quarter to replace the old generator. I left the company soon thereafter.

34

chapter 1

harnessing it to drive enterprise strategy

how to tell a winning project from a loser Enterprises can outsource a lot of functions, but they cannot outsource the activity of looking out for their own best interests. If they do, they wind up in a very weak position where they “depend on the kindness of strangers.”7 The continuous development of new systems to support evolving enterprise strategy requires that CIOs become very good at evaluating project activities and the likelihood of project success as they move through their development life cycle. Three Main Areas of Concern Answers to these questions help people connected with a project make accurate assessments and take appropriate corrective actions. Three main areas of concern need to be investigated on any development project: 1. The goodness of the system design. 2. The progress made in building the system. 3. The competence and confidence of the people on the project. Goodness of the System Design Notions that good designs must include state-of-the-art technology or complex processing logic are entirely misplaced. The goodness of a particular system design is measured by the combination of two probabilities. The first is the probability that the system will meet the performance criteria that were specified for it to accomplish its business goal or mission. The second probability is the probability that the system can be successfully built. The best system designs usually do not use state-of-the-art technology or complex processes for the very reason that newness and complexity tend to introduce uncertainty. Uncertainty reduces the probabilities that the system will perform as expected or that it can be built on time and on budget. The goodness of a system design can be accurately predicted by the extent to which it respects the seven strategic guidelines for designing systems. If a design omits only one of these guidelines—as long as it is not the first guideline—it may still be a good design. When a design disregards two guidelines there had better be very clear and convincing reasons. There

how to tell a winning project from a loser

35

must also be well-thought-out preparations to compensate for design omissions. Designs that disregard three or more of the guidelines will fail. The probability of building a successful system that violates this many guidelines is about the same as the probability of winning the lottery. Progress Made in Building the System Successful development projects move along at a smart pace. The pace of progress must be aggressive or the project tends to lose its focus and begin to wander aimlessly as the world passes it by. An aggressive pace requires two things: (1) rigorous application of the six tactical principles for running projects; and (2) effective time boxing. The CIO is responsible for applying the first tactical principle, which is to make sure there is a qualified full-time leader (system builder) for every project. It is then the responsibility of the system builder to effectively apply the other five tactical principles. There is no convincing reason to ignore any of these principles. When the system builder omits one or more of these principles, you need to do everything in your power to reinstate the missing principles. These principles are mutually reinforcing. Omitting even one principle creates a dynamic that undermines the application of all the others. The second requirement for moving projects along at a smart pace, effective time boxing, means that the activities of each project team are organized to follow a clear “Define-Design-Build” sequence for developing systems. The activities in each of these three phases need to be completed within the time-box constraints and budgets appropriate to each phase. The system builder works with the project team leaders to set the time boxes, and the project teams keep up the pace to meet their selfimposed deadlines. See Chapter 3 for an in-depth discussion of the Define-Design-Build sequence for ways to promote a tactical, agile IT organization. Competence and Confidence of People on the Project People charged with developing new systems must be competent and confident in order to succeed. Competent people who lack confidence move slowly. Confident people with no competence have even more trouble. Systems development people must possess both the know-how and leadership skills. CIOs can measure people’s qualifications. The first type of measurement

36

chapter 1

harnessing it to drive enterprise strategy

determines the degree to which people working on the projects can make good tactical use of relevant analysis and design techniques such as process mapping, data modeling, and system prototyping. Good use of technique is everything for people working on or leading project teams. The system builder and the team leaders need to understand and know when to employ each relevant technique. They must be competent in all relevant techniques and masters of a few of them. Individuals on the project teams must be competent in or masters of the specific techniques they will need to fulfill their roles on the team. The efficient use of relevant techniques allows project teams to complete their work within the aggressive time-box constraints that successful projects demand. The second type of measurement determines the degree to which the system builder and the team leaders are capable of demonstrating the requisite leadership skills. After a period of watching someone in action, most experienced CIOs can make a fairly accurate assessment of that person’s design and leadership skills. When project leaders and team leaders have these skills, good system designs emerge, effective leadership happens without rancor, and a visible air of confidence becomes evident on the faces of the entire project team. Project Evaluation Checklist Goodness of System Design Ask yourself and the system builder in charge these questions for each project. Whenever possible, ask these questions in the first 2–6 weeks (the Define phase) of the project:

1. What is the business goal or mission of the project? In two sentences or less state the action the company is going to take and state the desired result of that action. This goal is the target, the destination the project is supposed to reach. If you do not know where you are going, then you will only get there by random chance. If you cannot clearly and simply state the goal that the system is supposed to accomplish, then neither you nor anyone else really knows what the system is supposed to do. Figure this out or stop the project. 2. What are the performance criteria that the system is supposed to meet? State what requirements the system will meet in four areas:

how to tell a winning project from a loser

37

Business Operations Customer Expectations Financial Performance Enterprise Learning and Improvement These performance measures are the specific measures that determine whether the system is successful. Make sure that you know what they are and that the people designing and building the system know what they are as well. Otherwise, you will get a system that does not do what you want. 3. As an experienced businessperson, do you believe that a system that meets the preceding performance requirements will in fact accomplish the business goal that you are striving to achieve? If you have a feeling that some important performance requirements have been left out, then add them before the project gets any farther along—but make sure you do not add requirements that are not strictly necessary to accomplish the business goal. When the performance requirements become too broad, this will result in increased system complexity and lower the chances that the system can be successfully built. 4. What existing computer systems in your enterprise (that work well enough) are being leveraged in the design for the new computer system? The new system should leverage the strengths of systems and procedures that already exist in your enterprise. Focus the system on delivering new capabilities instead of just replacing existing resources that already work well enough. If you decide to replace everything and build from a clean slate you had better be prepared for the considerable extra time and expense involved, and be sure that it is worth it. 5. How does the overall design for the new system break down into a set of self-contained subsystems that can each operate on their own and provide value? Large computer systems that cost a lot of money are really made up of many smaller subsystems. Your enterprise should be able to build each subsystem independently of the others so that if one

38

chapter 1

harnessing it to drive enterprise strategy

subsystem runs into problems, work on the others can still proceed. Subsystems need to be put into production as soon as they are completed to begin paying back the company for the expense of building them. If all subsystems must be complete before any individual subsystem can be used, you’ve chosen a very risky all-or-nothing system design. Change that. 6. How accurate is the cost/benefit analysis for the new system? Have the business benefits been overstated? Would the project still be worth doing if the business benefits were only half of those predicted? Cost/benefit calculations usually understate costs and overstate benefits. You are the one best able to judge the validity of the benefits—do you believe they are accurate? The bigger and riskier the system development project, the larger the benefits must be to justify the risk and expense. Do not spend more on a system than it is worth. 7. Who is the senior technical person in charge of the project—the system builder? How has this person demonstrated that their system design and project leadership skills are appropriate to the demands of the project? If you do not have a qualified system builder in charge of the project, it will fail from lack of direction—management by committee will not work. People without the necessary design and leadership skills are not qualified and must be replaced no matter what other skills they may possess. Ask the system builder to explain to you which of the strategic guidelines for designing systems have been followed and which have not. For those that have not been followed, why not? If all the seven strategic guidelines are followed, your system design is very good. It is acceptable if one of the guidelines is not followed—any one as long as it is not the first one. If two of the guidelines are not followed there had better be very good reasons, and extra precautions need to be taken to compensate for the increased risk. What are these precautions? If more than two of the guidelines are not followed, then the design is fatally flawed—the system cannot be built on time or on budget if it can even be built at all.

how to tell a winning project from a loser

39

Progress Made Developing the System Ask these questions once the conceptual system design and initial budget have been agreed upon—the end of the Define phase. Ask these questions of yourself, the system builder, and the people on the project team as the project moves through the Design and Build phases.

1. Is there a project plan and budget in place? Do people pay attention to the project plan? Is there a project office group that provides people with regular and accurate updates to the plan and the budget? Multimillion-dollar system development projects involve a lot of people and stretch across some period of time. The project plan is the central coordinating instrument that tells every person at any given time exactly what each are supposed to be doing. If the plan is not kept current, the people on the project have no way to effectively coordinate their work with each other. The system builder will lose track of the details. Delays, cost overruns, and confusion will result. People will lose control of the project budget—they will not know how much has been spent to date or how much more is required to finish. When this happens, the project goes into a death spiral. 2. Are the teams working on each subsystem organizing their work into a clearly defined Design phase and a Build phase? Are these phases getting done within the appropriate time boxes and budgets? Or do time-box constraints keep expanding and budgets keep growing? The project team working on each subsystem should spend one to three months (and no more) to create a detailed design and system prototype (Design phase). The detailed design should then be turned into a working system within two to six months (Build phase). If this work takes any longer, the project is moving too slowly. It will lose momentum and start to drift. It is the system builder’s responsibility to keep things organized and moving— make sure this person is in place and is qualified. 3. Ask the system builder to explain to you how the six tactical principles for running projects are being applied to the running of this project.

40

chapter 1

harnessing it to drive enterprise strategy

Do you believe the answers you hear? Can the system builder explain the situation clearly without “tech talk” and jargon? A qualified person can give you straight answers. The system builder is in effect your general contractor who is running the job. This person can make or break the project—get a new one if you need to. Spot-check the project plan and budget from time to time. Have the system builder review the current, updated project plan with you and explain the situation on the project as of that week. Review the project budget—have the system builder show you the money spent to date on each subsystem and the estimate for remaining time and budget to complete each subsystem. How does the most recent estimate of time and budget compare to the original estimate for time and budget? Is it still worth the cost to complete the project? Competence and Confidence of People on the Project Ask these questions of yourself, the system builder, and the people on the project teams:

1. Ask each of the project teams to make a presentation to you at the end of their Design phase where they show you the design specifications they have created. Ask them to walk you through the process flow diagrams and the logical data model for the subsystem for which they are responsible. Ask them to show you the user interface, the technical architecture diagrams, and the system prototype. Can they tell you how this system will deliver the business benefits that are listed in the cost/benefit analysis? Do the design specifications make any sense? Do the people on the team know what they are talking about? 2. Are the project team members as confident in the success of the project as the project team leaders? Are the team leaders as confident as the system builder? If people feel they have the right skills and believe they have a good system design to work from, they will be confident in their ability to build the system. There is a problem somewhere if people

how to tell a winning project from a loser

41

at every level of the project do not share and reflect this confidence. If people are trying to transfer onto the project, that indicates people have confidence it will succeed. If people are transferring off the project or leaving the company, that indicates people have no confidence and expect it to fail.

■ notes 1. Robert S. Kaplan, David P. Norton, Strategy Maps: Converting Intangible Assets into Tangible Outcomes, (Boston: Harvard Business School Publishing, 2004). 2. Sir Basil Henry Liddell Hart (1895-1970), Strategy, (New York: Penguin Books, 1967). I came across Liddell Hart’s book years ago and found Chapter 20, “The Concentrated Essence of Strategy” to be one of the most lucid and succinct discussions of strategy I have ever read. My seven strategic guidelines for designing systems are much influenced by his book. 3. Kevin Kelly, Out of Control: The New Biology of Machines, Social Systems and the Economic World, (New York: Perseus Books Group Company, 1995). This book has many useful insights for the design and building of systems and many of these insights are summarized in Chapter 24, “The Nine Laws of God.” 4. This section first appeared in an article I wrote for Computerworld magazine titled, “The Rhythm of the Quarters” published 17 October 2005. 5. Jason Santamaria, Vincent Martino, Eric Clemons, The Marine Corps Way: Using Maneuver Warfare to Lead a Winning Organization, (New York: McGraw-Hill, 2004). 6. William Lind, Maneuver Warfare Handbook, (Boulder, CO: Westview Press, 1985). 7. These are the famous words spoken by the vulnerable character Blanche DuBois in the play by Tennessee Williams, A Streetcar Named Desire, (New York: Viking Penguin, 1947).

chapter

2

Architecture, Portfolio Management, Organizational Development—Integrated Foundations for Strategy Realization by anthony hill

It is the goal of every good CIO to align IT strategy to business strategy. No rational businessperson today would argue this premise. However, this simple premise is harder to achieve than is readily apparent. What IT needs to build and deliver to achieve the goals of business strategy can be difficult to identify, and highly debatable depending on one’s point of view within the enterprise. IT systems can be abstract, complex, and difficult to understand. Business processes, enabled by systems, can suffer from the same challenge. An enterprise will have a collection of systems created by different people at different times under different sets of information, constraints, and decisions. Parochial interests of different business units, departments, and key managers can also confound the issue. It is no wonder that an organization can sometimes feel that its IT systems, processes, and people are not in synch with its current strategy and goals. The CIO, IT staff, and other business leaders and staff need to be able to see and understand alignment between IT and business strategy. They need 43

44

chapter 2

integrated foundations

to be able to understand the elements that create alignment and understand their relationship and contribution to those elements. And, based on this understanding, they need to become the champions of the correct behaviors and processes that lead an organization to its alignment and strategy realization goals. The CIO faces an intimidating task aligning an IT organization and a steady stream of large, complex, and risky IT investments to the constantly evolving and adapting business strategies of an organization. Many CIOs have found this goal elusive and difficult to achieve and behaviors and expectations in other parts of the organization often exacerbate the problem. What is needed is a set of guiding principles, processes, maps, guideposts, and milestones that communicate and align IT to the business strategies, which guide both IT and the business. Once business strategy is set, the challenge becomes how to go about aligning IT strategy with business strategy, and doing it in terms that can guide and manage expectations for both the business and IT. This multifaceted challenge requires many disciplines and practices to achieve. There is no one single construct or technique that enables this alignment. Organizational decisions and behaviors need to support and lead to alignment, and this is not a natural process for most organizations. Achieving alignment means choosing the right IT investments, building them the right way and implementing them at the right times to achieve the enterprise synergy and business goals being sought. The ability to actually execute and deliver the initiatives is the difference between success and failure. And, the different systems and processes created need to integrate and create a whole that is greater than the sum of the parts. CIOs have several fundamental, interrelated, and often poorly understood disciplines at their disposal to align IT strategy to the business strategy. Enterprise architecture, IT governance and portfolio management, and organizational development constitute the primary set of practices that enable the CIO to achieve alignment in a constantly changing business environment. The tools and techniques in these three primary practice sets revolve around three long-standing core concepts well known in the systems development disciplines, and which have parallels when one seeks to build and enable an enterprise. People, process, and technology have stood the test of time as the fundamental, necessary components of successful business

integrated foundations

45

solutions. As technology becomes more ubiquitous and as technologies continue to commoditize, emphasis has evolved toward people and processes as the focal areas for gleaning return on investment and competitive advantage from IT investments. Successful CIOs necessarily train their sights on the business and enterprise level and keep their perspective focused on this horizon. The CIO needs to be squarely focused on strategic business goals and enabling and aligning IT to reach those goals. Bringing the focus on people, process, and technology up from the systems/project level and applying it to enterpriselevel IT and business alignment gives the CIO a focal point for IT alignment and the realization of business strategy. People, process, and technology manifest themselves at the enterprise level as IT organizational development and delivery model (people), IT governance and portfolio management (process), and enterprise architecture (technology and related business process). The disciplines in these three primary practice areas become the focus for CIOs entrusted to lead IT and enable business strategy, focus on the customer, and make their organization more competitive in the marketplace. CEOs often state that what they most want from their CIO is the ability to achieve this alignment. In other words, what the CEO wants most is the CIO who can lead IT to achieve the realization of business strategy. The realization of business strategy takes place over long, multi-year periods of time. This is especially true when the strategic goals include profound change or new business models. CIOs who lead by facilitating and enabling these long-term strategies use methods and approaches that endure the challenges and environmental threats posed by long-term change, and that outlast an all too common short-term view on specific projects, implementations, and tactics. The CIO’s methods must accommodate key personnel turnover, changing and competing business and technology priorities, business environment changes, and the need for ever-increasing business agility and flexibility. At the same time, the CIOs must articulate the strategic implications of IT methods so that people at all levels of the business understand how the IT architecture supports their strategic decision making and guides the organization to its stated objectives. This chapter is written for the IT leader who seeks to concretely and comprehensively support the realization of business strategy through

46

chapter 2

integrated foundations

information technology. Specifically, this chapter discusses the interrelated relationships of architecture, IT governance and project portfolio management, and IT organizational development in terms of how their interrelated synergies create a powerful whole, greater than the sum of their parts. This chapter focuses on the key interrelationships of these three practice area disciplines and how the CIO can integrate them to guide the organization in support of enterprise strategic goals.

integrated disciplines CIOs who establish a strategic IT presence at the leadership table bridge the gap between business strategy and the information and technology structure of the organization. At any given point in time, the state of information and technology may not represent what is most important to the organization. As strategic goals change, there is an inherent requirement for flexibility and agility on the part of IT and on the enterprise to adapt as detailed in Chapter 3. The requirement to rapidly adapt to change has become a critical differentiator for competitive, high-performing organizations. Building an agile, adaptive IT organization that constantly works to bridge and minimize the gap between the current-state of information technology and the optimal state required to meet the organization’s strategic goals is the name of the game for the best practice CIO. A series of interrelated practices and disciplines enable the CIO to bridge this gap and directly tie the elements of business strategy to IT investments. Best practice CIOs understand and communicate the current architecture of IT infrastructure, applications, and information for their enterprise and articulate a future-state to be achieved based on the business goals, strategies, and current technological opportunities. They identify the gap between current capabilities and the future-state required to reach strategic goals, and they demonstrate the path to reach the future-state where the strategic goals can be achieved in terms of information technology, processes, and people. However, defining and communicating the current-state, future-state, and gap is only the beginning. The best practice CIO guides organizational behaviors, decision making, and capital budgeting to lead the organization to the destination. Best practice CIOs also control and influence IT investment decision making to ensure that the right investments are being made, that these

enterprise architecture

47

investments are being made at the right time and in the right order, and that these investments and solutions are being constructed correctly to support strategically aligned IT architectural standards. These discrete IT investments need to be managed in unison as a balanced portfolio that supports consciously designed enterprise milestones and targets. Business outcomes that result from a correctly aligned IT investment portfolio lead directly to the realization of business strategy. The best practice CIO delivers these results through people and the IT services delivery model, leveraging in-house staff, vendors, consultants, and outsourcers. Organizational development must align and support the specific skills and services requirements of the enterprise architecture and IT project portfolio. This organizational development requirement is equally true for departments outside the IT function or the CIO’s direct control. This continuum of disciplines and processes can be viewed as a funnel that starts from the broad, overarching goals of business strategy and then moves down through a progressively narrowing set of processes, designs, and managerial disciplines leading to the right set of projects designed around the right architecture and delivered by the team with the right set of strategically aligned skills, objectives, and incentives. It is one of the fundamental skills of the CIO to be able to navigate the organization down this funnel leading to the realization of business strategy enabled by IT (see Exhibit 2.1). The funnel’s path guides the CIO through the critical IT management disciplines that bridge the gap between business strategy and the realization of strategic goals.

part 1 enterprise architecture As discussed in Chapter 1, business strategy today cannot be realized without information technology. The CIO and the IT organization are uniquely positioned in the enterprise to be able to articulate how a business will achieve its strategic goals, at least from the standpoint of technological capabilities, information, processes, and the customer experience. IT generally enjoys the broadest view on an enterprise at the operational level, enabling valuable insight into intra- and inter-enterprise processes, information requirements, operational challenges, and technical requirements. In addition to designing and managing customer-facing systems

48

chapter 2

integrated foundations

S T R AT E G Y R E A L I Z AT I O N EXHIBIT

2.1

Business/IT Strateg y Realization Funnel

and Web sites, IT often maintains close relationships with support and sales operations, all of which create the “customer experience” for the diverse constituency base of an enterprise. This becomes especially true when much of an enterprise’s business is conducted online through e-commerce and self-service vehicles. All of these experiences and visibility give IT and the CIO a unique and broad perspective on what is required for an organization to reach the goals called for by its strategy.

the architectural approach to it

49

It has been said that great leaders “illuminate the road ahead”. As a leader, the best practice CIO articulates and illustrates what technological, process, and business capabilities the organization requires to reach its goals. As solutions providers, CIOs demonstrate the nature and structure of the solution that enables IT customers to reach their goals in terms they can understand. And the CIO needs to be positioned to continually reinforce and communicate the vision and to execute the difficult task of guiding the organization through periods of strategic evolution. One of the tools of IT customer illumination in the CIO’s leadership arsenal is enterprise architecture (EA), which provides the organizational, process, information, and technology roadmap for enabling the capabilities required to achieve the enterprise’s strategic goals. It is the job of the CIO’s organization to be able to communicate and illustrate how and through what technology, information, and process mechanisms the organization will achieve its strategic objectives. Enterprise architecture is a foundational approach to achieving this leadership requirement. To put it another way, the CIO’s enterprise architecture should be the information, technology, and process manifestation of the enterprise business strategies.

the architectural approach to it To understand the application of enterprise architecture to the realization of business strategy and why it is an important best practice for the CIO, it is helpful to begin by looking at a few of the definitions of EA. Organizations can approach the definition and positioning of enterprise architecture in differing ways. For some organizations, the focus of architecture is technical while others take a focus on information, business processes, and organizational structure. Enterprise architecture can be approached top-down as enterprise-wide or driven bottom-up from a project and initiative level. Perhaps the most effective approach is a balance of the two. The final whitepaper for enterprise architecture for the U.S. Chief Information Officers Council describes it this way: “Enterprise Architecture (EA) links the business mission, strategy, and processes of an organization to its IT strategy. It is documented using multiple architectural models or views that show how the current and future needs of an

50

chapter 2

integrated foundations

organization will be met . . . In essence, the EA defines the target architecture at a given point in the future that is necessary to support the business mission and strategy of an organization.”1 The Meta Group (now part of Gartner Group) used the following definition: “Enterprise Architecture is the holistic expression of an organization’s key business, information, application, and technology strategies and their impact on business functions and processes. The approach looks at business processes, the structure of the organization, and what type of technology is used to conduct these business processes.”2 Although there is no single, universally accepted definition of enterprise architecture, they all attempt to describe the concept of linking an organization’s information, processes, and technology to its strategy. To address how EA helps the CIO integrate multiple managerial disciplines to reach organizational goals, the previous definitions can be complemented with a higherlevel, cross-functional definition of the role of enterprise architecture: Enterprise architecture provides a foundation for effectively integrating IT governance, IT portfolio management, and organizational development. These disciplines are necessary to create and align the IT capabilities that bridge the gap between business strategy and the realization of strategic goals.

With this added dimension, it becomes important for the CIO to understand the best practices of enterprise architecture and how to approach and integrate the discipline of enterprise architecture in ways that are appropriate and achievable for the enterprise and IT organization. IT capabilities and the architecture of the enterprise determine the CIO’s ability to enable business strategy. Enterprise architecture defines IT and business capabilities required by articulating and modeling the future-state required to realize the goals of business strategy. EA is the link between strategy, technology, processes, and organization and is one of the key IT contributions to the enterprise effort to implement strategy. Best practice CIOs develop the skills to “think like an architect” when viewing the enterprise IT landscape. Like it or not, consciously designed or not, the CIO has an architecture, and the job responsibilities call for reshaping the architecture to the optimal state to achieve the strategic objectives. Leading with architecture positions the CIO to tangibly align IT through architecture’s necessary and required contributions to IT

components of enterprise architecture

51

governance and IT portfolio management processes just as it aligns the structure of the organization’s information technology and processes with the business landscape.

components of enterprise architecture The analogy of city planning is very useful to provide a ground for what enterprise architecture is and illustrate why it is important. A city plan describes the architectural constructs, policies, and standards that guide individual building initiatives and defines the standards for shared and common services such as traffic, roads and transportation, utilities, and open space. City planning provides the framework within which multiple individual projects and architectures (sub-architectures) exist. City planning further focuses its frameworks into zoning controls, which define the standards and policies for specialized types of sub-architectures such as residential, retail, or industrial uses, or different types of shared services such as electricity, utilities, and roadways. Planned communities establish standards that guide development as the first order of business. Established cities create similar standards and plans for new construction, renovation, and expansion within and beyond current city boundaries. Cities create specialized roles for city planners, establish building codes and standards for construction and services, establish procedures for obtaining building permits, and have processes for enforcing adherence to these codes and standards. The goal of city planning is to ensure that buildings and shared services will work together to meet the goals of safety, efficiency, aesthetics, and livability established by the members of the community. Enterprise architectures are created and adopted to meet analogous goals for the enterprise. The multitude of systems in an organization need to work together, share data, provide information security, scale and adapt to change and growth, reduce overall costs, and allow the organization to reach its strategic goals. Enterprises need guiding and constraining architectural designs and standards with policies and processes for approval and enforcement of these standards for individual initiatives. Enterprise architecture can be further characterized in terms of the major architectural and process tiers used to categorize broad areas of IT

52

chapter 2

integrated foundations

and business architecture. The best practice CIO establishes these tiers, equivalent to planning “zones” in the city planning example, within which to establish and document architectural standards. Within an enterprise architecture, these tiers can include both business and technical architecture constructs. CIOs may focus on some or all of four areas, and define new areas appropriate to their organizations or the enterprise architectures methodology they have adopted. The four universally accepted enterprise architecture domain tiers are business, technical information, and application (see Exhibit 2.2). Business architecture describes the enterprise’s structural, high-level business processes, service areas, and delivery channels. It defines the functional roadmap for the organization. It may describe processes like procure-to-pay, order-to-cash, and recruit-to-hire for a commercial business. In a university setting, business architecture describes processes like prospect-to-student or student-to-alumni process flows. Technical architecture describes the infrastructure and network architecture. This category includes IT security architecture, networking and

EXHIBIT

2.2

Enterprise Architecture

components of enterprise architecture

53

communications infrastructure, servers, storage, operating systems, personal computers, and other end-point devices such as PDAs and cell phones. Information architecture describes the enterprise data model, database architecture, and content and knowledge management architectures. This can also be the tier where data and application integration is defined, but they can also be treated as a separate dedicated tier. The applications tier describes the applications and application architecture required to support the requirements of the business architecture. The presentation layer, or “customer experience” architecture could be described here or treated as a distinct architectural tier. The presentation layer should integrate the user experience into a common gateway for interacting with the enterprise. This becomes especially important as e-business and e-government initiatives continue to create online, selfservice access to data and services. Approaches to Enterprise Architecture Methodology This chapter is not meant to be a detailed treatise or primer on the various EA methodologies and frameworks that exist. However, a discussion of how to approach EA methodology is warranted. The CIO can choose between many methodologies, and they all have differing approaches to the challenge of quantifying, organizing, and describing the architecture of the enterprise. Variations between methodologies include different taxonomy for describing the architectural tiers, objects used within the models, repository architectures, and the approach to the modeling and analysis task. All of the models of enterprise architecture, however, describe both functional and technical architectures. Choosing a particular methodology is an important undertaking. It is also important to bear in mind that it is not required to choose a formal EA toolset and methodology to develop and maintain an effective enterprise architecture. What is most important is choosing a consistent way to describe the architecture that is accessible and agreed upon in throughout the enterprise. The scale of the enterprise has a significant impact on the need for a formal EA methodology. Large enterprises usually have sufficient people, skills, and financial resources to invest in a formal EA methodology and toolset. The size and scale of the EA effort in the large enterprise, combined with the broad constituency base of the EA outputs, warrant this approach. There are also

54

chapter 2

integrated foundations

attempts to drive inter-enterprise EA standards within industries, such as the U.S. Federal Government, which has established the Federal Enterprise Architecture (FEA) methodology to which all federal agencies are mandated to adhere.3 For the small and medium-sized enterprise, the choice is often less clear. There are advantages to being “methodology light”, especially for the small and mid-size enterprise. The complexity and cost of full-blown EA tools and methodologies can often be significant impediments for beginning an enterprise architecture program. The use of well-known charting and illustration tools like Microsoft Visio and flowcharting and data modeling tools are often sufficient to implement a highly effective EA program while facilitating adoption and keeping costs low. However, the CIO still needs to choose an EA approach and how to structure the practice. One excellent resource for the “methodology light” approach is the IT Architecture Toolkit,4 which describes a practical and simple approach to delivering on the promise of enterprise architecture utilizing readily accessible tools and methods. Other widely used approaches to EA methodology include:5 • Zachman Framework for Enterprise Architecture6—A framework for describing enterprise architectures. It is one of the original EA frameworks and is widely adopted. • TOGAF7—The Open Group Architecture Framework is an industry standard architecture framework that can be used freely by any organization. • FEAF8—Federal Enterprise Architecture Framework, developed by The Chief Information Officers Council of the U.S. Federal Government, is an EA framework designed to be used by all federal agencies in the United States.

organizing for the enterprise architecture One of the CIO’s most significant challenges is determining how to organize the enterprise architecture practice. Does the EA practice require a dedicated staff or can non-dedicated staff lead architecture? Should the EA group be a separate organizational unit or be part of the technical and

organizing for the enterprise architecture

55

operational units of the IT organization? What are the characteristics and skill sets of the architecture practice roles, and what are the different roles across the spectrum of enterprise architecture? There are many ways to achieve the benefits of enterprise architecture and to structure the practice. Perhaps the biggest determinant guiding which form EA takes is the size of a firm and the amount of available financial and personnel resources that can be applied to the EA function. Another key criterion is the vision and the appetite that the CIO and other stakeholders have for enterprise architecture (and planning in general) and the role they accord EA in their business. Small and mid-market organizations face unique challenges when attempting to incorporate enterprise architecture. Perhaps the most fundamental challenge is how the EA function gets funded (i.e., are there enough resources to create a dedicated EA group). The CIO also needs to ascertain if the size and complexity of the enterprise actually warrant a dedicated EA group. In my experience in mid-market organizations, while a dedicated team of architects would certainly be desirable it is not actually necessary to reap the bulk of the benefits of enterprise architecture. Although compromises may need to be made in the purity of the EA practice, thoroughness of the EA artifacts, and the life cycle within which those artifacts are kept updated, the majority of the benefits of EA can still be achieved. The architecture practice and analysis is still critical in the mid-market organization, but the analysis and planning can be incorporated into the role of key, skilled people on staff, including the CIO. CIOs in these mid-market organizations may need to perform the role of chief enterprise architect, while their technical managers perform the role of domain architects over business architecture, technology, information, or applications. The hiring and cultivation of these skill sets becomes a critical success factor for bringing enterprise architecture into the mid-market organization. For example, Golden Gate University (GGU), as a mid-size organization, doesn’t enjoy sufficient resources to create dedicated architecture roles. However, the university is keenly aware of the benefits of architecture and has incorporated enterprise architecture into the IT organization’s governance and project portfolio management practices. As a result of leading IT from the architectural perspective, we focus on hiring and developing IT staff who can function as architects in their domain areas,

56

chapter 2

integrated foundations

although they may not carry the title of “architect”. My role as the CIO has included the functions normally associated with what would be called the chief enterprise architect in a larger organization. All of our IT staff members need to be either technical or managerial performers, and the best also take on architectural responsibility. In fact, to be considered an architect of a domain area becomes a source of pride and leadership, as well as a significant career development step for the individual IT professionals. As discussed later in this chapter, creating architecture responsibilities and aligning skills development with the enterprise architecture is a positive career development practice for IT staff. The breadth of skills required across all the domain areas of the enterprise architecture practice make this positive aspect true for both technical and managerial career tracks. Benefits of this approach include significant cost efficiencies by not employing dedicated architectural staff, while still realizing most of the benefits of enterprise architecture. GGU has also found that architecture stays “close to the ground” and is firmly ingrained into IT governance and the systems development life cycle (SDLC). As opposed to environments with separate architect and IT teams where there can be significant antagonism between the groups, the leaders of the GGU IT technical domains firmly believe in the importance of architecture and actually become frustrated when architectural directions are not clear enough. This approach also avoids the “ivory-tower” syndrome where the architecture practice is divorced from technical IT. As in environments with dedicated EA architects, IT organizations without dedicated architects should still organize the architecture roles around the core components of enterprise architecture: business architecture, technical architecture, information architecture, and applications architecture. This often follows the natural organizational structure of many IT departments and should make it easier and more natural to create an EA practice. The best practice CIO of the small or mid-market organization instills architecture and architectural skills as a core competency as much as possible. Without a dedicated architecture team it becomes necessary to instill the skills and discipline across people who have other duties. Make architecture skills and an understanding of the enterprise’s current- and future-state architectures a core competency in the IT organization and not only the

organizing for the enterprise architecture

57

domain of “architects”. A parallel can be drawn with the project manager role in the small and mid-size organization; the role can be difficult to staff on a full-time basis. This situation requires two tactics: (1) Develop project management skills in domain area managers so they can manage projects, and (2) Contract IT project management specialists for unusually large projects requiring specialized project management skills beyond that of internal teams or that require full-time attention for discrete periods of time. Similarly, many organizations can function quite well and reap many benefits of EA without staffing full-time architects. Domain area managers with architecture skills can provide tremendous value to an organization and keep much of the architecture responsibility moving forward. For special architectural challenges that require advanced skills for discrete periods of dedicated time, specialized EA consultants can leverage internal team skills in these situations. The internal architects maintain and advance the initial architectures created by the consultants. In this way the CIO reaps the benefits of EA, aligning IT to strategy via EA, IT governance, and IT project portfolio management without the requirement to staff full-time architects. Remember, enterprise architecture is not solely the domain of the large enterprise with a lot of resources. With a good team and an awareness of all the options, a creative CIO can accomplish similar goals in a smaller organization. Enterprise architecture accrues the same benefits to organizations large and small. However, large organizations have significantly greater complexity and have both unique challenges and opportunities when developing their enterprise architecture practices. The need to have dedicated teams, formal methodology tools, volumes of artifacts, documentation, and EA-specific processes are more significant in large organizations. Challenges are also greater in large organizations when incorporating enterprise architecture into the operating processes of the enterprise, IT governance, IT portfolio processes, and the SDLC. Many of the frustrations architects face with large organizations stem from the challenges of EA integration into IT governance processes and a lack of alignment or appropriate enforcement and decision-making authority. Best practice CIOs in large organizations pay particular attention to these areas to position enterprise architecture for success and fully reap the benefits of enterprise architecture.

58

chapter 2

integrated foundations

the value of strategically aligned architecture A sound, well-executed enterprise architecture provides significant value and benefits for the CIO and the enterprise. Enterprise architecture propagates concentric waves of information influence throughout the organization and significantly impacts IT capabilities. Through direct, bidirectional linkages to IT governance and IT project portfolio management with impacts on costs, human capital management, outsourcing opportunities, communications, and leadership, enterprise architecture is one of the most important functions for the CIO and IT today (see Exhibit 2.3). EA plays a critical role as the CIO leads the organization down the Business/IT Strategy Realization Funnel. The next sections explore some of these areas and discuss their impact for the CIO. IT Governance and Portfolio Management At the highest levels, a good enterprise architecture provides a fundamental basis for decision making as a part of the firm’s IT governance processes. Architectural requirements serve to define and prioritize the most important projects in the IT project portfolio. As the architecture defines the IT components and capabilities required to reach the organization’s strategic goals, the projects that spawn from the architecture align with business strategy and focus on building the most important capabilities to exploit the best business and technology opportunities—if IT governance is working well. Part 2 of this chapter treats this interrelationship in greater detail. Cost Reductions and Efficiencies A sound architecture helps to reduce costs by enabling systems consolidation and increasing IT investment leverage. With a common architecture, investments in standardized infrastructure can be reused across many projects and applications. Standardization helps drive cost efficiency by reducing the number of disparate platforms to support, which, in addition to reducing the numbers of vendors and contracts, provides a direct impact on the efficiency of the IT organization as the staffing model becomes more tightly aligned with the corresponding technology architecture. With a standardized architecture, the IT organization delivers a greater

the value of strategically aligned architecture

EXHIBIT

2.3

59

Architecture-Centric View of Information

Te c h n o l o g y

number of projects through its ability to leverage previous investments, reducing or eliminating the need to make core infrastructure investments for business-driven initiatives. Additionally, a strategically aligned EA creates efficiencies in IT operations and systems management, reducing costs in these expensive IT areas. Clarity regarding the contents of the IT portfolio serves to eliminate redundant assets and create visibility into software application overlicensing or under-licensing, reducing either direct costs or liabilities. Driven by the standards and policies spawned from enterprise architecture, CIOs more easily see investment overlaps in the IT project portfolio that

60

chapter 2

integrated foundations

can significantly reduce redundant IT investments, positively influencing capital budgets available for IT investments or redeployment elsewhere in the organization. The cost savings realized for both operating and capital budgets can be redeployed into higher value projects and increase the innovation capacity of the organization. Payback from Architecture Investments With a strategically aligned IT architecture in place, most of the IT project portfolio can shift to business-facing projects where there is a higher payback. The impact of IT increases for the enterprise as a direct result of pursuing a consistent architecture, and migrating away from systems and applications that do not conform whenever possible. In addition to the direct savings from systems and IT portfolio consolidation and IT staffing model alignment, a significant part of the payback from architecture investments generally comes from the reduced cost of subsequent businessfacing projects. To keep the architecture investments justified, the best practice CIO explicitly quantifies and communicates the benefits of the architecture investments and ties those investments back to current and future project proposals and cost savings, which leverage the architecture. This communications practice keeps the value of architecture visible and relevant while continuously demonstrating the value that IT brings to the organization. IT Strategic Sourcing Increasingly, organizations look to outsourced services to fulfill their IT mission. A solid architecture is an important component of successful outsourcing. Systems and process environments that look like a plate of spaghetti are very difficult to outsource cost-effectively. A good architecture facilitates outsourcing via clear system and service boundaries, resulting in an enhanced ability to multi-source across a variety of outsourcing vendors while maintaining project and architectural control in-house. A solid architecture becomes even more critical as outsourcing influences a loss of “institutional-memory”, and a short-term, profit-motivated, project-level focus on the part of the outsourcers delivering the projects. Outsourcing by its nature causes a shift of systems knowledge away from internal staff to the

the value of strategically aligned architecture

61

services provider. Without the blueprint of a solid architecture, an organization runs the risk of losing control of the enterprise view on IT and experiencing corresponding difficulties coordinating the disparate efforts of multiple service providers. Additionally, the short-term, project-level focus of most service providers further exacerbates this problem. It is not in their short-term interest to explore all the enterprise ramifications of systems development or change, but instead rely on the client to provide this control and oversight. A solid enterprise architecture becomes a requirement for organizations wishing to leverage outsourcing, especially given the trend toward multi-vendor outsourcing, which requires greater clarity in servicelevel boundaries, delivery hand-off points, and enterprise-wide coordination. See Chapter 7 for more outsourcing considerations. Business Agility and Innovation Capacity A sound architecture simplifies the IT organization, increases its flexibility, and allows the same number of people to deliver more IT services and capability. Higher levels of IT delivery throughput and an architecture that provides leverage to subsequent investments lead to greater IT agility and flexibility. See Chapter 3 for an in-depth treatment on how to achieve an agile IT organization. Another way to look at the value of a sound EA is through its influence on “innovation capacity”, which refers to the capacity of IT to create new value for the enterprise in the form of new opportunities, products, and services. As IT succeeds in reducing the amount of time and money spent on IT operations, the redeployment of both human and financial IT assets to innovation creates new value for the enterprise. A demonstrable example of the power of enterprise architecture, combined with IT portfolio and project management processes, comes from Golden Gate University where IT enabled an e-business transformation of the university, taking it from a static, offline model to a dynamic, Webenabled, data-driven, online model. At the beginning of the transformation, many new significant IT and business capabilities were determined as requirements for carrying out the rapidly evolving business and educational mission. We spent many months up front, before starting a lot of new projects, defining our architectural approach and looking at key business

62

chapter 2

integrated foundations

process areas that would be affected and need to evolve to meet the goals of the e-business model. We assessed our current-state and planned and designed our future-state of technology, information, and business architectures in the initial key areas that would be affected first. Along with architectural design and planning, we also worked hard within the IT organization to implement an IT portfolio and project management practices for the first time. The eventual result was an estimated ten-fold increase in the number of information technology projects the university could realize in a given time frame when compared to the same time frame prior to the architectural upgrade. And the trend to greater speed has continued as the university continually leverages previously constructed architectural components to deliver new projects faster and less expensively. Three years after beginning the EA initiative, the university has fundamentally reengineered departmental and customer-facing processes and technologies in time frame order of magnitude faster than in the past. From the CIO’s perspective, IT applications projects now feel almost easy. The EA investments built prior leverages current initiatives, and little to no infrastructure needs to be created. This new ability to predictably and repeatedly deliver significantly greater numbers of new initiatives has meaningfully increased the business agility of the university and its ability to adapt to changing conditions in the higher education marketplace. Communications and Transparency Communications is a critical component of every CIO’s success. It is necessary for the CIO to describe the roadmap ahead for IT and how IT will enable their business strategy. The written goals, documents, diagrams, plans, and standards and policies of enterprise architecture are strong written and visual communication tools for the road ahead. These EA tools sell the vision to senior management and other stakeholders and manage expectations regarding IT investments. As an ongoing process that requires repetition and updating if learning and change are to be affected, use the tools of enterprise architecture in communications by posting them on your intranet and keep the architecture and roadmap visible to the IT organization’s constituency to illuminate the road ahead and lead with your strategically aligned enterprise architecture.

it governance and portfolio management

63

IT Organizational and Human Capital Development One of most powerful outcomes of a solid enterprise architecture is its positive impact on the development of the IT organization and the individual IT professionals. Because enterprise architecture defines the future-state of information technology in the organization, it creates a set of goals for both the IT organization and its individual staff members to target. Required organizational capability, individual skills, and career development plans become much more clear, and gaps between existing skills capabilities and required skills capabilities in the future become apparent. This clarity and visibility into future skills and staffing requirements give the CIO, the IT organization, and other areas of the enterprise, the roadmap for skills and career development, hiring plans, and strategic sourcing decisions. The future-states of the architecture clarify which functions are more commodity-like (becoming candidates for outsourcing) and which functions are more strategic and warrant inhouse development of skills and talent. Given that skills development and acquisition and staff retention are long-term challenges, the visibility provided by a clear enterprise architecture becomes invaluable. Part 3 of this chapter takes a deeper look at how the CIO can work to align career development planning within the IT organization with enterprise architecture.

part 2 it governance and portfolio management—the processes that link ea to the realization of business strategy As mentioned at the start of this chapter, there is no single construct or technique that enables the CIO to align IT to the business and facilitate the realization of strategic objectives. An enterprise architectural plan is only the beginning of realizing the business goals. Although enterprise architecture defines what IT capabilities are required to reach strategic goals, architecture by itself is not enough to bring about the required changes and organizational behaviors that result in the desired outcomes from IT investments. Many of the significant struggles that enterprises face in realizing the

64

chapter 2

integrated foundations

goals described by their enterprise architectures are born from the challenge to effectively link architectural goals to the specific projects that create the IT capabilities being sought. The CIO has a difficult, if not impossible, time working to realize the goals specified by the enterprise architecture without supportive, interrelated processes and disciplines working in concert. The CIO needs an approach and set of procedural disciplines to link the outcomes of enterprise architecture to the realization of business strategy on a consistent and ongoing basis. Enterprise architecture has a direct, dependent, and synergistic relationship to two other core disciplines of the successful CIO: (1) IT governance and IT portfolio management, and (2) organizational development (the development of human capital). The stewardship of the CIO leads the IT organization through these processes so that the enterprise can realize its business objectives. The Challenges of Linking Architecture to Outcomes Symptoms of an enterprise architecture that is poorly aligned to the organization are many. (1) Architectural plans are created, but IT projects are implemented without adhering to the architecture. (2) Architecture is not integrated into the IT governance decision-making processes, thereby allowing projects to get approved without complying with the architectural guidelines or standards. (3) Architecture becomes political in one of two ways. First, different parties fail to adapt to the architectural guidelines, creating resistance and a lack of consistent compliance. Second, architecture becomes a political bottleneck to approving projects, unnecessarily slowing down project life cycles, which results in people trying to figure out ways around the architecture process. (4) Investments in enterprise architecture are seen as providing insufficient or nebulous payback and fail to get approved. (5) Architecture efforts are not tied to the business initiatives born from business strategy and are interpreted as unaligned, ivory-tower, or impediments to rapid execution of individual projects. The symptoms just listed are neither exhaustive nor uncommon. Dysfunctional symptoms like these result from improper relationships and alignment between architecture and the processes of IT governance and portfolio management. Best practice CIOs effectively reach enterprise

tying it all together—linking ea to it governance

65

strategic goals by correctly aligning these processes into a complementary synergy.

tying it all together—linking ea to it governance and portfolio management IT governance and project portfolio management constitute the glue—the procedural linkages—required to marry the enterprise architecture function into IT decision making, program and project management, and budgeting. The topics of IT governance and portfolio management are broad and have a number of definitions and interpretations. The seminal book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, defines IT governance as “Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.”9 The authors further break down the concept of IT governance as defining “mechanisms formalizing the relationships and providing rules and operating procedures to ensure that objectives are met.”10 This distinction begins to illustrate the direct link and dependency between effective IT governance and effective architecture. In other words, without a governance mechanism to establish rules and operating procedures it becomes difficult or impossible to enforce architectural standards. Another definition of IT governance further aligns the conceptual link between strategy and the requirement to control the implementation of IT strategy, hence, architecture: “IT governance is the organizational capacity exercised by the board, executive management, and IT management to control the formulation and implementation of IT strategy and in this way ensure the fusion of business and IT.”11 Comprising a subset of the practices of corporate governance, the topic of IT governance is very broad. This discussion focuses on IT governance processes that enable the CIO to tangibly align IT decision making with enterprise architecture and how the CIO manages the process of decision making to specifically realize the goals of the enterprise architecture. The best practice CIO establishes a process for architectural governance that clearly positions architectural decision-making authority while also providing a process for managing exceptions. There are essential elements of this process for the CIO to consider.

66

chapter 2

integrated foundations

The CIO’s role is to gain senior leadership support for architecture. If architecture is going to become a critical forum for deciding which IT investments gain approval and to what architectural standards those investments are constructed to and constrained by, then it is mandatory for all leaders involved in the IT decision-making process to understand the value of a correct and strategically aligned architecture and the role of architecture in IT investments. Without this common understanding among key IT investment decision makers, the best practice CIO starts with education and communication regarding the value of the architectural approach to IT. Buy-in is critical because IT investment proposals need to be vetted against architectural standards and approved, rejected, or sent back for rework. Without senior leadership understanding of the important role of architecture in achieving business goals, the CIO continually fights a series of difficult battles in the process to lead IT decision making to achieve desired outcomes. Best practice CIOs incorporate architectural review into the IT investment evaluation process. An effective strategy to facilitate this is to create an architectural review board, which is responsible for leading the creation and governance processes for architecture and vetting project proposals for compliance to, and advancement of, the enterprise architecture. Even in small and mid-sized organizations that may not warrant a formal “architecture board”, the CIO should establish the key architectural leaders and loop them into this process. Project proposal documentation should be upgraded to include an architectural assessment for fit and compliance to internal standards. Only in a perfect world would every project conform to an organization’s architectural standards. One of the most important elements of architectural governance is a process for managing exceptions. The business inevitably encounters requirements that are best met by a solution that is not architecturally conformant, and architectural standards have to compromise. The most common exception-management process escalates through the managerial ranks. Each enterprise should design an architecture exception-management process to standardize the dispute resolution process. For example, if the project requestors and the architectural reviewers cannot agree, the issue escalates to the CIO. If there is still an impasse after CIO-level mitigation, the issue escalates higher to the next level of the official sequence, all the way to the CEO in some enterprises. Obviously, for reasonable architecture disputes to escalate above the CIO

tying it all together—linking ea to it governance

67

there must be a strong and common knowledge about the role and importance of enterprise architecture among the senior managers. When an architecture exception-management process includes the CEO as the final arbiter, it underscores the importance of enterprise-level architecture and it makes the business (not just IT) accountable for the decisions that affect IT outcomes. For additional discussion on managing exceptions see Weill, et.al.12 and the IT Architecture Toolkit.13 An area prone to challenges with architectural standards is the specialized, vertical-market application, which is clearly the best fit with a critical operating area of the business but does not fit the architectural standards. When looking at all the trade-offs in situations like this, the compromise that best benefits the business relaxes architectural standards for a critical functional area. Ways to mitigate the impact associated with these difficult, sometimes costly compromise decisions include the development of an integration architecture to minimize the isolation of non–standardscompliant applications. The on-demand model for software-as-a-service (SaaS) is another area that has become a real-world option to help CIOs mitigate the impact of non-compliant applications. Applications delivered over the Internet as a service offering greatly reduce the impact on internal application architecture standards as the service provider manages the application and its related technology stack. Organizations can take advantage of application services that they would have a difficult time coping with if hosted internally. The challenge of information and data integration remains, and standards for application and data interoperability are evolving rapidly and continue to help mitigate this challenge. IT Portfolio Management Project portfolio management is where the actual implementation of enterprise architecture initiatives gets managed. The management process and toolset ties enterprise architecture to the outcomes of effective governance. Portfolio assessment, balance, project prioritization, and timing decisions processes are critical factors in successfully realizing the goals of the enterprise architecture. In the book, IT Portfolio Management Step-byStep: Unlocking the Business Value of Technology, Maizlish and Handler outline eight essential stages to properly managing the IT portfolio.14 The eight stages define the critical stage of balancing the portfolio against strategic objectives and other operating parameters. The portfolio must be

68

chapter 2

integrated foundations

the manifestation of the projects required to strategically align enterprise architecture investments to the requirements of the organization. It is a critical process step to correctly align architectural investment with strategic objectives, and the best practice CIO ensures that portfolio balancing occurs to properly balance architecture investments with tactical projects. As in a financial portfolio where investments are balanced to specified levels of risk and reward and investments are grouped into specific sectors and asset allocations, the IT investment portfolio must balance immediate investments, such as critical business-facing projects and new application or e-business implementations, with long-term enabling investments in enterprise architecture and core infrastructure. Both long-term and short-term needs and outcomes need to be balanced if the enterprise is to obtain longterm benefits and payback from IT. It is through this balanced approach that the CIO establishes and maintains strategic IT momentum with regards to the correct architectural future-state required to meet business objectives. An effective approach for the CIO to incorporate architecture investments into the IT portfolio is to align them with business initiatives whenever possible. This means tying architecture to current or upcoming business-facing projects expected to provide a business payback. It is important to establish deliverable value from architecture, which this close alignment facilitates. The business projects are highly leveraged by the common architecture and delivered more quickly once begun, and this is a key lever that demonstrates the value of architecture investment. Avoid trying to make architecture work as a stand-alone practice with projects that are not specifically tied to actual business-driven deliverables. This is one of the reasons many architecture efforts do not get off the ground— they are not aligned with specific investments and become viewed as abstract exercises. Best practice CIOs learn to see far enough into the future of IT requirements to anticipate these long-term needs and get the architectural work underway with sufficient lead-time to be in place when the business initiatives hit. This requires CIOs to be architectural planners—to think like architects and make every attempt to avoid a reaction mode when project requests come into their queues.

integrated processes Starting from business strategy, the best practice CIO steers the organization through the process of defining current-state and future-state architectures,

integrated processes

69

identifying the gap between them, and managing investment decisions through IT governance and portfolio management disciplines to achieve the desired outcomes. From the architecture-centric view, think of the relationship between IT governance, portfolio management, and enterprise architecture as the relationship between the concepts of what (technology) and how (processes). Enterprise architecture represents the what from an information technology standpoint, and it defines what IT and process capabilities the organization needs to realize its goals. (see Exhibit 2.4).

EXHIBIT

Architecture

2.4

Integrating Processes that Reinforce

70

chapter 2

integrated foundations

IT governance and portfolio management represent how IT works in terms of the processes that enable architectural goals to actually be achieved. Architecture is the blueprint, IT project portfolio management stewards the collection of IT investments that build the blueprint, IT governance ensures that people make the right decisions to correctly populate the portfolio, and the approval process inherently includes a review of architectural correctness and adherence. Without enterprise architecture, IT governance and portfolio management can result in projects with little or no strategic integration. Enterprise architecture defines the criteria for the IT governance decisions. Additionally, enterprise architecture defines a large part of appropriate content for the IT project portfolio. At the same time, the enterprise cannot realize architectural goals without circular feedback loops that link back through decision making and IT portfolio management. Architecture, IT governance, and portfolio management constitute a cyclic dynamic, not a linear process, one-time event, or static plan. Not one of these practice disciplines can result in achievable designs or informed decision making in isolation. It is precisely the outcome of this process that the CIO must focus upon. The CIO attains a strategically aligned architecture via an effective IT governance process and an IT project portfolio that balances investments in enterprise architecture with other business-specific IT investments.

part 3 aligning ea and organizational development for strategy realization Organizational competencies are rapidly becoming increasingly important elements of competitive advantage as Wall Street learns the intangible value of information technology, integrated supply chains, and intellectual capital. The rise to prominence of chief learning officer and chief knowledge officer positions, the incorporation of e-learning and knowledge management into the enterprise, Six Sigma, and a host of other learning, knowledge, and process-focused initiatives and technologies validates and accelerates the importance of this trend (for more on managing intangible IT value, see Part 2 of Chapter 8). Technology-driven organizations have a constant need to develop skills

aligning ea and organizational development

71

and understand which skills and competencies will be needed in the future. Because competency development is a long-term initiative, it becomes increasingly important to be able to forecast and predict what competencies will be most important in the future. Enterprise architecture has an important contribution to make to the development of organizational competencies and the continued importance of the CIO role. We have already seen that enterprise architecture specifically plans the future-state of enterprise information and technology architectures and helps bridge the gap from the current-state. The blueprints created by EA provide a critical bridge between enterprise strategy and the technologies, information, and processes required to enable the strategy. These EA blueprints and plans also provide important inputs to the process of designing required future-states for competencies of the enterprise’s managers and workforce. The future vision enabled by enterprise architecture gives CIOs developmental roadmaps at both the individual and organizational levels. For the individual IT staff member, the EA future-state models for business architecture, information, and technology provide a clear path for aligning career and educational development plans. Career paths become more tangible when charting one’s future within an organization, as does personal commitment. Individuals can see where they are going professionally and learn to focus their growth and personal development. The ability for an individual to assess one’s own current-state skills and competencies to map professional development into the future becomes a very powerful planning and staff retention tool. In my experiences with direct career development planning with more than 100 IT colleagues, the ability for an IT professional to tangibly visualize and plan one’s career development and navigate within the enterprise is one of the most important motivators and retention tools at the CIO’s disposal. Succession planning is facilitated as individuals conscientiously address future professional growth, professional transitions, and the information they need to successfully plan the successions. The basis for understanding future required competencies and mapping those back into individualized career development plans can be principally enabled by the outputs of enterprise architecture and IT strategic planning. For the IT organization, enterprise architecture provides critical inputs for development planning. A future-state enterprise architecture vision

72

chapter 2

integrated foundations

requires new competencies in the business. Managers need to know what skills to recruit for, what types of learning and knowledge management programs to implement, and how to organize and architect the organization to become more competitive. The ability to innovate faster than the competition and ingrain this innovation throughout the workforce are increasingly critical competitive differentiators. EA provides the roadmaps for organizational, information, and technology future-states that facilitate organizational development (see Exhibit 2.5). Human resource requirements planning and development is a key factor in the linkage between enterprise architecture and organizational development. A firm needs to understand its demand curve for skills and competencies based on an understanding of its architectural and IT portfolio requirements. It then becomes possible to accurately source for skills and services in the marketplace. Project labor utilization rates are a key indicator

2.5 The Enterprise Architecture and Organizational Development Vir tuous Circle EXHIBIT

an architecture-led e-business and it transformation

73

of efficiency and project profitability. As such, the ability to identify current and future need is an opportunity to directly manage costs and project output. EA blueprints combined with IT portfolio schedules are a direct link for identifying and forecasting skills and competencies throughout the organization. The CIO can only deliver through the people of the IT organization. The best architectural designs and the most expertly crafted IT governance and portfolio management processes won’t make much contribution without execution, execution happens through people, and people execute through their skills and competencies. The best practice CIO encourages and fosters the contributions that a sound enterprise architecture program can make to the development of both individual staff members and the intellectual capital of the organization.

an architecture-led e-business and it transformation case study There is really no better way to tie together the implementation of the many practice principles discussed in this chapter than to describe the challenges and successes of an actual case study. In 2001 Golden Gate University (GGU), facing new competition in the face of revenue and profitability pressures, brought in a new senior management team to perform a turnaround to reposition the university in a new competitive marketplace for adult professional education. The new management team led significant change across academics, operations, technology, and financial capitalization. The turnaround plan called for a renewed focus on technology and a goal of ubiquitous 24/7 access to all information, transaction, and learning via a Web browser. From the standpoint of information technology, GGU was behind the technology curve with aging legacy systems, no IT architecture, static Web sites, and poor integration. The IT organization was configured in silos with little cooperation, and skills were not well aligned with modern technologies. The turnaround plan created pressures to deliver a new business strategy, create a new customer experience, and reduce costs of delivery throughout the enterprise. Essentially, the university articulated an e-business transformation, which required a complete overhaul of IT infrastructure, online applications, and educational offerings, an improved IT services delivery model, and new skills and organizational competencies

74

chapter 2

integrated foundations

throughout the university. A key constraint was that IT operating costs could not increase. In other words, we needed to transform IT but could not make it more expensive to run IT. GGU’s IT turnaround followed the approach illustrated by the Business/IT Strategy Realization Funnel. Beginning with the goals of an articulated business strategy, our fundamental approach led with enterprise architecture as the cornerstone of the effort. We anchored our effort around the concept of the architecture-centric view on IT and drove the development of processes, standards, IT governance, portfolio management, and organizational development from that basis. GGU focused on the alignment of the architecture with the stated business goals. We created a current-state view on the technology and a future-state model needed to realize the e-business vision. The gaps between the current-state and future-state architectures and the requirement to bring down IT costs were the drivers for all of the large IT investments and the balance of the project portfolio (see Chapters 4 and 6 for how such drivers can be incorporated into the enterprise financial systems). Over the subsequent five years, the university systematically executed on its e-business and architectural transformation. Among other things, the efforts have resulted in a new IT technical and security infrastructure overhauled from the bottom up, an enterprise-wide database architecture, a Java Web-application tier, new ERP and CRM applications, and a common customer experience for all online applications, which consolidated 29 unique and nonintegrated online experiences down to one. All business transactions moved to the Web, eliminating the need to come to the campus, and online learning moved up dramatically as a percentage of revenue. Innovation capacity greatly improved as IT costs moved from a ratio of 90%/10% maintenance/innovation to approximately 60%/40%. The combination of a common architecture and project management and portfolio methods increased project capacity by a factor of 10 when compared to previous time frames. The IT organization was reorganized, major business process re-engineering efforts overhauled much of operations, and significant investments were made to support organization development from investments in skills training to management and leadership programs. The university was awarded the CIO 100 award in 2004 for its success in creating agility and transformation through IT and the Infoworld 100 in 2003 for innovation in its e-business initiatives.

an architecture-led e-business and it transformation

75

Senior Management Understanding and Commitment to Architecture Plainly stated, without the consistent commitment and IT governance leadership by the senior leadership team of the university, we would not have been successful in our approach to lead with architecture. Leading with architecture represents a disciplined approach to IT investments, and many influences conspire to knock the uncommitted CIO off the path. The roles of the university COO/CFO and president were critical to set the cultural and procedural standards regarding the central role of enterprise architecture. They believed in the benefits of enterprise architecture and were committed to drive the cultural changes and disciplined decision making to support clear IT governance and architectural leadership. A statement the GGU president made at the beginning of a multi-year series of project investments in a new ERP infrastructure illustrates the importance of the senior leadership commitment. One of our challenges was to re-engineer business processes to break down departmental silos and realign processes horizontally across the enterprise. When the departmental managers were debating if the applications should conform and be customized to meet their business processes or if the university should adopt many of the best practices reflected in the new applications designs, the president addressed the group on behalf of the new enterprise architecture’s role. “The uniqueness of our business processes is not what creates value for the university. In fact, the uniqueness of our business processes represents an Achilles heel. The value of the university comes from uniqueness and distinction in our teaching and learning practices.” He further added that GGU’s biggest hurdle was cultural, getting everyone to believe that the uniqueness of isolated business processes was not where the value resided. With that one statement he set the expectations: it was not going to be business as usual and not everyone was going to get their way. He set the expectation that processes were going to change to meet the new goals of the university and that the enterprise architecture was going to be more important than the parochial desires of individual departments. IT governance is a series of trade-off decisions. Not everyone is going to be happy with the decisions, or even the process. It is critical that the most senior levels of leadership set the tone and expectations for how IT is

76

chapter 2

integrated foundations

to be governed. The CIO, as the senior management team’s IT leader, is uniquely responsible for obtaining this alignment and support. The CIO can leverage the concept of the IT/Business Strategy Realization Funnel to put all the practices of EA, IT governance, portfolio management, and organizational development process alignment into context to gain enterprise-wide commitment to support these disciplines. Pursue Architectural Transformation Incrementally The ability to clearly map business objectives into the architectural futurestate was essential in aligning people to the approach. This was done with a high-level view on the future-state enterprise architecture and a roadmap showing how the current-state architecture would migrate into the new. The articulation of this plan was possible at a high level without producing detailed architectural designs into specific processes or technologies. The organization was not capable of producing low-level architectural models at that early stage, yet the architectural direction needed to be established and approved if we were to move ahead. The lesson is that it is important to have an early high-level vision of where the architecture needs to go, but the lower-level and detailed modeling of that architecture should take place over time, driven by business-facing initiatives. Once the high-level architectural direction was set, we were able to define the projects that would enable the future-state. We realized the future-state architecture by aligning those architectural investments with the projects that would provide business payback. We did not pursue architectural initiatives in the abstract. The pursuit of the business-facing projects is what allowed us to pursue lower-level designs and architectural investment in those areas. Another example of the approach to align architecture investment incrementally with specific, business-value investment areas is General Motors. Former GM CTO Tony Scott, another CIO 100 award-winner, said when discussing GM’s approach to EA, “In fact, we’re not going to try to map all of GM; we’re going to do it in bite-size chunks. In all the architecture projects we’ve done so far, we’ve never gone top-to-bottom, left-to-right and mapped every piece of information at every level of detail. We’ve focused on those areas that we thought provided the highest

an architecture-led e-business and it transformation

77

value to GM.”15 Scott pursued the approach of aligning architecture work to business requirements analysis for current or near-term projects and pursued architectural advancement incrementally. Best practice CIOs align their EA with the important revenue or cost and efficiency drivers because they want senior managers to work as EA champions and have it accepted by the business project owners. For this reason, GGU aligned all architecture projects to business initiatives as defined by deriving the elements of EA from the university’s strategy and stated goals. Portfolio and Business Alignment GGU adopted a portfolio management approach for managing all IT investments. Our maxim is that if it is not approved and in the portfolio, then we are not working on it. The portfolio approach has been instrumental in our ability to align IT investments with stated strategy and unitlevel goals and objectives. The steps to reach the desired architecture, which reflects the important business initiatives, drove the contents of the project portfolio. GGU leadership took it a step further by quantifying university business strategy into eight key areas. We then inventoried all business-unit–specific goals and objectives, including IT, and linked every project in the portfolio with a specific element of strategy or approved business unit goal. If we could not match a project request to either a specific strategy or a business-unit goal, we did not do the project. The result was a portfolio of IT investments that everyone in the university supported, both administration and academic organizations. This was a noteworthy milestone because broad alignment is often very difficult to achieve in higher education settings, and transparency via the IT portfolio was a key instrument. Organizational Development GGU wisely took a focus on organizational development aligned around required organizational competencies. Within IT, we specifically mapped individuals’ career development plans to the requirements of the futurestate architecture. As a result, we found that people became energized, goal-oriented, and self-starting about their next career development step.

78

chapter 2

integrated foundations

Business departments aligned their organizational development efforts around their new processes, skills requirements, and ways of doing business. Management and leadership at every level must have a commitment to organizational development, but they also need a tangible guiding force like enterprise architecture to show the organization where it is heading with regards to processes, technologies, and the requisite skills and competencies. IT Governance A clear architecture improves decision making for the CIO and other people in the enterprise by providing a set of standards and quantifiable directions against which to base decisions. In a classic example from GGU, one department had selected an application they wanted to procure that was totally non-compliant with our architectural standards, and as a result, fell outside the skill set of the IT department to implement or manage. The department intensely lobbied for acceptance of the application, and the effort involved many of the university’s senior managers. The vendor offered application-hosting services, thereby reducing much of the architectural compliance impact. But after due diligence investigations we found that the vendor was very new to hosting and had no track record. Because the vendor was a small company we felt the risk was too great should it prove inadequate as a hosting provider. The IT organization was not equipped to take the application in-house if circumstances required us to do so. The GGU governance process supported IT in making the unpopular decision not to pursue the project, despite the expressed disappointment of the sponsoring department. We made a good decision. We eventually found a better, architecturally compliant solution and avoided a potential mission-critical liability. The take-home lesson is to stick to a disciplined approach to architectural standards. Be careful about making exceptions, and don’t make them when other options exist. When making exceptions, make sure they are for the right reasons, and make sure the business understands the trade-offs, risks, and future cost impacts. Communications and Alignment Enterprise architecture and an IT project portfolio are powerful tools for facilitating communications and enterprise alignment. Both disciplines

chapter checklist

79

provide the stage for clear prioritization and transparency of IT investments. This benefit became especially important for GGU where a large part of the enterprise focuses on academic goals and outcomes rather the business goals of the administration. Enterprise alignment challenges are notoriously difficult in higher educations environments. Our IT project portfolio and IT governance process were critical in achieving transparency regarding the focus of IT investments and how those investments supported the stated goals and strategies of the university. The work we did to align the IT function to the academic side of the university is a good example of this EA benefit. We created an informal IT group under the leadership of the vice-president of academic affairs, focused on academic leadership and the libraries. The work of this group was key in fostering the academic/business alignment with information technology. The group spent a lot of time reviewing the portfolio on a regular basis, educating everyone about the strategic rationale behind GGU’s IT investments. Additionally, the group brought academic leadership fully into the IT governance processes for proposing and obtaining approval on IT projects, alleviating the perceptions that the academic side was left out of the processes. In time, it enabled a productive dialog and process about how IT could add the best value for the academic component of GGU’s mission. Additionally, the academic side developed an understanding about what was required for creating and implementing joint IT and academic projects and their delivery responsibilities.

chapter checklist Use this list to rate the effectiveness of your own enterprise architecture, IT governance and project portfolio management, and IT organizational development practices: ❐ It is the goal of every good CIO to align IT strategy to business strategy. ❐ CIOs must optimize the interrelationships and integrate four of their most important tools—enterprise architecture, IT governance, project portfolio management, and IT organizational development—to align and execute the IT contribution to the realization of business strategy and bridge the gap between business strategy and the information and technology structure of the organization.

80

chapter 2

integrated foundations

❐ These tools and techniques revolve around three long-standing core concepts well known in the systems development disciplines—people (IT organization development), process (IT governance and portfolio management), and technology (enterprise architecture) have stood the test of time as the primary and necessary components of successful solutions. As technology has become more ubiquitous and as technologies continue to commoditize, emphasis has evolved toward the capabilities of people and processes as the focal areas to glean return on investment and competitive advantage from IT investments. Enterprise architecture enables people and process capabilities and aligns them with strategy. ❐ The practice of enterprise architecture formalizes the direct link between technology, information, and processes and the IT capabilities required to meet business strategy. Enterprise architecture should be the information and technology manifestation of your enterprise business strategies. ❐ Bringing the focus on people, process, and technology up from the systems and project level and applying it to the enterprise achievement of IT and business alignment provides a focal point for CIOs in their quest to achieve the challenging alignment mission and the realization of business strategy. ❐ Enterprise architecture defines the IT and business capabilities required by articulating and modeling the future-state required to realize the goals of business strategy. It is the link between strategy, technology, processes, and organization. ❐ There are a number of EA methodologies, which the CIO can adopt, and they all have differing approaches to the challenge of quantifying and describing the architecture of the enterprise. All of the models of enterprise architecture, however, describe both functional and technical architectures. Choose your methodology carefully and remember that it is not necessary to choose a formal EA toolset and methodology to develop and maintain an effective enterprise architecture. Choose a consistent way to describe your architecture that is accessible and amenable to your enterprise culture. ❐ Enterprise architecture has a direct and synergistic relationship to three other core disciplines of the successful CIO: IT governance, IT portfolio management, and IT organizational development. Manage them all proactively and in unison with one another.

notes

81

■ notes 1. Federal Government, Chief Information Officers Council, www.cio.gov/ documents/FINAL_White_Paper_on_EA_v62.doc. 2. See note 1 above. 3. Official White House e-government Web site: www.whitehouse.gov/omb/ egov/. 4. Jane A. Carbone, IT Architecture Toolkit, (Harris Kern’s Enterprise Computing Institute: Prentice Hall, 2004). 5. For an overview of the 14 most popular EA frameworks and a discussion of how to select one see Jaap Schekkerman, How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework, (Oxford: Trafford Publishers, 2003). 6. The Zachman Institute for Framework Advancement, www.zifa.com. 7. The Open Group, www.opengroup.org. 8. See note 3 above. 9. Peter Weill and Jeanne W. Ross, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, (Boston: Harvard Business School Publishing, 2004). 10. See note 9 above, page 10. 11. See note 9 above, page 242. (Note 14). 12. See note 9 above, pages 99, 113-114, 156, 225-226. 13. See note 4 above, page 150. 14. Bryan Maizlish and Robert Handler, IT Portfolio Management Step-by-Step: Unlocking the Business Value of Technology, (Hoboken: John Wiley and Sons, 2004) 175. 15. Tony Scott, CTO of GM’s Information Systems and Services Group, CIO.com interview, August 15, 2004, www.cio.com/archive/081504/scott.html.

chapter

3

A Strategically Focused, Tactically Agile IT Organization by michael hugos

hapter 1 opened this book with a discussion of the CIO’s two primary C responsibilities: (1) to ensure the stable and reliable functioning of the enterprise’s IT infrastructure—meaning all the application systems and all the hardware and software on which those systems depend; and (2) to continually evolve and enhance the IT infrastructure so that it remains properly aligned with the enterprise’s evolving business needs. These responsibilities ensure that the enterprise has the IT capabilities it needs to carry out its business strategy and to respond effectively to threats and opportunities as they arise. This chapter builds on these foundations to address IT tactical agility. In the high-change, high-risk, and highly competitive global economy in which enterprises compete today, CIOs can make their most valuable contributions by evolving and enhancing the IT infrastructure so that it stays aligned with business strategy. This is where CIOs must devote the bulk of their attention and their time. Although the CIO still remains responsible for the reliable day-to-day functioning of the IT infrastructure, that responsibility is not a “C”-level job anymore. CIOs must delegate IT operations to direct reports and partner with service providers to whom they can outsource selected IT operations. It is no longer about the technology itself; it is about how well the CIO uses it. It is no longer about squeezing more efficiency from internal IT 83

84

chapter 3

a strategically focused it organization

operations; it is about how well the CIO responds to external opportunities. Running an efficient and cost-effective IT organization has fallen off the list of the CIO’s high-value strategic contributions because so many enterprises have learned to perform them as basic disciplines. Senior management simply expects this kind of baseline performance from the CIO. Enterprises have used IT to increase internal efficiencies within their organizations over the past decade. CIOs and their IT organizations have learned to become much more cost effective in the way they run their operations. IT alignment with the enterprise is the new focus where the CIO can add the most value. With the rates of change in most enterprises, IT alignment work has become a full-time job in a way that was not the case even 10 years ago. Today enterprises live in a high-change world where advantage goes to the most agile enterprises, not just the most efficient ones. The conditions for operational efficiency keep changing and enterprises must learn to adapt and keep up with their markets. Just doing the same old things the organization has always done more efficiently brings less and less return when customers lose interest in those things.

agility is a process Enterprises need to be agile to keep up with their markets, and IT organizations must be agile to stay aligned with their enterprises. As enterprise strategy evolves over time, the CIO must constantly assess strategic changes and their impact on the IT organization. Does the existing infrastructure support the new business strategies? What new capabilities are needed? How can existing systems best be leveraged, and what new systems are needed? Let’s start by defining a tactically agile IT organization as one that senses and responds to environmental change efficiently and effectively. The two operative concepts here are “senses and responds” and “efficiently and effectively.” In other words, IT organizations must (1) constantly collect and analyze information to detect change and (2) respond appropriately when changes are detected. Agility is an ongoing process, not just an occasional event. An agile IT organization is not an athlete one day and then a couch potato the next day. An IT organization cannot be agile unless all its members are agile, so agile work principles need to be understood and practiced by everyone.

agility is a process

85

The diagram in Exhibit 3.1 outlines the process flow that creates agility throughout the IT organization. Note that agility is composed of three sub-processes or activity loops that all run concurrently. Loop 1 encompasses environmental monitoring and responsive decision making. The people in this process are responsible for making the decisions that deliver successful IT alignment with the business. This is where CIOs focus most of their time because this is where they deliver the most value to their enterprises. The focus of the environmental monitoring and decision-making process must be to identify, analyze, and respond to the “nonstandard inputs” as shown in Exhibit 3.1. This is because the most profitable opportunities for better alignment of IT and business often arise from agile responses to new or unexpected events (nonstandard inputs). The CIO

EXHIBIT

3.1

Agility Loops

86

chapter 3

a strategically focused it organization

needs to know when transaction processing volumes increase or decrease at unexpected rates and when system processing or operating errors occur at greater than expected rates. These events usually signify a need to improve an existing IT operation. The CIO also needs to know when new competitors enter the market and when sales of certain products increase or decrease faster than expected. Events like these often signify a need to create a new system or work process. For example, consider the response you would make to the unexpected news that sales of your enterprise’s new product X were increasing much faster than had been anticipated and also that customers who bought product X were two-thirds more likely to then purchase product Y within the following 60 days. The way you as the CIO respond to this unexpected news and the speed with which you deliver needed IT support will be a determining factor in how much success your enterprise can achieve. The CIO needs to consider the IT components that support product X and determine how to scale them up faster than originally planned to handle the extra sales volume. Then decide what new IT support can enable the enterprise to best exploit the emerging opportunity for sales of product Y and how soon that support should be in place. In responding to this unexpected news you as the CIO might decide to launch two projects. One project would accelerate the build-out of processing capacity for the systems that support product X. The other project would develop new systems to address the emerging opportunity for product Y and other follow-on product sales. The IT organization’s level of agility is measured by how appropriate your decisions are and how well you and the IT organization can carry them out. After making a Loop 1 decision, one or both of the other two loops engage to act on your decision. Loop 2 focuses on improving existing operations—delivering efficiency. Loop 3 focuses on creating new operations—delivering effectiveness. When used in combination, the IT organization can use these three loops to sense changes and respond efficiently and effectively. Loop 2 and 3 Agility Skills A close examination of the agility process diagram reveals several important features of Loops 2 and 3 that contribute to an agile IT organization. First,

agility is a process

87

notice that data from the environment and customer demands are handled by a set of standardized operating processes. They handle most of the input reliably and efficiently. The IT systems that drive the standard operating processes (SOPs) of the enterprise should be as automated and reliable as possible. They are the basic transaction processing systems such as ERP, order management, and production scheduling. Make them stable and scalable to handle the fluctuating transaction-processing loads required to support the enterprise in performing its day-to-day operations. Give them robust error handling capabilities that prevent bad data from entering the enterprise’s systems. These systems identify, isolate, and set aside bad data or “nonstandard input” for appropriate people (not computers) to examine. The agility of an IT organization is directly related to its ability to handle nonstandard input. Automated transaction processing systems handle the standard input so people can focus on everything that is nonstandard. This is where people bring the most value and where they should spend most of their time. People need to be skilled in analyzing nonstandard input to determine its cause. Nonstandard input comes from one of two conditions. The first condition results from errors in the input data or in the system operations. If there are errors in the data or system operations, people use Loop 2 to identify root causes of the errors to fix or improve the relevant standard operating processes and the systems that support them. The second condition occurs when the input data is correct and it represents a new trend or an event that was not anticipated when the system was built. New events occur as business conditions and markets change and there are no standard operating procedures to deal with the occurrence. In this case, people use Loop 3 to make assessments about whether it represents a threat or an opportunity. Their work often results in the creation of a new operating process in response to this type of nonstandard input. If successful, the new process is added to the existing stack of standard operating processes. In this way the standard operating processes themselves continue to evolve as the enterprise evolves—this is the agile process that maintains IT alignment. Clearly, agile people in an agile IT organization must be skilled in the tasks called for by these three process loops. Let’s take a more detailed look at each loop by first mapping out the activities that are involved and then

88

chapter 3

a strategically focused it organization

discussing some of the tactical skills and technology needed to do these activities well.

loop 1: monitoring and deciding Flying a jet fighter plane in combat is perhaps the epitome of agility. A fighter pilot named John Boyd devoted his life to understanding and teaching the skills of agility. He fought in the Korean War and then went on to become an instructor teaching the best U.S. and allied pilots in advanced air-to-air combat tactics. Over the years he articulated what he had learned about the best way to deal with fast-paced and complex environments. Boyd encapsulated his teachings in a learnable and repeatable process that shows individuals and whole organizations how to compete and win in any high-change situation. He named this process “Observe—Orient—Decide—Act” (OODA)—also known as the OODA Loop or Boyd Cycle.1 The monitoring and decision-making activities of Loop 1 in the agility process are well described by the Boyd Cycle. The next sections describe the four steps in the Boyd Cycle and show how they can be applied to the tactical operations of an IT organization. Following the Four Steps There are four steps in the Boyd Cycle, and the first step is to observe. This involves collecting and communicating information about the environment. In an IT organization this includes information such as performance statistics for all systems, project status for all development work, and budgetary status. The second step is to orient. This is the most important activity because it is where information is turned into understanding. Understanding is used to build an appreciation of the situation and its possibilities. The next two steps depend on this appreciation of the situation. Translated in terms of an IT organization, the first and second steps mean that the IT operating environment is described and relevant measures are plotted over time so that performance trends become visible. The progress of the different system development projects are summarized showing key project completion statistics such as money spent, deliverables

loop 1: monitoring and deciding

89

produced, and time and budget. Also lay out other expenses in areas such as systems operation, staff training, and salaries. With this information people can assess the situation and look for new threats and opportunities in the IT environment. In the third step, decide, people (1) investigate different responses to threats and opportunities and (2) create and evaluate plans for implementing different responses. In an IT organization, that means creation, evaluation, planning, and budgets for different system architectures and development projects. IT staff members consult with people from the business units who will be users of potential new systems. Choosing the most appropriate plans leads to the fourth step—act. Depending on the decisions made in the orient and decide steps, the act step results in a tactical action that either improves an existing process (Loop 2) or creates a new process (Loop 3). In the act step, action is taken with either favorable, not favorable, or indeterminate results. These results are picked up in the observe step and the loop continues. Note that the Boyd Cycle does not require people to cycle through all four steps all of the time. It is not a lock-step sequence. For example, the decide step is not needed when an environment is well understood. People can simply cycle quickly between orient and act steps in a series of rapid responses. At other times people may decide not to act at all but just observe and orient, waiting for an appropriate opportunity to act. It is better to think of the Boyd Cycle as an interactive network of activities with the orient step at its core instead of a fixed sequence of steps, as illustrated in Exhibit 3.2.2 Most Important Step: Orient Let’s take a closer look at the orient step because it is the most important. People form a picture of the world in the orient step, and this picture of the world drives the decisions and actions that follow. Good orientation is central to one’s ability to take effective tactical action and achieve desirable results. The orient step needs the most support from business intelligence (BI) capabilities. The real world unfolds in “an irregular, disorderly, unpredictable manner” as Colonel Boyd put it. Effective CIOs watch their business and IT

90

chapter 3

a strategically focused it organization

Market information and customer demands

ORIENT

OBSERVE

DECIDE

Implicit guidance Explicit guidance

ACT

EXHIBIT

3.2

The Boyd Cycle

environments and make decisions about how best to respond as day-to-day and week-to-week situations unfold. Dashboards and other Web-based reporting systems significantly improve outcomes in this step. Another major concept of the Boyd Cycle implies that everyone in an agile organization has a common understanding of the organization’s purpose and its major objectives. In military organizations this is known as the “commander’s intent” or the “mission orders”—people are told what needs to be done but they are not told how to do it. They are not micromanaged; instead they are trusted to do the right thing. The Boyd Cycle expresses common understanding of purpose with the notions of implicit guidance and explicit guidance. When the IT staff knows what the CIO expects of them and when they possess accurate, timely information about their own performance, then they can take their own corrective actions as demanded by the situation without waiting to be told what to do. If the CIO defines performance objectives for the IT organization and makes performance data available via dashboards and other BI systems, people do not need to be micro-managed. They can see for themselves what the situation demands and act appropriately. In this way the CIO provides implicit guidance to the IT organization. As shown by the heavier lines on the Boyd Cycle diagram, the best CIOs most often make use of implicit guidance. CIOs provide explicit guidance when they make decisions to change

loop 2: improving existing processes

91

IT strategy and stop or start IT development projects. CIOs use explicit guidance when the rules of the game change. When this happens people need to be informed of the changes and told how those changes affect their jobs and performance expectations. Once this happens people readjust, and implicit guidance again takes over to guide their actions. As CIO you need to make sure that you clearly explain what you expect from people in your organization. Define clear performance measures and expected results. Implicit guidance works very well when people know what the CIO expects of them and when they get regular and accurate performance reports. Implicit guidance is more efficient than explicit guidance because it requires less of the CIO’s time once the performance expectations are in place. Some combination of three leadership errors is troubling your IT organization if the CIO always has to tell people what to do and how to do it: (1) The CIO may not have clearly defined expectations; (2) People are not getting timely performance reports; and (3) The CIO may be changing course and starting new projects too frequently. These three leadership errors push the CIO into excessive use of explicit guidance practices. People cannot be agile in an explicit guidance environment because they are always waiting for the CIO to make decisions and tell them what to do. The CIO who constantly resorts to explicit guidance practices to get things done in the IT organization must find ways to address the reasons causing this unhealthy situation. Your organization cannot be agile until you address these issues. Depending on the decisions people make in the orient and decide steps, an IT organization is constantly called on to act. At the highest level, action can be thought of as activities that fall into one of two categories. The first category includes tactical activities that improve existing operations (Loop 2). The second category includes activities that create something new (Loop 3).

loop 2: improving existing processes In addition to being a universally applicable performance measurement, Six Sigma provides guidelines as IT organizations and project teams move through the activities they need to improve their operations and their products (see Sidebar on the following page). A five-step process guides

92

chapter 3

a strategically focused it organization

“six sigma—a process for measuring quality”

Six Sigma started at Motorola in the 1980s, and since then it has spread to many other organizations. Six Sigma (6σ σ ) is a statistical measure of the performance of a process or the quality of a product. A process operating at a Six Sigma level produces less than 3.4 defects or errors per million opportunities. Six Sigma is a clear definition of excellence that all organizations can aim to achieve. It provides a common measure of performance across different processes and systems, and it can be used by people to compare, discuss, and learn from different operations in different parts of an organization. To get a sigma measurement for a process, first identify the customer the process serves and define what the customer expects from the process. Then collect and graph data as a histogram or a bell curve showing the frequency distribution of the process outcome. The graph shows how many times the process outcome met customer expectations and how many times it did not. This is illustrated in Exhibit 3.3. One sigma means the process met customer expectations 30.9 percent of the time. Two sigma means 69.1 percent, three sigma means 93.3 percent, four sigma means 99.4 percent, five sigma is 99.97 percent, and six sigma is 99.99966 percent. Most companies operate in the range between two and three sigma. A 99.3 percent customer satisfaction rate (3σ σ ) is good, but it means that there are 66,807 failures per million events producing a lot of unhappy customers and unnecessary expense.

IT teams through these Six Sigma activities: define, measure, analyze, improve, and control.3 The process is shown in Exhibit 3.4. It is known as DMAIC (first letter of each step) and is pronounced “dee-MAY-ic”. Let’s take a look at the activities in each step. Define Most of the CIO’s work begins with definitions. The define step begins a Six Sigma project and produces three important documents. The first

loop 2: improving existing processes

EXHIBIT

3.3

93

Six Sigma

document is the project charter. The charter lays out the business case and the problem statement. It also clearly defines the project scope so that the project team knows exactly where to focus and what they should avoid. The charter also articulates the goal or mission of the project and the specific objectives that the team needs to achieve in order to accomplish the goal. Operationally, the charter lays out project milestones that indicate to

94

chapter 3

EXHIBIT

3.4

a strategically focused it organization

Five Steps in the Six Sigma Process

the team where and when they should be achieving other sequential steps in the DMAIC process. Finally, the charter describes the roles and responsibilities of the team members, the team leader, and the project executive sponsor. In addition to the project charter, the second document produced in this step defines and documents the customers that will be served and their needs and expectations. The needs and expectations of the customers tell the team what to measure and improve. The third document is a high-level process map that shows the tasks involved in the process and the inputs and outputs of each task. The high-level process map shows everyone involved with the project the exact sequence of tasks that are candidates for improvement. Measure In this step the project team creates a data collection plan and then collects data that measures the current state of the process or product targeted for improvement. The data collected reflects customer requirements and shows how often the process actually meets customer requirements. The data also shows the activity levels of key tasks in the process. After collecting the data the team calculates the existing sigma measurement for the process. This obvious step of collecting data and documenting

loop 2: improving existing processes

95

the current situation is often overlooked or done poorly because the project team thinks they already know what is wrong and they want to get on to fixing the problem. Good data collection gets the project off to a start in the right direction. Analyze In this step the project team applies statistical analysis tools to discover and validate root causes of problems. Many of the tools used in this step come from total quality management. The team uses cause-and-effect diagrams and frequency distribution charts to pinpoint the sources of error in the process being investigated. They use scatter diagrams to test the strength of correlations between one variable and another in the process. They use run charts to track the performance patterns of various tasks and of the process overall. As they pinpoint problems, the team then formulates options for eliminating or reducing these problems and compares the different options. How difficult is each option? How much will each cost? What impact will each option have on improving the sigma measure of the process? Improve In this step the team leader works with the project’s executive sponsor to select a group of improvement options. They choose the options with the best chance for success and with the greatest impact on the process. With the sponsor’s backing, the DMAIC team implements the selected improvements to the process. Best practice calls for the team to implement the improvements one at a time or in small groups of related improvements. After implementing each improvement the team should collect process performance data and recalculate the sigma measure—hopefully the sigma measure improves. Recollection and recalculation ensures that either the improvements actually provide valuable results or they are discontinued. Control Once a team makes process improvements they need to regularly monitor the process to assure that the improvements stay in place and remain

96

chapter 3

a strategically focused it organization

effective. The DMAIC project team defines a set of measurements collected on an ongoing basis to document performance levels of the improved process. In addition, the team creates a response plan that lays out corrective actions if ongoing performance measures indicate that the improvements are beginning to slip. Over the longer term, the greatest benefit from the Six Sigma approach is that organizations reap the very real benefits of process improvements that continue to improve and thus deliver more and more value.

loop 3: creating new processes: define-design-build In the first phase—Define—the CIO helps people identify a goal and the objectives or performance requirements that need to be achieved to reach the goal. In this phase they create several conceptual designs of business processes or systems that will attain the specified performance requirements and objectives. Then, based on application of the seven strategic design guidelines (see Chapter 1 pg. 11) and ROI analysis (see Chapter 8 pg. 343), they select a preferred conceptual design. Based on this conceptual design, people move into the next phase— Design. This phase expands the conceptual design out to the level of detail necessary for accurate evaluation and implementation of the proposed new system or business process. Teams test the selected technology and procedures for their suitability and create detailed specifications and plans to guide the work of implementation. In the third phase—Build—people focus on executing the implementation tasks as rapidly as possible to deliver the required systems and roll out the new business procedures called for in the design specifications. As the new systems and procedures go into use, objectives are achieved and new situations unfold. People continue working toward their goal by cycling through sequences of these three steps as appropriate. This Define-DesignBuild process is illustrated in Exhibit 3.5. This process of sequential steps increases the momentum of the project at each step. The change, or delta, in the momentum and focus of the project can be objectively measured as work moves from one step to the next.

dynamics of the agile it organization

97

DEFINE

DESIGN

BUILD

People creating something new go through these three steps. The first step defines the business goal and objectives and creates a conceptual design for a solution. The second step creates a detailed design and implemantation plan. The third step builds the solution. EXHIBIT

3.5

Three-Step Development Process

When done successfully, this sequence of steps produces an increase in forward momentum that is as clear as walk-trot-run!

dynamics of the agile it organization The concept of management by exception is nothing new, but in the context of the agile IT organization it is absolutely central to the way the organization works. The agile IT organization lives in a world of continuous and enormous flows of data. How does it process this data without becoming overwhelmed? The agile IT organization works by using standardized operating procedures (in effect an autonomic nervous system) that handle all routine transactions automatically with little or no human intervention. The organization devotes most of its people’s time (its conscious nervous system) to handling only the exceptions or the nonstandard inputs. In an agile IT organization automated business process management (BPM) systems immediately notify appropriate people when exceptions or nonstandard input occur. People analyze exceptions, not computers. If there are errors in the data, people track down root causes and fix them.

EXHIBIT

Organization

98

3.6

System Dynamics of the Agile IT

creating agile new processes

99

When the data is not in error but indicates the appearance of something new, it is very important to have people in the exception-handling loop. This puts them in immediate and intimate contact with the data indicating a change that could be an emerging threat or opportunity. Using implicit guidance they make decisions and act quickly. If changes of strategy are needed, the CIO gets involved and issues explicit guidance. Exhibit 3.6 illustrates the system dynamics of the agile IT organization.

creating agile new processes Efficient operation of existing systems and evolving the IT infrastructure to align with ever-changing enterprise needs are the two main activities of any CIO. The IT profession has gotten very good at the first activity, but the second activity is still a high-risk undertaking. CIOs must demonstrate a high degree of competence and success in this activity to deliver the value their enterprises expect from them. The competitive, global economy requires most enterprises to constantly adapt to changes and reexamine their business strategies. Keeping IT aligned with the business regularly calls for the creation of agile new systems and procedures. The next four sections examine this topic. The process of creating new IT systems has traditionally been described by various development methodologies. The problem with most development methodologies is that they are unnecessarily complex and often too cumbersome to apply in real life. An agile IT organization needs an agile process for developing new systems and enhancing existing ones. Agile development processes have to be powerful yet simple enough so that people can understand and use them when they need them. They should also be flexible enough so that they can be tailored to meet the demands of any specific development challenge. The Define-Design-Build development process addresses these needs. When you think about what is needed to create something new it all boils down to just three basic steps. First define what you are going to create. Then design how to create it. And then you build it. One can further divide each of these three steps into sub-steps, but this only increases the complexity of the process and reduces the likelihood that people will understand or use it effectively. Define-Design-Build provides an uncomplicated framework to guide development work for any new

100

chapter 3

a strategically focused it organization

business process or system. It also provides a reliable way to estimate development times and budgets. Benefits of the Define–Design–Build Process From the perspective of the CIO and other senior executives who sponsor a system development project, Define-Design-Build is a way to manage project risk. In the Define phase small amounts of time and money are spent up front to qualify a business opportunity—5–10 percent of the total project cost. If findings warrant, the enterprise then spends only a moderate amount of further time and money in design—15–30 percent of the total project cost. In the Design phase, a small, prototype system is created to prove that the opportunity is real and justifies a larger investment. The Build phase is where enterprises spend the most of the time and money—60–80 percent of the project total. Notice that the decision to move into the Build phase is made with the greatest amount of information (and the least risk). The nature of the business opportunity and the solution system that will exploit that opportunity are well established by that time. From the perspective of the project leader (the system builder), DefineDesign-Build provides a way to navigate through the complexity of creating a new computer system. The system builder is truly the person on the hot seat who needs to get things done. The CIO and the system builder use the Define-Design-Build process in combination with the strategic system design guidelines and the tactical principles for running projects to structure the work sequence. The process lets them set reasonable time limits within which to investigate situations and make decisions in the Define and Design phases. After making decisions about system design and budget, this same framework provides a set of tactics for the system builder and the team leaders to employ during the Build phase. Core techniques employed in the Build phase give structure to the work and enable the system builder to effectively focus and lead the effort. From the perspective of the people on the project team Define-DesignBuild is a clearly defined and manageable repertoire of techniques for completing new projects. People who participate in each of the three project phases know which of the core techniques they are expected to use as the

creating agile new processes

101

project moves toward completion. They can focus on mastering these techniques. The CIO should emphasize that IT staff members work together on tasks in small groups so that the learning and use of techniques among team members is more effective than if they worked alone. Managing the Encounter with Complexity Define-Design-Build is a three-step sequence that could also be described as “Move it! Move it! Move it!” In order to support an agile IT organization in a high-change world, systems must be built with a quick and iterative process. The project team must strictly adhere to the time boxes for each step in the development sequence. Complexity is as much perception as it is reality, and a disciplined, fastpaced approach is the best way to handle complexity. When the CIO allows project teams too much time to contemplate the situations facing them, team members begin to perceive excessive amounts of complexity and sink into that dreaded state called “analysis paralysis”. Agility means learning to deal effectively with complexity. People learn to become agile when guided by a discipline for developing new systems in a fluid and coordinated manner. They learn by participating in project teams with people trained to use the Define-Design-Build process. Define opportunities, design systems to exploit those opportunities, and quickly build those systems. As success with one opportunity opens up other opportunities, address each new opportunity using and refining the Define-Design-Build process. Your IT organization will build great credibility and momentum in this way. Time-Boxing The Define-Design-Build process depends heavily on the use of appropriate time boxes for getting things done in each of the three steps. Agile processes need to be quick. Regardless of the task at hand, an agile response must be a fast response. Time-boxing sets limits to the amount of time that can be spent on a task, and the job is shaped to fit within the constraints of that box. Time-boxing helps keep a project moving along at a brisk pace. As the saying goes, “The job will expand to fill the time available.” Therefore we respond to that tendency with time-boxed constraints on all development

102

chapter 3

a strategically focused it organization

The DEFINE-DESIGN-BUILD Process DEFINE

Core Techniques: • Joint Application Design • Process Mapping Deliverables: 1. Business goal for system to accomplish 2. System performance requirements 3. Conceptual system design 4. Project objectives 5. Cost/benefit analysis 6. Detailed plan and budget for DESIGN phase

DESIG N

Core Techniques: • Joint Application Design • Process Modeling • Data Modeling • System Prototyping Deliverables: 1. Detailed design of new business process 2. System data model 3. System prototype 4. Detailed plan and budget for BUILD phase

BUILD

Core Techniques: • Object Oriented Design & Programming • System Test & Roll Out

Deliverables: 1. A working system 2. System technical documentation 3. Complete set of operating instructions

2–6 Weeks

1–3 Months

2–6 Months

(5–10% of Total Cost)

(15–30% of Total Cost)

(60–80% of Total Cost)

EXHIBIT

3.7

The DEFINE-DESIGN-BUILD Process

activities. Allocate only a certain amount of time and money to each of the three steps. People learn to manage the scope and pace of the work to meet their due dates and budgets. Set the scope and pace of work in each step of the project to conform to the time and budget constraints shown in Exhibit 3.7. If a step in the sequence is not completed in a timely manner, the process and the project itself is in danger of breaking down. People must stay on track. These constraints provide the implicit guidance to keep

the core techniques

103

project teams from wandering too far off course or getting in over their heads. A Small Set of Techniques The activities in each of the three steps can be accomplished by using an appropriate combination of just a few of techniques. I call this small set the “core techniques” because they are the basic techniques that every systems developer should understand and be able to use. Regardless of the specific technology being used and regardless of the specific business process being addressed, these core techniques remain relevant and applicable. The set of six core techniques are: 1. Joint Applications Design—An inclusive process that combines ideas from both business and technical people to create new system designs. 2. Process Mapping—Exploring and mapping out business workflows. 3. Data Modeling—Defining the data used by business workflows. 4. System Prototyping—A way to model and validate both the user interface and the technical architecture of a system. 5. Object-Oriented Design & Programming—Designing and specifying the structure and working logic of software that will be created. 6. System Test & Roll Out—Testing, training, and implementation of new systems. These techniques are well known in the IT profession so training and reference materials are widely available. People on project teams must be able to apply an appropriate combination of these techniques as needed within the time boxes defined for each step of the Define-Design-Build process. Combinations of the core techniques create the agile tactics needed to develop systems within the short time frames required to support organizations in high-change environments.

the core techniques This section takes a look at the application of the six core techniques and how their use drives the Define-Design-Build process. Every CIO must be

104

chapter 3

a strategically focused it organization

familiar with these techniques. Although CIOs do not perform the actual work of developing new systems, they must be conversant with the proper application of these core techniques to lead their organizations effectively. Just as the game of basketball relies on use of techniques such as dribbling, passing, and shooting, the game of developing information systems depends on its own set of basic techniques. The CIO can objectively measure the skill levels of IT project teams by how capably team members apply these techniques. By skillfully applying these techniques in combinations most appropriate to different situations, an agile project team can always produce competent—and sometimes even brilliant—results. CIOs must see to it that their people are trained in these techniques and that every project team has people skilled in applying the right mix of these techniques to succeed with their project. Joint Application Design The joint application design or JAD technique enables a project leader to create an inclusive process that brings together the knowledge and insights of all the team members. The JAD techniques lay down a set of rules that govern how the team leader leads, how team members interact, and how the team approaches problems. These rules stimulate the creative problemsolving abilities of the team and allow the team to generate a stream of ideas that then become the raw material from which the system design emerges. JAD is a direct response to the overwhelming complexity of the design tasks that we face in business today. People individually analyzing parts of a problem either alone or in isolated groups cannot develop competent or adequate system designs on a consistent basis. However, using the JAD rules, project teams with the appropriate mix of business and technical people can come up with competent system designs every time. A basic set of JAD ground rules is shown in the following list: • Attendance of all team members is expected. If any team member cannot be at a JAD session, then reschedule the session. • Check your baggage at the door. Everyone has a stack of problems and personal issues. Leave them out of the JAD session. • Start and end sessions on time. Everyone is busy these days so treat the time spent in JAD sessions as valuable and respect people’s schedules.

the core techniques

105

• Every session must have an agenda. At the beginning of each session review and confirm the list of issues the group will address and the deliverables it will create. • Everyone is of equal rank while in the JAD session. Everyone on the team is equally important in what they have to contribute or else they would not have been asked to participate. • Team member comments will be kept confidential. In order to participate freely, people must know that statements they may make will not be repeated outside the session to people who could hurt or embarrass them. • Deal with issues, not personalities. We can discuss issues and evaluate solutions to them in a rational and creative way only if we ourselves are not personally being discussed or evaluated. • Everyone participates, no side conversations. It is through the combined insights and ideas of the whole group that good ideas emerge. Side conversations are distracting and disrespectful to the group. • Reach consensus or request “a decision from above”. If the JAD team cannot come to an agreement on a particular issue, then it must outline several possible solutions and ask for a decision from the executive sponsor of the project. Process Mapping Process mapping defines a set of steps for identifying the work processes that occur in an enterprise and the connections between these processes.4 The team first identifies the highest-level processes and then the subprocesses within each high-level process. They define the data inputs required by each process and list the sources of the data. Their work also defines data outputs generated by each process and lists the destinations of the data outputs. This technique uses diagrams to create a visual map of the tasks in any process and the data that flows between the tasks. This visual map creates a common reference framework for business and technical people to discuss issues and discover opportunities for process improvements. Process maps are far more effective than written documents because they use graphic means to communicate a lot of information quickly and accurately. Exhibit 3.8 shows an example of a process map diagram.

106

chapter 3

a strategically focused it organization

Task 1

Task 2

Data Store A

Task 4

Task 3

Task 5

Data Store B

Task 6

Task 7

The process map shows the inputs and outputs of tasks in the workflow. It can also show places where data is stored. EXHIBIT

3.8

Process Map

Data Modeling The data model defines the entities about which data needs to be collected. The entities are usually identified while using the process mapping technique. Entities such as customer, product, and invoice can be found in the data flows between different business processes. The data model then defines the properties or attributes that must be known about an entity. For example, the entity called “customer” has attributes such as customer number, name, address, and credit limit. Data modeling also produces a visual diagram called an entity relationship diagram or ERD. Like the process flow diagrams produced by the process mapping technique, the ERDs provide another visual method for

the core techniques

107

Product

Customer

Cred it Rating

Targe t Market Home City

Demograph ics

This sample data model shows that there are six entities that the managers of any given business process must understand and how these entities relate to each other. EXHIBIT

3.9

Data Model—Entity Relationship Diagram

communicating a lot of information to the business and technical members of a project team. Everyone on a team can spot-check the entities on the diagram with which they are most familiar to ensure accuracy. Exhibit 3.9 shows an example of an entity relationship diagram. System Prototyping There are two kinds of system prototyping. The first kind of system prototype is a system’s user interface model. By looking at the process mapping diagrams the project team decides which tasks will be fully automated, which ones will be a mix of human activity supported by a computer, and

108

chapter 3

a strategically focused it organization

which ones will be completely done by humans. By looking at the data model they can see what data will be handled by each task. The prototype of the user interface builds upon this knowledge to create the layout and sequence of computer screens to support the tasks where humans and computers interact. The user interface prototype also illustrates how the users of the system can navigate between screens, and it shows the layout of any printed output generated by the system. The development team designs this kind of prototype by using an interactive slide show displayed on a computer screen that allows the system user to move from one screen to another via keyboard, mouse, or other commands. It shows the business people what they will get when the new system is built. The interface prototype is something tangible and participative that people can work with, respond to, and make suggestions for improvement. The second kind of system prototype is a technical architecture prototype composed of the hardware and software components that have been selected to build the system. This prototype demonstrates how well the system components will work together. The selected software is installed on the selected hardware. Links are then established between the different software components. The team passes data back and forth under different conditions to measure the hardware and software components’ ability to work together and handle the expected number of users and volumes of data. The architectural prototype shows the technical people what issues they will face when they build the system. It allows people to verify that the technology they have proposed to use in building the system will work as advertised and meet the performance demands of the new system. Exhibit 3.10 illustrates the idea of the two types of system prototypes—the technical architecture and the user interface. Object-Oriented Design & Programming Object-oriented design (OOD) and object-oriented programming (OOP) are the latest incarnation of a set of techniques that have been evolving for the past 30 years in the systems building profession. The purpose of these techniques is to enable the design and programming of stable, reusable software that is easy to debug and easy to modify.

the core techniques

109

Technical Architecture

User Interface

The prototype of the system’s user interface shows how people will use the system. The prototype of the system’s technical architecture shows how the system will be built. EXHIBIT

3.10

System Prototypes

The object-oriented techniques are analogous to the engineering techniques an electrical engineer uses when designing a piece of equipment such as a cellular phone. The cell phone is specified as a collection of component parts. Many of these parts are integrated circuit chips (IC chips) plugged into a motherboard. Each IC chip is defined by the inputs it accepts, the operations it performs, and the output it creates. Software objects are the equivalent of the IC chip in this example. A system is composed of interacting software objects just as a cell phone is composed of interacting IC chips. The popular concepts of Web services and

110

chapter 3

a strategically focused it organization

services oriented architecture (SOA) are based on the use of object-oriented programming. Web services are composed of programs (objects) from existing systems that communicate with each other by sending inputs and receiving outputs over the Internet using agreed-upon XML formats. Once the object-oriented design has been completed, the programming is a relatively straightforward process of writing code to meet the design specifications for each object. All the hard decisions about how the objects operate and interact to drive the system are made in the objectoriented design. The choice of the programming language influences the design of the objects to some extent, but the object design is largely language independent.

Import Data System Screen Export Data

Manage Data

Show Catalog

Main Menu SQL Database Format Data

Update Codes Code Maint.

The object model shows the modules of program code—the objects—and how these objects interact with each other to drive the system. EXHIBIT

3.11

Object Model

the core techniques

111

The system builder can manage the programming effort very effectively by simply tracking the programming progress object by object. Generally, objects can be programmed in one to three days. They can be programmed in any order and could all be done in parallel if there are enough programmers available. In this way, new programmers can be added to speed up the programming process without causing confusion and loss of project control. Exhibit 3.11 illustrates a sample object model diagram. System Test & Roll Out Project teams use this collection of techniques to test the system in a thorough and orderly manner to find and fix the bugs and then to roll the system into production. System test and roll out techniques allow people on the project teams to first test each object individually, then to test the groups of objects used in each system function, and finally to test the entire system. The programmers who program each object first perform unit testing on the object. When an object passes the unit test, it is checked into a system test environment. People familiar with the specific operations that the system is designed to perform create test scripts and use these test scripts to put different parts of the system through its paces. They write test scripts that exercise the different features of the system in a wide range of usage scenarios. The entire system is assembled and tested as more and more parts of the system come together in the test environment. Once the system has passed through the test environment with all the bugs fixed, the team follows a regular sequence in rolling out the system. The first step uses a beta test or pilot group of people who begin using the system for their normal jobs. The pilot group participants define a range of system modifications that fine-tune the operation of the system and improve the ease with which it can be used. Finally, the system rolls into production. Appropriate training always anticipates and supports the roll into production so that people who depend on the system are not left to cope with the change entirely on their own. The system testing sequence is illustrated in Exhibit 3.12 Now let’s explore the details of how project teams combine and use these six core techniques in each step of the Define-Design-Build process. By combining selected core techniques they create useful tactics to get work done and achieve the development plan objectives.

Unit Test Each object

Function Test Functional collections of objects

System Test (Alpha Test) The entire collection of objects that make up the system

Beta Test Entire system tested by selected people in real-world setting

Production Roll Out System is introduced to the people who will use it and they are trained in its use EXHIBIT

112

3.12

S y s t e m Te s t i n g S e q u e n c e

define—the framework for action

113

define—the framework for action It is amazing how often the Define phase is overlooked or badly performed in the rush to get a project started. Yet this phase forever after either guides or confuses the project team. When performed well, it provides clarity and greatly increases the chances of project success. When performed badly, confusion reigns, and the project has very little chance of success. The purpose of the activities in the Define phase is to align the system development project with the business strategy. In this phase, the business executive who sponsors the system development project clearly spells out the goal or mission of the project by working with the CIO and the system builder to identify the performance criteria that the system must meet. Defining the Project Goal The project goal should not be a technical goal. It should be a business goal—something that provides a significant business benefit or a set of benefits. It should be stated in a format that identifies an action to be taken and states the expected benefit from that action. Some examples are: • Strengthen and grow the national accounts program by acquiring customers in vertical market segments A, B, and C. • Reduce the complexity of the steps involved in the warehouse receiving process to make product available for sale immediately after delivery. The goal answers the question, “Why should we do this project?” It is a qualitative as opposed to a quantitative statement. Everyone affected by a project quickly understands a well-written goal statement. A goal statement should not be longer than a sentence or two. Do not confuse a project goal with a vision statement. A vision statement is a much broader statement about the organization’s purpose and aspirations. A goal is one of the things an organization must accomplish in order to bring its vision to life. Creating the Strategy Once a project goal has been defined, the next step is to create a strategy to accomplish it. By definition, the strategy uses the means or capabilities available to the business to achieve certain objectives—in this case, the

114

chapter 3

a strategically focused it organization

project goal. Businesses often implement strategies by building systems to obtain the new abilities they need. The sponsoring executive works with the CIO and the project’s system builder to define the strategy and the high-level or conceptual system design. To define a project strategy, begin by listing a set of desired performance criteria that the system should meet in order to accomplish its goal. Chapter 1 discussed how Robert Kaplan and David Norton in their famous 1992 Harvard Business Review article, “The Balanced Scorecard— Measures That Drive Performance” defined four perspectives that create a comprehensive view of an organization’s performance (more on this for the IT organization in Chapter 5). It’s helpful to describe the system’s desired performance criteria from these four perspectives as well: 1. Financial Perspective—What financial measures should the system achieve? 2. Customer Perspective—What do external and internal customers want from the system? 3. Business Perspective—What business processes must the enterprise excel at to accomplish the goal? 4. Learning Perspective—How do people continue to learn and continuously improve their ability to accomplish the goal? Brainstorm a list of performance criteria for each perspective. Then review the lists and select three to six of the most important performance criteria. These are now the measures of success for the project. A successful project builds a system that meets all these criteria. Next, strive to achieve these criteria in dramatically new ways by asking the question, “What seems impossible now, but if we could make it possible, would dramatically change the way we do business?” Look for ways to use systems that change the business landscape to give your organization a significant competitive advantage by doing something new and different. The Conceptual System Design The conceptual system design literally embodies the strategy the CIO uses to create the system. Whenever possible, good conceptual designs build on systems and procedures already in place. The conceptual design is the highlevel outline of a system.

define—the framework for action

115

Referring to the seven strategic guidelines for designing systems in Chapter 1 pg. 11, generate several different conceptual designs for systems that meet your specified performance criteria. Express the design as a workflow diagram or a process model. Further define the high-level activities in the workflow by specifying the data that goes into and out of each activity. For each activity, estimate the volume and frequency of the data flows and the source and destination of each data flow. In addition, define the types of people (if any) who will perform the work for each activity. How many people are needed? What are the skill levels of the different types of people? Exhibit 3.13 shows how the system process flows for a proposed e-business system.

y Unique catalog for each cus tomer location

SUPPLIER Collect Prod uct & Price Data

Create Customer Product Catalogs

Calcu late prices for thousands of products and hundred s of catalogs

CUSTOMER Get Customer Orders

Growing number and size of orders per day

Daily updated sales history by customer, by product and time period Provide Sales History Reporting

Route Order to Servicing Membe r

EXHIBIT

3.13

BUSINESS UNIT

Collect Customer Inv oices

Growing number and size of invoices per day

CUSTOMER

SUPPLIER

Data connection s to different type s of computer systems at the business units

BUSINESS UNIT

System Process Flows

116

chapter 3

a strategically focused it organization

Next, decide which activities will be automated, manual, and part automated and part manual. As a rule, people like systems that automate the rote, repetitive tasks and empower them to do problem-solving and decision-making tasks more effectively. People are the spark that animates the system, and technology’s role is to support that spark. Evaluate the computer systems infrastructure that already exists in the organization. Look for ways to build on existing systems that work well enough. The most cost-effective new systems are those that adapt existing systems and deliver valuable new capabilities to an organization quickly and with a minimum of expense. To get started, select the simplest combinations of technology and business processes that meet your specified performance criteria. Balance the need for simplicity with the need to increase the capacity of the system to handle greater volumes of data and the ability to add new functionality as the business grows. Refine and improve the system as you get feedback and ideas from others. Apply the Seven Strategic Guidelines Conceptual system designs should respect all of the seven strategic guidelines discussed in Chapter 1. Under some circumstances there may be reasons to violate one or maybe two of these guidelines. The only guideline that can never be violated is the first one—closely align systems development projects with business goals. If the system devised to accomplish the business goal violates one or two of the guidelines, the executive sponsor and the CIO both must acknowledge these violations and provide justification. A system design that violates only one guideline is acceptable. If it ignores two guidelines, there must be very good reasons for doing so. If it ignores more than two guidelines, the conceptual design is fatally flawed and should be reworked. Define Project Objectives When looking at the new workflows and the information system designed to support those workflows, the system resolves into a set of high-level components. Each component should be devoted to the performance of a closely related set of tasks, such as storing and retrieving data, helping customers find a product, placing an order, or shipping products to customers.

define—the framework for action

117

The building of these high-level components becomes the set of necessary and sufficient objectives to create the system you have designed. Projects generally use between three and nine high-level components or objectives, and all other components resolve into sub-components of these high-level components. Strive for no more than three to nine high-level components because most people cannot quickly comprehend or easily remember more than seven (plus or minus two) things at a time. Clarity of system definition and the related objectives is critical to the success of the project. If the Define phase produces a system definition (the conceptual system design) so complex that only a genius can understand it, then it is useless. Project team members will not be able to use it effectively to guide their work in the next two phases. Without a clear system definition, people on the project team will have different interpretations about what the project is meant to accomplish. People working on different objectives will find it increasingly difficult to coordinate their actions, and the level of tension and argument will rise as the project continues. The objectives selected should each be achievable in nine months or less. Each objective should provide value in its own right. An objective should not be just an intermediate step that depends on the completion of a subsequent step to be of value. Select objectives that can be achieved quickly because they begin providing value and repaying the cost of the project before it is even finished. Once achieved, an objective becomes a base from which other objectives can be achieved. Avoid defining objectives that lock the project into a rigid sequence of development activities. The real world rarely goes according to plan, so an agile plan must be flexible in order to adapt as reality unfolds. Begin work on a handful of objectives at the same time (work on objectives in parallel). Structure the tasks needed to achieve one objective to be independent of the tasks needed to achieve other objectives. This provides maximum flexibility because delays in achieving one objective will not affect the completion of other parallel objectives. This way the system builder can shift resources from one objective to another as needed, and the project continues to move forward. The system conceptual design shown in Exhibit 3.14 has four high-level components numbered on the diagram. Each of these components provides value in its own right, and work on each component can proceed

118

chapter 3

a strategically focused it organization

1 . Extranet

2 . Web -Ba sed E -Com m e r ce Systems CU STOM E R Enterprise Business Unit

Product Catalog CU STOM E R

3. Data Warehouse (Product Data)

3. Data Warehouse (Order Data)

Order Entry

4. Data Delivery System (NetLinkNSC)

Enterprise Business Unit

CU STOM E R

S U P P L I E R

Order Status

CU STOM E R

Customer Service

Enterprise Business Unit

Inventory CU STOM E R 4. Data Delivery System (NetLinkNSC)

Sales History CU STOM E R

Enterprise Business Unit

S U P P L I E R

3. Data Warehouse (Company Data)

S U P P L I E R

1. Extranet

The greatest business value lies in the construction of the data warehouse that houses the supply chain data and in building the data delivery system called “NetLink-NSC.” Working together, these components are the best way to meet the supply chain performance criteria defined by the enterprise. In order to meet financial performance criteria and reduce project risk, it was decided to lease the use of an existing Web-based product catalog and order entry system instead of building one from scratch. In building the NetLink-NSC system people reused parts of an earlier system that provided for electronic receipt and error checking of customer invoices from business units. © 2000, 2001, 2002, 2003 Network Services Company

EXHIBIT

3.14

e-Business Systems Infrastructure

independently of the others. These four components become the four objectives for the system development project to create the system shown in this conceptual design. Create Initial Plan and Budget Once the set of project objectives have been defined, a high-level project plan can be created. Create a section of the overall plan for each objective. In the section of the plan devoted to each objective, list the major tasks necessary to achieve that objective. There will be tasks related to designing

define—the framework for action

119

and building the deliverables necessary for each objective. Show the dependencies between the tasks and between the objectives. The plan now reflects the strategy being used for building the systems needed to accomplish the business goal. The plan also defines the time boxes for the Design and Build phases of the project. Estimate the total project budget by calculating the time and cost needed to achieve each project objective. Each task that is part of the plan for an objective will require some number of people with appropriate skill sets for some period of time. Each task will also require certain technology and perhaps other expenses, such as travel, hotel rooms, and meals. Create a spreadsheet to show the project cost by task for each objective. After estimating your costs, do a cost-benefit analysis. If it is hard to quantify the different kinds of benefits provided by the system, take this as a warning that the goal of the system has not been well defined or is not very valuable. If the costs of the system outweigh the benefits, find a cheaper and simpler way to accomplish the goal. Avoid the use of expensive technology with more features than are really necessary to get the job done. Exhibit 3.15 shows a summary overview of the work in the Define phase. Outputs of the Define Phase The agile CIO consistently requires five specific outputs from the Define phase work before moving forward to the Design phase: 1. A clear statement of the business goal to be accomplished. 2. The performance criteria required from the system. These criteria usually fall into four measurement perspectives: (1) financial results; (2) customer expectations; (3) critical business operations; and (4) learning and continuous improvement. These identify and communicate the conditions of success that the system must meet. 3. A conceptual design for a system to accomplish the business goal and meet the performance criteria. The system design is composed of people, process, and technology. The conceptual design is the embodiment of the strategy being used to attain the goal. 4. A definition of the project objectives that are needed (necessary and sufficient) to build the system. Objectives are those items that must be built to create the system outlined in the conceptual design.

Exhibit 3.15 DEFINE Phase

The GOAL is the target or the mission . Make it clear. In two sentences or less, state the action an d the desired resu lt. Also state the performan ce criteria needed t o reach the goal.

GO AL

2– 6 Weeks

1.

Devise a STRATEGY to ac complish this GOAL tha t maximize s the use of the organization’s resources and the things tha t it doe s well.

2.

Express this strategy as a PROCES S flow t hat mee ts specified performance criteria (fina ncial, custome r, operation s, learning ).

3.

Specify h ow PEOPLE fit into the flow. Define the TECHNOLOGY that supports the proc ess and the people. You now have a CONCEPTUAL SYSTEM DESIGN.

PROCESS

PEOPLE

TECH NOLOGY 4.

Identify the nece ssary and sufficien t set of measurable ac hievements needed to build this system —these are the project OBJECTIVES.

Objective A

Objective B

Objective C

Objective D

(Time & Cost)

(Time & Cost)

(Time & Cost)

(Time & Cost)

5.

The Initial PROJECT PL AN & BUDGET is the sum of the estimated times and costs for each project objec tive.

6.

Use cost-benefit analysis to verify that the conceptual system design will accomplish its goal in a cost-effe ctive manner. Modify the conceptual system design if necessary to reduce cost.

EXHIBIT

120

3.15

DEFINE Phase

design—workflow and technical system design

121

5. A cost-benefit analysis verifying that the project is worth doing. The senior business executive responsible for accomplishing the business goal that the system will address must confirm that this analysis is valid.

design—workflow and technical system design The purpose of the Design phase is to flesh out the conceptual design and create the detailed technical system specifications. The phase begins with the system builder reviewing the project goal, the conceptual system design, and the project objectives with the project work group. The work group is composed of business and technical people who have the necessary mix of business and technical skills and experience needed to do the detailed system design. It is important for people to understand senior management’s intentions and the project’s goal. Specific issues relating to the project objectives and budget can be investigated during this phase. If necessary, some adjustments can be made to the project objectives in light of the findings that come out of this phase. Work in the Design phase falls into three activities: 1. Create detailed process model diagrams for the new system. 2. Define the logical data model. 3. Build and test the system prototype, that is, the user interface and the technical architecture. Divide the total time allotted to the Design phase among these three activities. Allocate the necessary time to competently complete each activity but avoid the temptation to spend extra time excessively analyzing and checking and re-checking the results that come out of each activity. It is important to keep the people involved in these three activities working together. System process models, system data models, and system prototypes are just different aspects of the same system. The designs for these three activities must be created in concert or they will not function properly when assembled. The three design teams must work simultaneously. Use the joint application design (JAD) technique to integrate the work of people who focus on the three different activities. As the process team defines the details of the business process flow, the data modelers can record

122

chapter 3

a strategically focused it organization

the data needed by the process. As the process requirements and the data volumes become clear, the technical architecture can be defined and tested to validate how well it supports the process and the data. As the process flow, the data model, and the technical architecture are defined, the prototype team can design the user interface needed to fit the process flow and handle the related data. The Role of the System Builder Business and technical people commonly experience a communications gap. The CIO is ultimately responsible for assigning a qualified and competent system builder to lead each development project. The system builder is responsible for creating an inclusive design process that involves both kinds of people and bridges the gap between them. Both business and technical people commonly rush to conclusions about how a process should work or what kind of technology should be used. The system builder must be a person who is able to tolerate ambiguity and set an example by reserving judgment and taking the time allocated to explore and select the best of the different design options. When this happens the creative power of the people on the project begins to open up. The system builder pushes the project teams to keep looking for the simple underlying patterns that define an effective business process. The system builder leads the search for elegantly simple ways to support the process with technology. Remember, more complex system designs are harder to build and less likely to succeed. The Design Process Spend the first part of the Design phase in JAD sessions where business and technical people explore different process designs. People from both disciplines should “think outside of the box” and generate as many ideas as possible. The team then selects the most useful ideas and fits them together into a coherent, detailed map of how work will be organized and flow through the business process. After sketching out the process workflows, the JAD sessions focus on how technology will be used to support this process. The design team starts by defining how people in the process will interact with the technology supporting the process. Often, designing this user interface takes the form

design—workflow and technical system design

123

of creating a sequence of screens like a storyboard that illustrates what people will use in their jobs as they perform their work. When designing the user interface, look for ways to automate the rote and repetitive work. People don’t like to do this kind of work—it is usually boring and computers do these kinds of tasks very well. Look for ways to empower the problem-solving and decision-making tasks. Design systems that give people a rewarding work experience. If the JAD team decides to use a packaged software application, that package should be brought in and installed in a test environment. Script out realistic usage scenarios and load the databases used by the package with a sampling of real data. People, who will both use and support the package, need to evaluate it by working through the usage scenarios. The technical people responsible for building the system should sit in on the JAD sessions. As the design unfolds, they should be selecting technology—hardware, operating systems, databases, and other software that will effectively support the system being designed. They should participate and listen to what the business people need for doing their jobs. They should not, however, slow down or confuse the design process with excessively technical questions or long dissertations about hardware and software. During the Design phase it may become clear that a given performance criterion cannot be met. It may become clear that the initial conceptual design from the Define phase is not quite right and must be modified. Accordingly, certain project objectives might require redefinition. The project goal must remain unchanged but the specific objectives needed to accomplish the goal can be changed as needed. The system builder is the liaison between senior management and the project work group at every step in this redefinition process. Creation of the Detailed Project Plan and Budget As the detailed design specifications emerge near the end of the Design phase, everyone involved should have a clear idea of their work and the time they need to accomplish it in the subsequent Build phase. The system builder assists each team to figure out how they will do their work and how long it will take, challenging them to set ambitious but achievable time frames. Encourage teams to break their work into discreet tasks that take one week or less because the week is the standard unit of time in business.

124

chapter 3

a strategically focused it organization

Teams must strive to accomplish something of measurable value each week to maintain their momentum. A project plan that clearly lays out performance expectations for every person every week is a valuable tool for coordinating and monitoring the work of building the system. A plan at this level of detail is also the best way to arrive at an accurate and realistic project budget for the Build phase. As the project teams each create their specific task plans to achieve the objectives assigned to them, the system builder combines these plans into the overall project plan. In a process somewhat analogous to the manner in which a general plans a campaign, the system builder plans the sequence of activities that will lead to the successful building of the system specified in the Design phase. Divide or segment the overall project plan by objective. Devote a section of the plan to each objective. The system builder determines the best sequence for achieving the project objectives and arranges the project plan to reflect this sequence. Then the task plans created by the project teams assigned to each objective are inserted into the sections of the project plan devoted to their objective. Look for opportunities to run activities in parallel. Flexible, agile projects accomplish more work this way. When projects run activities sequentially, a delay in one activity causes a ripple effect that delays all the other activities queued up behind it. When activities are run in parallel, a delay in one does not delay the others. In well-designed project plans, deliverables from activities running in parallel come together at the end and combine to achieve the objective. Running activities in parallel allows project teams the opportunity to finish one activity and then shift resources over to help out other teams that experience delays. Delays are inevitable on any project. Any plan that fails to account for delays and provide team members the flexibility to effectively respond to them is a plan whose timetable and budget will quickly be thrown into disarray. The Decision to Proceed or Not to Proceed If doubts arise about the viability of the project or if the revised budget has grown too large, reduce the scope of the project or cancel it altogether. At this point only 20 to 40 percent of the total project cost will have been

design—workflow and technical system design

125

incurred. The business has yet to commit the major effort on the project. Pay special attention to projects with viability or budget issues whenever they occur. It is all too common for organizations to run the Design phase as a poorly done research project. Teams spend a great deal of time in detailed analysis of what already exists but produce only sketchy designs for the specifics of the new system. Debates break out on many aspects of the design of the new system, but no one can agree on clear answers and critical decisions are not made or are pushed into the Build phase. Use the Design phase as an opportunity to reduce the risk on a project before committing large amounts of time and money. The more detailed the design specifications, the better the chances for building the system on time and on budget. The broader the understanding of and support for the system among both the business and the technical people, the greater the likelihood that the system will be used effectively and produce the desired business results. Exhibit 3.16 illustrates the activities in the Design phase. Design Phase Deliverables The agile CIO expects four detailed deliverables from Design phase work before approving a project for the Build phase: 1. A detailed design and map of the new business process flows supported by the system. Make sure there is agreement among the people who have to work with the system that it will meet the performance criteria expected of it. The specifications for the business process are created using the process mapping technique and captured in documents such as process flow diagrams and process logic descriptions for each step in the process. 2. A system data model that accommodates the data identified by the process map. The data model should be created using an entity relationship diagram (ERD) that other people on the project can understand. The model should also record the volume of data that will be handled and the frequency with which different types of data will be accessed. 3. A system prototype that specifies both the technical architecture and the user interface. There should be a development environment

Goal & Objectives

Exhibit 3.16 DESIGN Phase 1– 3 Months

A

B

C

The system bu ilder reviews w ith the project work group the GOAL, the co nce ptual system design, an d the projec t OBJECTIVES that were s et by sen ior management.

D

15–30% of Total Cost Project teams use core techniques to flesh out the conceptual design and create detailed system designs and specifications

Process Map

Data Model

System Prototype

Project Plan & Budget

Detailed system specifications allow the creation of a more accurate project plan and budget.

EXHIBIT

126

Objective A Task 1 Task 2 Task 3 Objective B Task 4 Task 5 Objective C Task 6 Task 7 Total Project

3.16

DESIGN Phase

Cost $999

$99

$999

——

$9,999

build—system construction and roll out

127

in operation where all the components of the technical architecture are installed and working together. This technical architecture must be capable of handling the anticipated data volumes and user demands. Define the user interface needed to support the process logic in the relevant steps of the process flow. There must be a complete set of screen layouts, report formats, and specifications for all aspects of the user interface. 4. A detailed project plan and budget that accurately reflects the time, cost, and resources needed to build the system. No plan can predict the future or anticipate all obstacles, and no budget can accurately estimate every cost. However, plans and budgets built up from the detail task level and structured to provide as much flexibility as possible are essential to guiding the project to a successful conclusion.

build—system construction and roll out The project effort really ramps up in the Build phase. The full complement of people is brought on to fill out the project teams. Consequently, the weekly cost or “burn rate” on the project rises significantly in the Build phase. Unlike the previous two phases, the cost of false starts and wrong turns now adds up very quickly. This is where your system builder vigorously exercises project leadership skills. Activity must be tightly focused on the completion of those defined tasks necessary to achieve the project objectives. In this phase, good design and planning pay off handsomely. The System Blueprints The initial work in this phase creates the system object model from the combination of specifications from the data model and the system prototype. This activity is often started in the Design phase as part of the detail design and budgeting process. By completing the work at the appropriate level of detail, the project teams produce very exact blueprints of what they will build. This strengthens the teams’ understanding of and confidence in their ability to complete the work according to plan.

128

chapter 3

a strategically focused it organization

System blueprints take the form of the screen layouts, database design, system object model, and detailed technical architecture diagrams. These documents guide and structure the work that creates the actual system. The system builder and the team leaders track their progress every week using these documents to discuss relevant details. Teams create and test system database and software in the system development environment. The development environment created in the Design phase supports the prototyping of the technical architecture and the user interface with the actual hardware, operating systems, and database packages used to build the system. Pre-programmed application software packages used for parts or all of the system also are installed and tested in the development environment. Once programming begins, record progress at the object level using the object chart as the reporting tool. Circle an object as work begins. Everyone can see how long the work should take. Color in objects when work has been completed. People can see software development progress at a glance by looking at the object model. When problems develop the system builder and team leaders can use the object model to quickly see what issues affect each object. They can then focus on specific solutions for welldefined problems. If software development projects are not tracked at this level of detail, people resort to the infamous “percentage complete” method. Under this method, large multi-week tasks quickly become “70 percent complete” (whatever that means). Then the last 30 percent takes four times as long to finish as the first 70 percent, and nobody can figure out why. The Project Office The system builder effectively coordinates and focuses activities on a fastpaced project through the project office. The CIO uses the project office to accurately manage a portfolio of IT development projects. The project office employs a skilled staff dedicated solely to working with the system builder and the team leaders to update the project plan and budget as work progresses. The system builder is analogous to the general manager of a business unit, and the project office is like the accounting department. The general manager does not have time to keep the business unit’s books nor is that the general manager’s job. But if no one keeps the books, the general

build—system construction and roll out

129

manager loses touch with where the business really stands and this inevitably leads to bad decisions. There is a pervasive tendency for people to hide bad news such as delays and cost overruns. Trouble results unless leadership takes active steps to counter this tendency. People should not be penalized for reporting bad news. On the contrary, leaders who give their people permission and encouragement to report delays and potential cost overruns as soon as they perceive them improve the entire project’s chances of success because problems are seen earlier and everyone has more time to react. Early reporting gives everyone more time to respond and respond effectively. The project office staff exists to help people keep track of actual project progress and make good decisions with the information the project office provides. Indeed, one of the best ways to get into trouble is to hide bad news because when the truth finally does come out, then there is usually very little (if any) time to respond effectively to the situation. System Test and Rollout As major system components or subsystems are delivered, they are beta tested with a pilot group of business people who were involved with the Design phase of the project. In this way they already understand and accept the need for and benefits of the new system and that makes them effective beta test personnel. Expect to make adjustments to the system architecture and to the user interface during the beta test. People who operate the system architecture will need to tweak different operating parameters to get the best response time and stability from the system. People who designed the user interface will need to sit down with the beta test group of business users and listen to their ideas for improvements to certain screens. Business people in the pilot group smooth off the rough edges as they test the system and make suggestions for adjustments. In this process, advocates for the system emerge from among the beta test group. They will feel a personal connection to the success of the system because the system takes on a look and feel influenced by their suggestions. These people sell the benefits of the system to the rest of the enterprise and often become the ones to train their co-workers in using the new system. Exhibit 3.17 shows the operation of the Build phase.

3.17 BUILD Phase

Project Plan & Budget Objective A Task 1 Task 2 Task 3 Objective B Task 4 Task 5 Objective C Task 6 Task 7 Total Project

2 – 6 Months

C os t $999

$99

$999

Allocate resources to achieve objectives on time and on budget

—— $9,999

od el

Object model is derived from the data model and the system prototype

Data Model

System Prototype Object Model

Re-calcu late the tim e and budget ne eded to complete eac h ob jective every week .

Develop men t

Environm ent

H ardware & O /S D atabase

So ftw are

System Test & Rollout

EXHIBIT

130

3.17

BUILD Phase

build—system construction and roll out

131

Lead by Staying Involved The CIO relies on a mixture of information from the updated project plans, budgets, personal visits, and investigations into projects that attract attention. Effective CIOs cannot spend undue time in their office reading e-mails and writing reports. Effective CIOs hold regular meetings with all their system builders to review progress on projects, and as problems arise, the CIO continuously assesses when to get personally involved and when to delegate to others. Inevitably, obstacles arise and delays happen. The agile CIO demands flexibility in the project plans and uses people skilled in the core techniques. System designs that use simple combinations of technology and business process to achieve multiple objectives are more likely to be built on time and on budget. With system designs like this, CIOs can quickly shift resources from one project to another because the same skill sets and technologies are being used. In this way, the agile CIO retains options to deal with the obstacles and delays that occur. Build Phase Deliverables Agile CIOs expect three critical deliverables from the Build phase work: 1. A working system that matches the design specifications and meets the performance criteria. Schedule the building of the system so that the process delivers something of value to the business every 30–90 days. This means that certain pieces of the system must be finished and put into use before the entire system is completed. 2. A complete and updated set of technical design documents. The design documentation is analogous to the wiring diagrams and structural plans of a building. This documentation enables the IT organization to build enhancements and make repairs to the system in the future. The documentation should include at least the object model, the data model, an organized library of program source code, and diagrams and descriptions of the overall process flow of the system. 3. A complete set of user and operating instructions. The people who operate and maintain a system are different from the people who build systems. The people who operate a system need to know how

132

chapter 3

a strategically focused it organization

to bring the system up, bring it down, and carry out performance tuning, troubleshooting, and operating maintenance. Assign the people responsible for operating a new system to work with the development team during system rollout to define the needed operating and maintenance documentation.

two wins, a lose, and a draw: lessons in complexity Four real projects from my own experience seem like the best way to examine what works and what doesn’t when it comes to developing new systems using the principles discussed in this chapter. All were prominent, multimillion-dollar system development projects. I was the overall project leader or system builder on three of them. On the fourth I was one of four team leaders—there was no system builder. These four projects span the years from the early 1990s to the early 2000s; two were major successes, one was an utter failure, and one, though not a complete failure, was not a complete success either. These projects used a range of technologies—IBM mainframes with COBOL and DB2, Sun servers running Java and Sybase, and Windows servers with SQL Server databases accessed through Windows PCs and Web-based thin clients. Although the technology and the business goals were different for each of these projects, I began to see consistent reasons for project successes and failures. A timeline analysis of these four projects demonstrates the importance of the agile principles discussed in this chapter. These timelines illustrate practical lessons I learned the hard way. I learned that the seven strategic system design guidelines and the six principles for running projects really work and that there are consequences when they are ignored. I also saw that the core techniques (the skills of the game) were applicable each time regardless of the technology being used. These guidelines, principles, and core techniques represent a body of knowledge that must be understood and applied to successfully create a new system. Finally, I saw that there is a basic, underlying sequence to the process of building computer systems. That sequence is Define-Design-Build. Depending on the system development methodology or the consulting firm facilitating development of a new system, there could officially be a

two wins, a lose, and a draw: lessons in complexity

133

much more complicated process in place but that added complexity leads to trouble. Simplicity and clarity are the keys to success in multidisciplinary projects prone to different interpretations by both business and technical participants. Define-Design-Build remedies the tendency to make projects more complex. In a more complicated development process the Define phase might be divided into two or more steps with important sounding names such as “Preliminary Needs Analysis” or “System Concept Justification”. The Design phase may also be fractured into three or four steps with more fancy titles and the Build phase can be broken into a further number of steps. This added complexity neither increases people’s chances of success nor changes the basic sequence of events that have to occur. First, one must still define what is to be done. Next, one must design how it will be done. And lastly, one must build it. The following charts in Exhibits 3.18 through 3.21 are maps of the four projects. They show how each project unfolded over time. Study the sequence of activities and read the notes that explain these activities for an overall appreciation of each project. Underneath every chart is a brief description of what happened. Look for the ways that successful projects consistently applied the principles I present in this chapter, and try to pinpoint where the failed and partially successful projects lost focus. Takeaway Lessons What can be learned here? To begin with, every project needs a qualified, full-time project leader or system builder who has full responsibility and day-to-day authority for running the entire project. Working with the senior businessperson sponsoring the project, the system builder identifies a specific business opportunity and defines the system performance criteria needed to exploit that opportunity. Projects should focus on developing new system capabilities not already available in existing systems. For the best results, combine new technology with existing systems to create new systems. Avoid re-creating functions that already exist in older systems that work well enough. You run up too many costs and deliver too little value when you rip out existing systems and replace them with new technology that does essentially the same things.

134

chapter 3

a strategically focused it organization

Based on feedback from version 1.0, we DESIGN and BUILD enhancements to create version 1.1.This achieved the project breakthrough.

DEFINE-DESIGN-BUILD sequence creates clear conceptual design and version 1.0 is delivered in nine months.

Direct Mail subsystem

Three DEFINE-DESIGNBUILD sequences ran in parallel to create new subsystems to respond to opportunities that appeared after the project breakthrough. This resulted in version 2.0 of the system.

LAN-based telemarketing system

ProductFinder subsystem version 2.0

Q1

Q2 Q3 YEAR 1

DEFINE

Q4

Q1

DESIGN

Q2 Q3 YEAR 2

BUILD

Q4

Q1

Q2 Q3 YEAR 3

Q4

System Delivered

This development sequence narrowed scope and focused resources up front to create version 1.0 of the system and achieve the project breakthrough point. Once the breakthrough had been achieved, multiple DEFINE-DESIGN-BUILD sequences were launched in parallel to exploit the opportunities that opened up. I followed all the strategic design guidelines. The tactical principles for running projects were followed although there was no staff devoted exclusively to the project office function. The team leaders and I did the project office work, and at times we did not keep plans and budgets up to date. If the project had been any larger, the lack of dedicated project office staff would have hurt us.

EXHIBIT 3.18 System Development Sequence for an Enterprise Sales Suppor t System—A Win

By building upon existing systems, a much simpler set of new technology can often be used. PC workstations can be used to run terminal emulation software, giving people access to existing mainframe systems. New applications can be Web- or server-based. The whole mix of new and old applications can be integrated under a single graphical user interface by

two wins, a lose, and a draw: lessons in complexity

135

DEFINE created a conceptual system design to accomplish e-business goal.

Strategic planning exercise

Beta test data warehouse & sales history reporting Ver 1.0 NetLink

DEFINE phase identified four system components and DESIGN-BUILD sequences ran in parallel to produce version 1.0 of these components. Project breakthrough was achieved.

Ver 1.0 Data Warehouse

New web site

Tech Infrastructure Version 1.0 of E-Business Systems

DESIGN-BUILD creates version 1.1 enhancements to two system components.

NetLink Enhancements

Data Warehouse Enhancements

Data Warehouse Enhancements

DEFINE-DESIGN-BUILD creates version 2.0 enhancements to exploit further business opportunities.

Web Site Enhancements

NetLink Enhancements

Q3

Q4

DEFINE

Q1

Q2 Q3 YEAR 1 DESIGN

Q4

Q1

BUILD

Q2 Q3 YEAR 2

Q4

Q1

Q2

System Delivered

The development sequence was focused and tightly time-boxed. Work ran in parallel during the DESIGN-BUILD phases requiring good planning and coordination. Version 1.0 of the e-business systems infrastructure was created in nine months. Based on positive reception and feedback from version 1.0, enhancements for version 1.1 were created. Further assessment of business needs led to definition of next round of major enhancements that created version 2.0 of the ebusiness infrastructure. I followed all of the seven strategic design guidelines and respected the six tactical principles for running projects. This project was a clear demonstration of how to quickly and cost-effectively design and build a suite of new systems that then provide significant competitive advantage.

EXHIBIT

3.19

A Web-Enabled Supply Chain—A Win

136

chapter 3

a strategically focused it organization

Six-month DEFINE phase was spent selecting new technology and identifying possible sales applications but no clear goal or performance criteria were defined. Only a sketchy conceptual system design was produced.

Three DESIGN teams worked for six months on different but overlapping parts of the system. There was confusion and arguing. Much duplicate work was done. First version was not ready for beta test as originally scheduled— programming continued.

One BUILD team received design specs from three DESIGN teams. Specs filled hundreds of pages, and the BUILD team changed them on the fly without notice. They spent almost a year programming and re-programming.

Q1

Q2 Q3 YEAR 1

DEFINE

Q4

Q1

DESIGN

Q2 Q3 YEAR 2

BUILD

Q4

Q1

Beta test version fails to live up to expectations. Project was canceled at year-end and millions of dollars were written off. Q2 Q3 YEAR 3

Q4

System Delivered

On this project there was a long DEFINE phase that resulted in a broad project scope, but there was no clear focus of effort. Resources were then spread across several different DESIGN teams who developed complex designs. Design specifications were handed off to a BUILD team that was overwhelmed by the amount of work required. Momentum was lost and a breakdown occurred in the BUILD phase. Programmers worked long and hard but the project never recovered. I was one of four team leaders. There was no overall project manager or system builder to answer questions or resolve disputes. The strategic design guidelines were completely ignored—some deliberately and some out of carelessness. Most of the tactical principles for running projects were violated. Project teams did have 2–7 people and we did have freedom to figure out how to do our work, but we still did not know exactly what we were supposed to do. So everything took forever.

EXHIBIT

3.20

T h e Ne w Te c h n o l o g y f o r S a l e s Pr o j e c t — A L o s e

giving each application an icon that users click on to switch from one application to another. Employ the time boxes suggested in the Define-Design-Build process and move the project along at a fast clip. It is very important to set and maintain a brisk pace on a project to prevent it from degenerating into a

two wins, a lose, and a draw: lessons in complexity

137

Partnership formed with high-tech company to provide advanced information technology. There was great enthusiasm and a rush to get started. Performance of first beta test version was unacceptable— response time was very slow. Beta test system worked but did not generate much enthusiasm. There was no project breakthrough.

Project team of people from company and high-tech partner designed and built first version of system.

The system and related business assets were sold for several million dollars to recoup some of the project expenses.

Project was reorganized and reenergized. The project goal and system performance criteria were clarified. New project leader was put in charge.

Q1

Q2 Q3 YEAR 1

DEFINE

Q4

Q1

DESIGN

Q2 Q3 YEAR 2

BUILD

Q4

Q1

Q2 Q3 YEAR 3

Q4

System Delivered

The project got off to an adequate start, but then faltered because the technology did not perform up to expectations, and the business logic was not accurately captured during the DESIGN phase. The project was reorganized and re-energized but no fundamental changes were made in technology or project scope. The renewed effort produced some better results but not enough to gain acceptance of the system from target customers. I was the new project leader brought in when the project was reorganized. I followed the tactical principles for running projects and applied them vigorously. The project was closely aligned with a business goal and there was some flexibility in both the project plan and the project staff. However, the other five strategic guidelines were not followed. I learned what many have learned before—great tactics cannot make up for flawed strategy.

EXHIBIT

3.21

Next Generation Financial Ser vices

System—A Draw

sluggish and indecisive voyage to nowhere. Use the overall time boxes for each phase and then subdivide these boxes into smaller boxes for each of the major activities defined in a phase. Further subdivide those activity time boxes into task-level time boxes. The trick is to define time boxes that are both aggressive and realistic.

138

chapter 3

a strategically focused it organization

Both of the projects that succeeded shared a very effective approach. Simply stated, this approach first focuses the development effort to create a breakthrough deliverable—a deliverable that proves the system and wins over lots of supporters. After achieving the breakthrough deliverable, make every effort to exploit it quickly by developing more system enhancements and new subsystems to address further opportunities opened up by the breakthrough.

■ notes 1. Robert Coram, Boyd, The Fighter Pilot Who Changed the Art of War, (New York: Little, Brown and Company, 2002). 2. Material on the Boyd Cycle or OODA Loop can be found on the Internet and in several books. Two authoritative Web sites are www.belisarius.com and www. d-n-i.net. Robert Coram’s book referenced above is also a good source. Another insightful book written by one of Boyd’s associates is: Chet Richards, Certain to Win, (Philadelphia: Xlibris Corporation, 2004). 3. George Eckes, Six Sigma for Everyone, (New York: John Wiley & Sons, 2003) 29. 4. A classic book on the technique of process mapping is written by Tom DeMarco, Structured Analysis and System Specification, (Englewood Cliffs, NJ: Yourdon Press/ P T R Prentice Hall, 1979).

chapter

4

The Sum of IT Can be Greater than its Parts by william flemming, sas, and alan stratton, stratton associates, llc

If one were to ask symphony patrons and symphony professionals what section of instruments in an orchestra is the most important, the answer would surely be all of them. Composers utilize every section and every instrument when writing symphonies. Symphony orchestras have steadily changed since they first appeared in ancient Egypt, and the role of every instrument has evolved over time. The end game for a conductor is to get all the sections to perform in harmony. Performing without a section of instruments leaves a gap that cannot be hidden. Posing the same question to IT customers and IT professionals, pick the most important part of IT—pick the one process, one section of infrastructure, or the one department that stands out as the most strategic piece of IT—what would be your answer? Does IT have one most important strategic piece? If one asked this question of industry vendors and analysts, their answer would invariably be the product or service they sell. If one asks CIOs this question, the answers depend upon the state of IT maturity, the most pressing need of the day, and the state of the business where they work. The SAS cut-to-the-chase answer is this: None of the pieces are strategic by themselves. None. IT has too many parts. Often organizations gather these parts into technology stovepipes and manage them accordingly. Technology stovepipes lead to incoherence and disharmony within 139

140

chapter 4

the sum of it can be greater than its parts

and outside of IT. IT Finance is often just another stovepipe within a stovepipe. Reporting the cost of service without including the results of the service is an example of a stovepipe telling only part of the story, one section playing in isolation. Conversely, reporting service results without the corresponding cost and value is also only part of the story. No single stovepipe can reveal the sum of the parts of IT. To understand why, let’s extend the symphony analogy to help cut through the abstractness and complexity that is IT. Because symphony orchestras are not created equal, consider the situation of a poorly conducted, overburdened, large city, symphony orchestra. Due to budget constraints, the symphony has to settle for young, inexperienced musicians to replace departing musicians. To compensate for their shortcomings and develop these new musicians, the orchestra consumes most of its rehearsal time training and correcting mistakes. To increase efficiency, the orchestra sections rehearse individually until they each become proficient. As a result the sections have difficulty finding the time to play together as a full orchestra—the case of the Silo Orchestra. The score calls for the orchestra to play in harmony. Individual sections cannot carry an entire symphony nor can they practice in isolation and then perform in public with perfect harmony. It comes as no surprise to hear that in past seasons the public performances of this orchestra were poorly played. Patrons became frustrated. Reputations suffered. Funding declined. As an institution, the orchestra was left with a foundation of poorly played symphonies, declining public support, and declining musician morale. Still, the demand for classical music remained high. The community depended on the symphony for a portion of its identity and an indication of the city’s prominence among the communities of the world. With the competition orchestras face from other sources of classical music, expectations for Silo Orchestra performances rise higher and higher. In today’s musical world now so heavily dependent on technology, patrons constantly compare one orchestra’s performances to other orchestras’ recordings, performances broadcast from other cities with digital sound, and performances captured on DVDs played over home theater systems. The lack of quality compared to competition quickly becomes very apparent to Silo Orchestra patrons.

why it sections play in isolation

141

To turn this orchestra around, how might its leadership approach learning a new repertoire and building the orchestra at the same time? Or, more to the point, how does this analogy apply to IT? How does IT learn a new season’s repertoire and build the orchestra to world-class caliber at the same time? IT organizations face the same dilemma as the orchestra. (1) Learn new business “symphonies” (applications) every year with higher expectations than the year before. (2) Learn to build a better orchestra (IT staff ). (3) Relearn the old, badly played symphonies. All at the same time. Like Silo Orchestra, many IT organizations have various stovepipes playing and rehearsing in isolation to gain efficiencies. Like the orchestra, the IT stovepipes are organized by sections. Woodwinds over here, UNIX over there, Finance in here. Although it is cheaper and more effective to have experts in one technology than generalists who must have skills across several technologies, IT organizations that depend on generalists often lose view of the symphony. This leaves an IT organization where no one plays a strategic role and without any way to bring all the stovepipes together to play from the same score. Stovepiping is the classic misalignment conundrum: Each might do good work in isolation, but how can the CIO tell if the right part is being played correctly, much less harmoniously and strategically? The enterprise pays IT to play the symphony of business applications. Like the orchestra, IT’s sections must play harmoniously together to deliver strategic value. Best practice CIOs know that none of the IT organization’s parts can function strategically unless IT functions in strategic unison as a whole. This chapter examines the strategic role of IT Finance by emphasizing that IT Finance cannot be strategic by itself. Finance must be joined with other IT governance and processes to develop symphonic capabilities and work together in harmony with enterprise strategy.

why it sections play in isolation SAS published an IT Governance maturity model depicted in Exhibit 4.1. This model reflects the approach most IT organizations use to gain process maturity and incorporates the best of IT thought leadership. However, most current research and surveys indicate that IT maturity still lags despite a recent emphasis on process management. This particular process model advocates that all IT organizations build from the bottom up in sequential

142

chapter 4

the sum of it can be greater than its parts

Change

Vision IT Business Ojectives

Governance Financial Optimization Service Optimization Resource Optimization Stabilization Time EXHIBIT

4.1

S A S ’s St e p s t o I T Gove r n a n c e

steps and not skip any steps along the way. The model is a practical, stepby-step maturity process. The main premise here is that the CIO must build IT organization maturity and business value on top of a solid, predictable infrastructure. We at SAS and our IT customers agree with this premise. So would our friends in the symphony orchestra. IT begins to part ways with the orchestra as the other dimensions of IT maturity add complexity to the problem of maturing IT and adding business value. An example of complexity is the implementation of process management to move from stabilization to business alignment. One such process management framework is the IT Infrastructure Library (ITIL). ITIL is gaining rapid acceptance in the United States after an excellent track record in Europe. Another source of complexity is the extensive automation required for IT operations and management. Orchestras do not need to trade in their violins every other year for a newer, more powerful, more capable, more musical violin. Just how far along the maturity index have most IT organizations developed? According to a Gartner survey of CIOs in 2005, only 12 percent of

why it sections play in isolation

143

those interviewed had attained Level 3 of service—Value on the Gartner IT Management Process Model.1 Twelve percent! Yet 42 percent wanted to be at Level 3 by the end of 2007. Why the lack of progress? Why are so many IT organizations hovering around Stabilization? The answer reflects another key difference between an orchestra and IT. Symphony orchestras have been in existence for centuries. Hundreds of years of experience have resulted in knowledge and a foundation of traditions that provide a path toward excellence for classical music. IT, on the other hand, has been in existence for only several decades. During that time, technology has grown so rapidly and the application of the technology has been so diverse, that IT management practices lag far behind. Given that IT management lags behind the technology that IT organizations provide to their enterprises, the reasons why processes fail to rapidly mature should come as no surprise. The same CIOs state that they encounter difficulties in accelerating IT development: • Upper management support • Practical implementation guidelines • Time to develop a thoughtful approach • Hierarchical reporting structure • Effective organizational communication These shortcomings indicate that IT organizational processes are often mired in technology-centric management environments that make it difficult to communicate problems, results, and issues either to peers managing different technologies or to upper management. The CIOs also point to a chaotic/reactive maturity environment where they spend time reacting to problems rather than preventing them. Because putting out fires consumes more time than preventing them, IT never finds the time to develop an approach to bring the organization to a higher maturity level. Mixed messages compound the problem. Alongside SAS’s IT maturity governance model, other writers give a different message about how IT should think and behave. They suggest that IT should provide immediate business value by implementing the applications and technology needed to compete in a global economy. Who can argue with that? But they assume that the enterprise architecture is as stable as the best practices discussed in Chapter 2—often an invalid assumption.

144

chapter 4

the sum of it can be greater than its parts

Notice that the very last stage within the maturity model is IT Governance and Business Alignment. After all the other steps are completed, IT begins to deploy the technology, processes, and applications to solve business problems and enable business strategy. By contrast, Silo Orchestra must learn new symphonies for the coming season of high expectations while rebuilding. The orchestra can’t skip a season of performances any more than IT can put a year-long moratorium on new business applications. Nor can either the orchestra or the IT organization implement new performances on an unstable platform.

building a mature it organization while learning new symphonies This chapter of CIO Best Practices is about Strategic IT Finance. This section begins to discuss the role that Strategic IT Finance plays within IT. Without a strategic framework for IT and IT Finance, no part of IT can play a harmonious strategic role. Strategic alignment lies at the heart of the issues preventing IT maturity and growth. A strategy that provides practical implementation and thoughtful guidelines, allows IT to overcome matrix organizational reporting, and supplies effective communication across IT and to IT’s business partners, gives senior management the necessary resources to support the transformational development of IT. Strategic Performance Management (SPM) pulls all the parts together into a two-pronged approach that simultaneously enables IT to (1) engineer internal maturity and (2) play new application symphonies for the business. This SPM model follows a Balanced Scorecard approach to manage the two-pronged approach and measure the results. The two prongs enable IT to connect new business applications to IT processes with a Top-Down strategy and build internal engineering and processes simultaneously following the SAS model stages of IT readiness. The Top-Down prong concentrates on defining, implementing, and measuring the IT-enabled value of new business applications. Or, putting it another way, the Top-Down prong focuses on capital expenditures. The Bottom-Up prong deals solely with applications already implemented. Most companies would consider this to be expense. In a nutshell, the mixed messages that prompt IT organizations to work beyond their current level of maturity are encapsulated in capital investment versus expense. IT Finance guides both prongs.

building a mature it organization

145

Balanced Scorecards use four perspectives in the top or “executive” scorecard (see Chapter 5 for a detailed discussion of using the Balanced Scorecard for IT performance management). Each perspective contains initiatives that drive the two-pronged IT Finance strategy in Exhibit 4.1. The format of the perspectives neatly corresponds to the IT world and, for IT Finance, outlines the role that Finance plays in orchestrating business strategy. Exhibit 4.2 shows the four perspectives and corresponding initiatives for an IT organization. The perspectives are divided into those that face the external environment to follow investment and customers and those that face internally into IT operations and concentrate on expense management. Customer Performance Optimization provides the strategic performance guidance that allows the IT organization to align with its customers. Financial Performance Optimization strategically guides IT Finance to improve financial management internally and externally and illuminate IT’s financial performance managing customer business applications. Learning and Growth concentrates on the processes (ITIL) that IT must put in place to build maturity. Resource and Service Optimization characterizes the internal engineering required to build the maturity foundation. In an undertaking as large as guiding and managing IT maturity, the need for tools and automation that bridge the individual stovepipes is fundamental. The SPM model groups each Executive Level perspective into an “optimization suite”. Each suite contains tools and initiatives that encompass each maturity level while building the new application repertoire. Each suite works like an orchestra section with its own specific role to play. While they may play a solo from time to time, the purpose of the suites is to strategically play the business symphonies in harmonious unison. A well-thought-out plan appears concise on the executive level. A wellthought-out plan also abstracts several layers of complexity. To understand the role of IT Finance within the Financial Performance Optimization perspective requires a basic understanding of the other suites and initiatives. Following the SPM model, this discussion begins with a general overview and then uses strategy maps to illustrate the role of IT Finance. (For more information on IT organization strategy map development see Chapter 5, pg. 208–210.) On the expense prong, the Resource Optimization arm of the Resource and Service Optimization perspective delivers infrastructure stability and predictability, places the right infrastructure capacity at the right place at

146 EXHIBIT

4.2

An Executive Scorecard Guides Strateg y Implementation

it strategy mapping

147

the right time, forecasts seasonal and business metric saturation points, preempts threshold violations, and creates business metrics. In other words, it helps move IT from stabilization to resource optimization on the maturity scale. Resource Optimization does not, however, measure negotiated service-level agreements. Service Optimization negotiates business application service-level agreements and costs. Because service-level agreements here are expressed in terms of Availability/Response/Throughput, the agreements for each business application greatly depend on how well Resource Optimization measures manage capacity and exceptions. Service Optimization does not measure the effectiveness of capacity forecasting or measure the cost of providing the service. Financial Optimization measures the financial results of the other optimization perspectives plus a few other areas. Here, IT Finance folds into IT strategy and enables the sections to play together symphonically. For purposes of this chapter, Financial Optimization focuses on three key areas: (1) Cost of Business Application Service; (2) Cost of ITIL; and (3) Cost of Infrastructure Capacity. Each of these merges with appropriate results from other optimization suites to give a strategic view of the results.

it strategy mapping Any well-considered, well-managed plan consistent with the complexity of ascending IT maturity indices must set an execution order to the initiatives mandated by the strategy. Similar to PERT charts in project management, strategy maps depict the critical path and relationships between the initiatives. As the strategy is deployed, the strategy map helps identify whether the performance goals are met. Key initiatives that fall behind in attaining goals or targets delay strategic execution. Guiding IT maturity development while learning new applications is a complicated undertaking that requires a strategy map with two separate views. First, Exhibit 4.3 shows the Bottom-Up view of the SAS Governance model; Exhibit 4.4 shows the Top-Down new business application view. Any chaotic, failure-prone IT hardware and software infrastructure is a recipe for poorly played symphonies and the reputations that follow. Accordingly, the first order of business is to put an end to the infrastructure failures. The CIO cannot forecast capacity, define business services, or

148

chapter 4

EXHIBIT

4.3

the sum of it can be greater than its parts

IT Strateg y Map from a Bottom-Up

Pe r s p e c t i v e

show attractive financial results while the IT organization works in a reactive stage of maturity. Not only is firefighting financially expensive, it also carries the opportunity cost of preventing both IT growth and adding value to IT customers. Resource Optimization is the foundation, which once built, moves IT from reactive to proactive/capacity management. Resource Optimization is also the foundation for Top-Down efforts. It is the lead goose. All other initiatives follow its lead. The first step on this journey begins by harvesting and consolidating all the necessary IT infrastructure metrics into a Performance Data Warehouse. Scrubbing and transforming IT metrics from the isolated technology stovepipes is the key technology layer. A pristine Performance Data Warehouse serves many purposes including providing key metrics for IT Finance—metrics used on a daily basis. Metrics are also

it strategy mapping

149

stored on a long-term basis allowing a series of strong and vital initiatives to use the baseline data. A fundamental component in stabilizing the infrastructure is setting performance thresholds and generating exception reporting (this discussion does not cover the ITIL processes that also play a key role in stabilization, proactive management, or service levels). Catching potential performance degradation indicators (including cost) before performance falls allows the IT organization to mature from the developmental stage of a reactive to a preventative workforce. The metrics used to prevent performance malfunctions and stabilize the infrastructure also enable the next maturity step to be taken. Forecasting capacity and providing service-level agreements means engineering the raw consumption metrics into business workloads. The basic measures of CPU, memory, and queues stabilize the infrastructure. Use the same data to answer what is consuming CPU and memory over time, at peak seasons, around business-driven growth, and through abnormalities, allowing the application of forecasting tools to predict capacity needs in terms of business needs. Also use the same data to measure cost so that cost can be part of the performance evaluation. Forecasting and managing capacity is a key step toward providing mature services to IT patrons. In efficient fashion, Resource Optimization uses its metric foundation to stabilize performance and forecast and manage capacity. Even more economically, the Performance Data Warehouse uses actual business workloads to calculate the performance and cost of service-level agreements. In some capacity configurations, more advanced capacity costing tools illuminate the true cost of peak capacity provisioning decisions, discussed in greater detail later in this chapter. The strategic role of Financial Optimization in IT maturity initiatives is to provide financial insight into resource and service optimization and legacy applications. The financial insight required transcends far beyond traditional budgeting or departmental views of financial performance. Financial Optimization strategy determines the costs of capacity, services, and legacy applications with transparency into the cost elements. Expressed another way, Financial Optimization, IT Finance’s new role, must create cost models that have all the sections of the IT organization as cost elements: people, processes, and infrastructure expressed in cost

150

chapter 4

the sum of it can be greater than its parts

objects of business service, processes, and IT customers. IT Finance must illuminate the internal engineering. Strategy Mapping: Top-Down Prong Because a single strategy of building from the bottom to attain the highest stage of IT maturity would, in the end, create an endless cycle of retrofitting the stream of new business applications back up the maturity index, IT must also implement new business symphonies while engaging in maturity engineering. Rather than wait, the best practice CIO begins a parallel set of customer-facing initiatives that capture business cases and service requirements. Doing so implements the new applications with the business value already defined.

EXHIBIT

Pe r s p e c t i v e

4.4

I T S t r a t e g y M a p f r o m a To p - D o w n

it strategy mapping

151

The Top-Down strategy prong concentrates on the Customer Performance and Financial perspectives of the Executive Scorecard, assuming that IT has progressed from the bottom sufficiently to provide the necessary infrastructure metrics prior to new application implementation. As in the BottomUp portion of the strategy, a single initiative precedes the other initiatives—Driving Business IT Alignment through Business Cases. The proper use of business cases, automated or otherwise, details the business objectives, IT automation requirements, IT financial requirements, service requirements, and volume forecasts. Gathering the business case data establishes the value of applications, how much the customer is willing to pay for the service, the service parameters, and the basis for calculating capacity forecasts. While business case review is critical before implementation, the business case also provides the basis for ongoing financial review over the life of the service. Conditions rarely remain the same for very long. The business case provides the context for its lifelong review. Major enhancements deserve appropriate scrutiny and review lest they drift out of the parameters originally envisioned. IT Finance takes responsibility for creating the models to measure the cost of the service, cost of capacity, and the cost of IT processes. Reporting back to the customer is the art of the symphony. Cost of service and the results of the service and cost of capacity with the accuracy of the forecast each surface the good and bad cost elements that IT Finance must orchestrate to create a symphony of strategically harmonious customer-related information that supports decision making. Service-Level Agreements To ease into a discussion of the heart of IT Finance best practices and the role Activity-Based Costing can play, let’s look at the crucial relationship between IT Finance and service-level agreements (SLAs). In this discussion, SLAs are the IT organization’s product for its business customers. SLAs define the performance requirements of each business application. SLA performance requirements can be quite granular, extending down to individual processes and to the time of day. In addition, properly defined SLAs determine the value the business places on the application by setting forth how they are willing to pay for the performance requirements of the

152

chapter 4

the sum of it can be greater than its parts

application. Measuring the financial performance of SLAs is as important as measuring other facets of SLA performance (expressed in terms of Availability/Response Time/Throughput or A/R/T). Many IT organizations struggle to define and implement SLAs, but in reality they struggle to reverse-engineer legacy applications into SLAs. Here IT Finance and Service Management clearly falls on the expense side. Creating “operating” service-level agreements where IT measures A/R/T while determining SLA operating costs establishes a baseline that pays dividends when IT helps the enterprise create business cases to assess whether to keep, enhance, or replace aging applications. Financial review applies equally to new business cases and older, legacy services. With new capital expenditures for new business applications, the Top-Down prong predefines the SLA requirements. Taken together, new and legacy SLAs become the essential IT Finance measurement and a key ingredient in the discussion that follows.

it finance’s strategic role— illumination Finance has a split personality with its two primary roles in the enterprise. The first is a traditional role as the funds custodian. This custodial role includes financial responsibility for enterprise resources. Custody also includes appropriate internal controls and financial transparency required by law and by stakeholders. However, more important to strategic IT management is the second role, that of business partner, or fellow musician playing in unison with other employees in the harmonious interpretation of the same strategic score. All organizations look to finance when operations are expressed in monetary terms. Traditionally, cost, associated revenue, and profit have been the sole monetary picture of operations. However, these traditional pictures have been expressed in external reporting terms such as GL account costs by organizational department or in total. These traditional pictures have not leveraged Finance’s specialized skills and training to provide financial information more directly useful to operations. Often, the information is not supplied in the context of the underlying operations. Because costs are always the result of operating capacity decisions and process results, understanding cost requires the operating context.

it finance’s strategic role—illumination

153

Historical costs are always a lagging indicator of operating results. Transforming cost into a leading indicator involves more careful understanding of the underlying operating relationships. This transformation takes more effort than a historical cost analysis, but it is worth the effort when insightful advance decisions prevent waste and inappropriate resource deployment. As the CIO seeks to improve IT’s part in the symphonic performance, IT Finance’s instruments must illuminate the financial results of IT’s initiatives to become more mature as an organization and provide immediate business value. Advancing the maturity of the IT organization and immediate business value of the IT strategy spell out the methods and IT Finance’s role in each strategic prong of Exhibit 4.1. Finance provides a common measure for all sections of the IT orchestra. Financial measures help to blend and optimize the various sections for a performance worthy of the IT players. For the moment, assume that the CIO manages the IT organization as an enterprise separate from those business units consuming its services. The resulting perspective is illuminating. It brings the Top-Down strategy to the forefront: If IT services are being purchased, what does the customer expect from IT? What would IT as a supplier provide? The customer would expect: • Consistent service delivery as specified in contract • Consistent quality • A competitive price As an external supplier, IT would provide: • Adequate capacity to assure consistent service delivery as required by contract • Robust processes to provide consistent service • Invoices with prices and supporting documentation of services provided In this arm’s length environment, the price that the customer is willing to pay would be based on perceived business value and a benchmark of prices and services offered by other IT suppliers. The customer is willing to pay for what their business consumes but not for waste or excess capacity. Excesses are not allowed to inflate the price. If

154

chapter 4

the sum of it can be greater than its parts

special note for internal it or non-profit organizations. Profit is a powerful decision driver, but you don’t have revenue and therefore don’t have profit as a decision basis. Consider establishing prices for services offered to internal customers. Benchmarking other organizations would set these prices. These prices would be for internal analysis only—not implemented in the formal accounting system nor paid by internal customers. However, these would provide a profit equivalent to enhance and drive better decision making.

the price is too high, the customer finds other alternatives. It is critical to note that for a profit-oriented IT provider the cost to provide the service does not establish the price. Independently, market conditions set prices. The profit to be realized drives the supplier’s desire and willingness to provide the service. Profit equals revenue minus cost. For a high enough price, an IT service provider purchases whatever capacity it needs in order to make a profit. When prices are too low, IT service providers redeploy resources to a more profitable market and potentially stop offering the service. If profitability is low, IT service providers are highly motivated to improve the efficiency of their operations. If profitability is too low, the service provider leaves the business. An external customer wants assurance of the supplier’s ongoing ability to provide services. Part of this evaluation is the supplier’s financial stability—an issue totally separate from adequate detail behind invoices for services rendered. As an external supplier, IT would not provide complete financial transparency of its operations to its customers. This financial information would be highly protected; provide only publicly available summaries. The IT service provider would not open its financial records. At most, it offers customers only enough exposure into its operations to assure them that they have the capability and quality to provide the services being requested. What is the difference for IT’s business customers when IT is not external to the organization but works inside the organization? In most circumstances, internal customers cannot switch to an external IT service provider.

it finance’s strategic role—illumination

155

As an internal supplier, IT typically cannot sell services and capacity to other customers outside of the parent organization. Should the internal customer expect any less consistent service delivery or quality? Should internal IT provide less than adequate capacity to assure consistent service delivery or consistent quality? Should customers now be expected to pay for waste and inefficient operations? Should customers now expect unlimited capacity and unlimited services for free? NO to all these questions! The best practice CIO changes IT’s ability to work more closely with its internal customers to meet the company’s overall strategic objectives. In other words, provide immediate IT business value and implement those IT-enabled solutions on a stable architecture supported by mature processes (see Chapter 3). When part of the same enterprise, IT and its customers are more closely yoked together and should be driving to a common fortune. As a consequence of Enron and other accountancy-related trials, financial transparency is now a common battle cry. What does this mean to IT and its internal customers? First, what it does not mean is a dump of every possible bit of information on the customers’ desks. What it does mean is providing accurate and appropriate information relevant to strategic decision making and backed up with additional detail if desired. Together with a foundation of sound internal financial management, this is the financial transparency internal IT customers seek. Financial transparency should enable (1) self-regulation to adjust and fine-tune behavior and (2) strategic operational choices. Financial transparency does not mean computing figures four, eight, or twelve digits to the right of the decimal point. Financial transparency that enables greater enterprise-wide maturity means providing figures that are relevant and accurate for the decisions being made whether measuring the value delivered to IT’s customers or guiding IT’s own maturation process. In an internal IT environment, billing internal customers for services is a separate consideration from knowing and sharing the cost of services rendered. An actual billing for services is a choice, not a requirement. However, knowing and communicating the cost of services is essential for the CIO and the IT organization because it contributes to forming and fine-tuning strategy and optimizing operational resources. For internal customers, it helps them make appropriate choices concerning the mix and quantities of services they consume. Without understanding the cost of a service, customers naturally want the Cadillac version. Knowing the cost

156

chapter 4

the sum of it can be greater than its parts

enables them to choose the service level adequate to their actual needs. The bottom line is that reports to internal customers give the CIO and the IT organization an opportunity to communicate in clear business terms with transparency to cost elements.

alternative tools for implementing strategic it finance Traditional financial tools crafted generations ago provide little help for IT Finance to play a strategic role. Limited to these tools, IT Finance cannot identify the strategic symphonic themes IT needs to play, let alone participate in the performance. Fortunately, new tools have become available. Activity-Based Cost and Management (ABC/M) is a recently developed set of methodologies and tools that provide management analysis to aid in decision making. Cost is a direct result of operating decisions, and therefore a measure of performance. Rising or declining costs are symptoms of resource decisions and utilization. ABC/M is primarily a symptom diagnostic tool that provides cost information for more strategic management decisions. Coupling cost with other strategic performance metrics results in a complete picture of operating results and value. This complete picture provides the decision illumination that management needs. Before describing how ABC/M assists IT decision making, familiarity with a few ABC/M basics immediately suggests how this tool is superior to traditional methods. If you are already familiar with ABC/M, please read the next section anyway and look for the nuances of its application to the IT environment. First, there are a couple of things that ABC/M is not. ABC/M is not a transaction recording tool like more familiar financial transaction instruments such as Accounts Payable, Asset tracking, and the General Ledger. As an analytical tool, ABC/M uses summarized information provided by these transactional tools to provide decision grade information for management decisions. ABC/M is not the General Ledger (GL). The GL has other important purposes in the custodial role of finance that center on external reporting and internal controls. It has its own highly controlled environment with many rules governed by external reporting and tax requirements. Because it is optimized for external and tax reporting purposes, the GL is not optimized for internal analysis and reporting. For this reason, it is difficult, if

alternative tools for implementing strategic it finance

157

not impossible, to use GL reports to understand the cost of specific service outputs. ABC/M information includes costs provided by the GL but then goes much further by analyzing these costs for internal management’s use rather than for external use. ABC/M provides the principles and methodologies to trace and understand the costs of operations as an input to internal decision-making processes. ABC/M couples costs with operating results and capacities to illuminate operating results and conditions. A basic principle of ABC/M is that cost should follow cause and effect relationships. This seems natural and logical to nonfinancial professionals. They often ask, “Isn’t that the way it is done?” Unfortunately, no. The reasons lie in the historical evolution of cost analysis and its supporting technology. Before the Industrial Revolution, products and operations were typically very simple and labor intensive. Overhead was minimal and much of it supported labor operations anyway. Without computers, all computations were manual, simplistic by necessity, and kept to a minimum. Though adequate for earlier, simpler environments, the habits established for this environment persisted far too long. As business operations, products, and services became more complex, external reporting requirements grew. Unfortunately, as these requirements gained significance in the economic climate of an era newly focused on external reporting, most internal cost analysis remained unchanged despite the growth in complexity of the products and services being offered. Because competition was minimal, plenty of room remained to manage by gut feel. As a result, internal cost analysis did not keep pace and largely retained the same techniques from simpler days. These techniques did not keep pace with the Industrial Revolution much less the IT revolution. However, using the methods and tools of ABC/M that were developed to bridge this gap in accounting evolution, enterprises can reestablish cause and effect as a governing principle in cost analysis. Following cause and effect is especially critical with shared resources— those not dedicated to a particular service. Costing for dedicated resources is easy but limited because few resources can be dedicated to a single task. Shared resources (nearly all people and many components) require application of sound cause-and-effect costing principles. A second ABC/M principle is to look at the work being performed as the intermediary step between resources consumed and products produced. This work is captured as activities performed by people and/or equipment. Activity

158

chapter 4

the sum of it can be greater than its parts

analysis is a vital bridging step that serves two primary purposes. First, it enables a step-wise analysis between resources and products/services. Without the intermediary activity analysis, it is often very difficult to understand how products and services consume resources. Activities provide this missing link. Second, it provides a vital link and view to the complex processes employed to produce or deliver products or services. Process analysis is not complete without understanding the cost of the process and its components. Within ABC/M, cost driver analysis seeks to capture and understand the root causes of activities at two levels. The first level seeks to understand why the activity is performed in the first place. Perhaps it should not be done at all, or perhaps there should be more. Assuming that the work must be performed, the second level seeks to understand the negative root causes of performance in terms of cost, quality, or cycle time. Why is cost higher than expected? Why is quality lower than desired? Why is cycle time too long? Linking cost with a root cause analysis enables process improvements to be focused on those issues that have the highest importance and the greatest overall impact on performance improvement. Correspondingly, people spend less time on issues that carry minimal cost and other performance impacts. It’s important to understand the semantic components of activity-based accounting systems. Activity-Based Cost (ABC) focuses on the flow of costs from resources through activities and subsequently from activities to products, services, and customers. See Appendix 6.A in Chapter 6 for a more detailed summary of how ABC’s cost reassignment networks achieve a cause-and-effect picture of enterprise costs. Activity-Based Management (ABM) focuses on the performance aspects of activities, their cost drivers, performance measures, and process contexts. ABC and ABM are best used together as Activity-Based Cost Management (ABC/M).

deploying abc/m for it finance An IT ABC analysis starts by identifying the resources deployed in the IT organizations. Typically, these are recorded in the GL for each IT department—usually the only relationship between ABC and the GL. The SAS ABC model begins with GL costs by department and by account as its first view, retaining the original GL view to provide a firm common starting

deploying abc/m for it finance

159

point and for correlation with external financial reporting. However, it then also provides another parallel view of resources that better reflects operational requirements and realities. Regrettably, the GL’s level of data detail is both greater and lesser than the optimum set required for ABC depending on the resource and account structure. Where there is too much detail, such as accounts required for tax reporting, these details can be aggregated. Where there is too little detail, such as for asset depreciation, a well-designed ABC model uses its capabilities to split these costs to a more appropriate and useful level to support decision making. The reorganization is accomplished in the transition between the GL view and the new operations view. This operationally focused view reorganizes resources and their costs to align them with operational resources—it captures resources in terms of teams of people, types of equipment, and other more operationally natural categories. This operational view is designed for use and easy understanding by operating personnel. At the same time all costs are easily traced and reconciled to traditional financial views providing a robust and comprehensive resource view that is also verifiable. This view provides IT managers with a view of what the resources they deploy actually cost in terms that they easily understand and use. This view is also the foundation for subsequent views of activities and services. The overall model cost flow and management views are shown in Exhibit 4.5. IT components are tracked separately because they constitute a significant cost and play an essential part of IT business symphonies. For these components, the cost recorded in the GL is usually aggregated to a level not useful to operating management or for a symphonic view. For this reason, component information is obtained from asset registers or other sources to identify the current costs of components at a sufficiently granular level to support service-level agreements and Capacity Forecasting models. After establishing an operational view of resources, the next step is to assign these costs to the work that these people do. This model uses existing ITIL process definitions as activity definitions. Using the ITIL process definitions provides a sound, common basis for measuring predictable, repeatable IT processes. ITIL processes are a necessary component in IT’s maturity process. Without them, it would be difficult to attain a proactive, service-oriented, value-driven IT organization. Resources are traced department by department to the ITIL processes representing the work

160

Accounting View

Operations View

Process View

Accounting GL

People-Based Resources

ITIL Processes

Components

Standard Service View

SLA & other Services

Standard Services

Department A Department … Department N EXHIBIT

4.5

Services View

ABC Model Views Customized to Dif ferent Analyses

Customer View

Customers

deploying abc/m for it finance

161

that the respective people performed. At this level of detail within the departments, this work is considered activities. Later costs are easily reported at the organization-wide ITIL process level using reporting tools. After these costs have been assigned, the costs of ITIL processes become available. Because the ITIL costs are tied to the operations resource and financial resource views, people can observe more powerful relationship costs with breakdowns by department and by types of resources either by the operational view or the financial view of cost. Why continue to trace costs by department rather than by process? Why not the best of both worlds—have our cake and eat it too? Retaining a departmental view retains the department’s responsibility for costs—now in the operationally focused activities. Departments are necessary for control and accountability, and each manager has the responsibility and opportunity to manage their activities. At the same time, having used common ITIL processes as activity definitions, a process owner or team has the beginning-to-end view of the process regardless of the department. They can also drill down into the organizational components when necessary. This modeling style overcomes the departmental budget view of IT and retains accountability while providing an efficient cost analysis. The objective of the next step in ABC/M deployment enables tracing costs to products/services provided by IT. What is the difference between a product and a service? Not much—sometimes the difference is a question of tangibility. Especially for an organization that has both physical and nonphysical outputs, this distinction may be useful. For organizations that have only intangible outputs, the difference is so trivial that the terms are interchangeable. Following the Top-Down value strategy, service-level agreements contain the value definition for business applications as well as service-level requirements. In addition to documented SLAs, there may be more general standard services offered as a cost savings or legacy services not yet formally documented with customers. Even without formal documentation, IT should be ascertaining cost and service performance for internal management purposes. ABC methodology requires a cause-and-effect tracing of costs. Consumption metrics often provide the best basis for this assignment. Standard services may also be traced to specific services where they are used as components of a broader service offering.

162

chapter 4

the sum of it can be greater than its parts

At this point, cost analysis of services becomes available for service cost trend and service unit cost trend. With the relationships to ITIL processes, components, and people resources already established, these services can be analyzed by ITIL process and/or the resources consumed. Conversely, resources can be analyzed in terms of the services that ultimately consume them. In the final step of ABC/M deployment, services are assigned to customers based on the consumption metrics of their usage. Cost metrics are now available by customer. As these are added to the relationships already calculated in the model, a rich analysis base becomes available to help understand the operations and to be related to operating results. Because the symphonies that IT plays are business applications covered by SLAs, the results can be used for both value reporting to customers and also for internal IT optimization. With the operational view defined, relationships established, and costs measured, the model now provides a rich source to illuminate operating results. Activities provide the essential step between resources and services provided. Understanding activities and their drivers provides actionable information. Modeling the entire organization provides a comprehensive analysis basis and avoids non-repeatable, non-verifiable ad hoc analyses. Exhibit 4.6 provides a summary of the model elements, interrelationships, and samples of the questions to be asked. Along the diagonal, the sample questions center on the model element itself, its profitability, and its cost to facilitate evaluation of other operating results. Away from the diagonal, the questions concern relationships between model elements that can be analyzed from either side of the relationship. For example, in the intersection of the Customer row and the Customer column, the questions center on the cost or profit of the customer itself. Further questions may deal with the relative contribution from or cost of each customer. Similarly, in the intersection of the ITIL Process row and the ITIL Process column, the questions center on the cost and performance of the individual process. Further questions may deal with the relative mix of ITIL processes. Although these two sets of questions and their answers provide valuable insight and input to business decisions, the relationship between these two elements provides even more insight. This relationship is in the intersection of the Customer column and the ITIL Process row. Now the questions center on the relationship between the ITIL

163 EXHIBIT

4.6

Management Decisions Involve Relationships between Elements of the Operation

164

chapter 4

the sum of it can be greater than its parts

process and the customer from either side of the relationship such as “How does this process support our customers?” and “Is each customer receiving appropriate value from this process?” Other row and column combinations provide additional perspectives. Data Sources ABC/M modeling requires data from several sources. One source is the General Ledger, but operational data is more important to the ABC/M model for defining and refining the financial results of the underlying operations. Asset registers may be needed to break summarized financial information down to the actual component level. Measures of how people spend their time serve to apportion their cost when they work in multiple processes. These measures do not need to be extensive—only sufficient to provide management decision-grade information. If customer billing is performed, it becomes the source for revenue versus cost analysis. If not, then a revenue surrogate assists the decisionmaking process. System consumption metrics serve to meter ITIL process, component costs, and standard services to the services that consume them. Using the same consumption metrics for costing helps assure an accurate and relevant financial view of operating conditions.

decision information The illumination of IT operations with cost results is only valuable when the information is used in decision making. At times, financial information can play a solo. Other times, financial information is joined with other IT sections to produce a broader perspective. This section discusses several types of reports that highlight not only the types of reports or analyses that could be generated with ABC/M information but also some of the questions or insights that come from each analysis. Most analyses take either tabular or graphical form. Tabular formats are most useful when the actual amounts are significant to decision making. Graphical formats are most useful when looking for significant changes in trends or when comparing/contrasting different categories or time periods. Modern OLAP Business Intelligence tools include both formats and the ability to drill into supporting details.

decision information

165

The art of Business Intelligence tools is to apply the analysis, forecasting, and graphics to the strategic vision of the enterprise. Recall that earlier in the chapter the role of IT Finance within the Strategic Performance Management scorecards was defined within two strategic prongs (Exhibit 4.1). In the first part of the strategy, IT engineers the long-term maturity of its internal processes to gain stability, move to a proactive stance, define and provide services, and align with the rest of the business to define and provide value. In the second part, IT defines value immediately with new business applications. As a result of that strategy, IT Finance tracks both new, welldocumented SLAs and also “legacy” SLAs that have not been well documented. The new SLAs are compared to business cases and the legacy SLAs generate a baseline of performance and cost for future decision making. Let’s begin by first focusing on the Top-Down SLAs, stepping through the results from an overview level and then examine people costs as expressed in ITIL processes and end with infrastructure costs. This section concludes by pairing the results with the pertinent operational measures. Service-level agreements are the nucleus of the Top-Down prong and become the primary focus of strategic IT Finance as illustrated in Exhibit 4.7, which examines the trended cost of services for Marketing Automation, a customer-facing formal SLA. SLAs capture the value of the service for the business, the requirements of the service, and anticipated growth. SLAs may also cover several sub-agreements. CIOs and their IT organizations use this configuration of SLAs to negotiate and measure large, complex business applications. The value here lies in identifying costs that have changed and in comparing two separate services (rows) or time periods (columns). In this example, the user drilled down into the Marketing Automation Service to see information about SLAs covering Marketing Automation departmental modules. If this information is also presented on a per-unit of output basis, some differences may be magnified while others are diminished. If two items have equivalent cost but significantly different output volumes, a per-unit analysis would dramatically show the change. On the other hand, if a cost has increased but proportionally to the output volume, then the unit cost would be stable. One of the main cost analysis tools provided by the ABC cost model is an analysis of the cost of a service as shown in Exhibit 4.8. Traditional cost

166

SLA Cost by Month 2005 Jan Documented SLAs

2005 Feb

2005 Mar

2005 Apr

2005 May

2005 Jun

2005 2005 Jul Aug

2005 Sep

2005 Oct

2005 Nov

2005 Dec

3,686

3,651

3,611

3,600

3,656

3,642

3,647

3,666

3,635

3,578

3,683

3,678

1,047

1,039

1,023

1,020

1,037

1,027

1,033

1,038

1,028

1,013

1,043

1,039

180

178

173

170

176

172

176

176

173

169

177

175

Campaign ROI Assessment

70

69

67

67

68

67

68

68

68

66

69

68

Market Automation Planning

422

419

413

414

417

416

417

419

416

410

421

418

Marketing Automation Service (direct)

272

269

267

267

272

270

269

272

268

267

272

274

Target Marketing

105

104

102

102

103

102

103

103

103

100

104

103

SLA2

259

256

254

253

257

257

256

258

256

251

259

259

SLA3

318

315

311

311

315

314

314

316

314

309

318

317

SLA4

274

271

269

268

272

272

271

273

271

266

274

274

SLA5

333

330

326

326

330

329

330

331

329

323

333

332

SLA6

285

281

278

277

281

281

282

283

280

275

284

283

SLA7

277

274

272

271

275

275

275

276

274

269

277

278

SLA8

306

303

300

300

304

303

303

305

302

298

306

306

SLA9

281

278

276

275

279

279

278

280

278

273

281

282

SLA10

308

305

302

301

306

305

305

307

304

300

308

308

Marketing Automation Service Campaign Execution

EXHIBIT

4.7

Tr e n d e d S e r v i c e C o s t

decision information

167

Service Cost - Composition 2005 April Marketing Automation Service Total Sub Services Total ITIL Processes Total Components Grand Total

2006 May

1,090,521 245,903 33,406

1,066,903 250,995 54,823

1,369,830

1,372,721

2005 April

2006 May

Inc/Dec (23,618) 5,092 21,417

2,891

% Inc/Dec -2% 2% 64% 0%

Service Cost - Composition Marketing Automation Service Sub Services Target Marketing Market Automation Planning Campaign ROI Assessment Campaign Execution Total Sub Services ITIL Processes Total IT Strategic Processes Total IT Service Delivery Total IT Service Support IT Operations Support Total System Management Total Network Management Operation Management Infrastucture Mainframe Operations Distributed Systems Total Operation Management Total Database Management Total Security Management Total IT Operations Support Total Other Total ITIL Processes Components Total Hardware Software Total Mainframe Software Total System Management Software Total BI Foundation Server Total Software (general) Total SAS Management Console Total WebDAV Total BI Foundation Server Total Software Total Components Grand Total

Inc/Dec

% Inc/Dec

142,681 579,188 128,384 240,267 1,090,521

146,887 564,210 146,125 209,681 1,066,903

4,206 (14,978) 17,741 (30,586) (23,618)

3% -3% 14% -13% -2%

10,977 42,187 80,610

10,843 43,566 81,464

(134) 1,379 854

-1% 3% 1%

2,658 6,519

2,688 7,078

30 559

1% 9%

26,365 4,236 28,894 59,495 528 14,704 83,904 28,225 245,903

25,937 4,270 31,684 61,891 532 14,930 87,119 28,003 250,995

(428) 34 2,790 2,396 4 226 3,215 (222) 5,092

-2% 1% 10% 4% 1% 2% 4% -1% 2%

24,184

35,111

10,927

45%

1,184 375 1,628 1,911 1,822 1,731 571 9,222 33,406

546 841 11,833 1,379 2,519 1,981 613 19,712 54,823

(638) 466 10,205 (532) 697 250 42 10,490 21,417

1,369,830

1,372,721

-54% 124% 627% -28% 38% 14% 7% 114% 64% 0%

2,891

4.8 The Cost Model Provides Interesting Details of the Cost of a Service EXHIBIT

tools would only show “Direct costs” and “Allocated Overhead” with allocations based on direct cost, labor hours, or other potentially arbitrary measure. A properly developed ABC model has summary-level analysis for high-level views as well as the ability to drill down into the composition of the cost as necessary. The composition analysis includes operating activities, processes, and/or components coupled with their cost. One

168

chapter 4

the sum of it can be greater than its parts

typical management question is: “What does this service cost?” usually followed by • “Why does this service cost what it does?” • “What makes up that big item?” • “What did it cost last month?” and • “What can we do about it?” and • “What and how much value does it generate?” An alternate analysis of the relative magnitude of cost coming from the sub-agreements of the Marketing Automation SLA is shown in Exhibit 4.9. In addition to the magnitude, this interactive analysis shows a variance from target versus actual as a color gradation (shades of gray in this book). To explore further into a section, the analysis tool enables additional drill downs into the components. The prime question is whether the mix of cost is appropriate for the value generated or where the greater variance from target occurs. The analysis in Exhibit 4.10 examines the trended cost of major ITIL processes across all departments. The value here is in identifying what has changed or in comparing two separate services (rows) or time periods (columns). In this case, the question is why IT Service Support cost has increased and why IT Strategic Processes has decreased, especially if this is contrary to current strategy. This cost trend of ITIL processes is complemented by an analysis of the relative magnitude of cost resulting from resources consumed in ITIL processes as shown in Exhibit 4.11. In addition to cost, this analysis shows a variance from target in its color gradation. A further drill down into ITIL Strategic Processes in show in Exhibit 4.12. The analysis of ITIL processes by SLA shown in Exhibit 4.13 examines the contribution of ITIL processes to the various SLAs, and correspondingly, the consumption of ITIL processes by SLAs. In IT organizations, people costs typically constitute the lion’s share of operating expenses. As IT sets its strategy, ITIL should play a major role to move the organization from isolated functions to an integrated unit where all IT sections harmoniously play their parts the strategic symphony. Because SLAs are IT’s business perspective, investigate the makeup of ITIL costs for the SLAs in Exhibit 4.13. Are they appropriate? As IT matures, CIOs should see a

169

EXHIBIT

4.9

Relative Magnitude of Service Cost

K$ 170

2,000 1,800 1,600

IT Service Support

1,400 1,200 1,000

IT Operations Support

800 600

IT Service Delivery

400 IT Strategic Processes

200 0

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec EXHIBIT

4.10

I T I L P r o c e s s C o s t Tr e n d

171

EXHIBIT

4.11

I T I L P r o c e s s C o s t — R e l a t i v e M a g n i t u d e a n d Va r i a n c e o f To p - L e v e l P r o c e s s e s

172 EXHIBIT

Processes

4.12

I T I L P r o c e s s C o s t — R e l a t i v e M a g n i t u d e a n d Va r i a n c e o f I T S t r a t e g i c

IT IL Pro c esses b y SL A 2 0 0 5 Q 3 ( 0 0 0 ' s) Do c um ent ed SLA s Mar k et ing A ut o m at io n Ser v ic e Mar k et A uto m at io n Plan n in g

Cam p aig n Cam p aig n RO I Exec u t io n A sse ssm e n t

SL A 1 0 SLA 2

Mar k et in g A ut o m at io n S e r v ic e ( d ir e c t )

SLA 3 SLA 4

SLA 5

SLA 6

SLA 7

SLA 8 SLA 9

Tar g et Mar k e t i n g

IT Op er at io ns Sup p o r t

2, 716

543

60

20

184

259

20

244

258

237

239

237

237

238

244

IT Ser v ic e Deliv er y

1, 0 4 3

188

2

1

57

128

1

117

85

84

82

10 2

101

105

96

82

IT Ser v ic e Sup p o r t

3,0 31

1, 038

248

83

384

24 2

83

242

19 7

220

21 2

24 2

219

211

229

221

Chang e Manag em ent

657

207

46

15

80

51

15

50

50

51

50

50

50

50

51

50

Co nf ig ur at io n Manag em ent

207

48

4

1

17

24

1

15

24

15

15

15

15

15

24

24 30

239

Inc id ent Manag em ent

899

475

166

55

172

27

55

61

30

61

30

61

61

30

61

Pr o b lem Manag em ent

762

206

32

11

75

78

11

78

54

54

54

78

54

78

54

54

Release Manag em ent

506

103

39

63

39

39

39

63

39

39

39

39

63

477

79

1

10,300 2 , 8 8 7

558

IT St r at eg ic Pr o c esses Sub to tal

EXHIBIT

4.13

18 6

45

33

1, 0 53

904

ITIL Processes by SL A (Ser vice)

18 6

41

41

55

41

41

41

41

55

41

887

77 9

815

786

865

817

807

853

805

173

174

chapter 4

the sum of it can be greater than its parts

decrease in the “front line” ITIL support processes of Incident and Problem Management as they increase service processes. What adjustments should IT make in process management? From the process perspective, the ITIL analysis shows the ITIL processes that various SLAs consume—helping CIOs and IT employees evaluate their appropriateness, especially in conjunction with other nonfinancial performance measures. From the SLA perspective, investigate the makeup of the SLA. Is it appropriate? What adjustments should be made in process management? From the process perspective, one sees the proportion that the various SLAs consume which ITIL processes and evaluate their appropriateness. Using the information provided in Exhibit 4.14, IT management could communicate with their customers about the component cost of the services they consume. Conversely, IT management could evaluate how components are deployed in support of services. Are there opportunities to redeploy some components to achieve a better balance of service metrics and cost? Analyzing ITIL Processes by Department, Exhibit 4.15 examines if departmental resources are being directed toward the processes that the CIO expects them to perform. The analysis departs from the cross-functional focus to include a responsibility focus. Each department has a manager who is responsible for the resources deployed in that department. Knowing and analyzing how the department deploys its resources gives the manager the ability to act within the department while also acting properly in the overall cross-functional context. From a higher level and across all departments, are certain departments spending too much of their resources fixing shortterm problems and not enough ensuring process stability from the outset?

understanding capacity Capacity drives cost, but capacity is lumpy. One usually cannot purchase 30 percent of a computer or hire 65 percent of an employee. Companies commonly buy a server but use just a fraction of its capacity. Acquisition or hiring decisions incur or commit the majority of a resource’s cost regardless of how it is actually used. Other than subsequent operating costs, the cost has been determined and continues until the computer is disposed of or the employee leaves. External customers understand and are willing to pay for the capacity that they actually use or have reserved. However, they

Co m p o nent Usag e b y Ser v ic e ( 0 0 0 ' s) SL A 1 0

M ar k et ing A ut o m at io n Ser v ic e Mar ket A u to mat io n Pl an n i n g

Camp aig n Camp aig n Exec ut io n

RO I A ssessm ent

Mar k eting A u to ma t io n Service ( d ir e c t )

SL A 2

SL A 3

SL A 4

SL A 5

SL A 6

SL A 7

SL A 8

SL A 9

Total

Tar g et Mar k eting

Hardw are

3, 3 2 2

614

399

1, 4 2 3

67

820

377

377

798

479

922

640

377

716

580

8, 5 8 9

So f t w ar e

1, 0 0 6

240

3

572

188

3

369

37

260

146

208

9

200

89

92

2, 4 1 5

139

0

0

0

139

0

139

0

139

0

139

0

139

0

0

696

Call Center A p p lic at io n

16

16

0

0

0

0

16

16

16

16

16

0

0

16

0

114

BI Fo und atio n Ser v er Call Center Data So ur c e

34

0

0

34

0

0

34

0

0

0

0

0

34

0

0

103

Camp aig n Stu d io

96

0

0

96

0

0

0

0

0

0

0

0

0

0

0

96

Camp aig n Web Ser v er

22

11

0

11

0

0

0

0

0

0

0

0

0

0

0

22

Custo m er Dem o g r ap hic Data So ur c e

43

0

0

43

0

0

43

0

0

0

43

0

0

43

0

174

Custo m er Ser v ic e Data So ur c e

112

56

0

56

0

0

0

0

56

0

0

0

0

0

56

223

Custo m er Tr ansac tio n Data So ur c e

219

109

0

109

0

0

109

0

0

109

0

0

0

0

0

437

Dataw ar eho use R D M S

27

0

0

27

0

0

0

0

27

0

0

0

0

0

27

82

Enter pr ise Miner

51

0

0

51

0

0

0

0

0

0

0

0

0

0

0

51

E T L Stu d io

34

0

0

34

0

0

0

0

0

0

0

0

0

0

0

34

In f or m at io n Map Stu d io

53

0

0

53

0

0

0

0

0

0

0

0

0

0

0

53

Mainfr am e So f t w ar e

12

0

0

0

12

0

0

12

0

0

0

0

0

12

0

37

SA S Camp aig n Web Stu d io

76

38

0

38

0

0

0

0

0

0

0

0

0

0

0

76

SA S Manag em ent Co nso le

14

0

0

0

14

0

14

0

0

0

0

0

14

0

0

43

SA S Ser v er

25

10

3

10

0

3

3

0

0

3

0

0

3

0

0

35

So f t w ar e ( d ir ec t )

15

0

0

8

8

0

8

8

8

8

8

8

8

8

8

83

Sy stem Manag em ent So f t w ar e

7

0

0

1

6

0

1

1

6

1

1

1

1

1

1

22

WebDA V

9

0

0

0

9

0

0

0

9

9

0

0

0

9

0

34

4,3 2 8

855

402

1,9 9 5

254

823

Total

EXHIBIT

4.14

Component Usage by Ser vice

7 4 6 4 1 5 1,0 5 9 6 2 5 1,1 3 0

649 577 805

6 7 2 1 1,0 0 5

175

176

ITIL Processes by Department

Application and Development

2005 Q2 (000's)

IT Service Delivery

IT Operations Support

IT Strategic Processes

IT Service Support Change Management

Configuration Management

Incident Management

Problem Management

Release Management

0

202

2,145

569

238

0

629

709

349

Business Integration

0

144

0

0

0

0

0

0

268

Distributed Development

0

40

1,438

378

0

0

410

650

45

Implementation

0

0

687

191

238

0

199

59

0

0 1,416

18 0

20 0

0 0

0 0

0 0

20 0

0 0

36 0

Infrastructure Support

0

8

581

0

0

581

0

0

16

Office of the CIO

0

0

0

0

0

0

0

0

284

System Management and Operations

2,181

1,307

1,419

324

91

372

481

151

469

Total

3,597

1,517

4,145

893

330

953

1,110

860

1,118

Mainframe Development Facilities Administration

EXHIBIT

4.15

ITIL Processes by Depar tment

understanding capacity

177

are not willing to pay for additional capacity that was purchased in anticipation of growth or becomes idle due to demand changes.2 Why should internal customers behave any differently? They too are willing to pay for what they use but are not willing to pay for what they don’t use. However, many IT organizations implicitly and actually require their internal customers to pay for idle capacity due to their cost allocation policies. Capacity analysis integrated with ABC costing methodologies serves to identify capacity cost issues and provides insight for these kinds of management decisions. The first step in establishing an integrated capacity analysis quantitatively identifies how capacity is used or not used. The three major capacity categories are productive, non-productive, and idle. The total capacity is time, seven days a week/24 hours a day. Aside from some Star Trek type of disruption of the space-time continuum, this is fixed. External requirements, the policies, contracts, maintenance requirements, and actual usage all serve to define how capacity is allocated to these categories and their substates or subcategories. Subcategories within each major category serve to further refine the analysis. These can be further subdivided as necessary for specific operating environments (see Exhibit 4.16). Idle capacity includes capacity that is off limits due to regulatory, contractual, or policy restrictions. Another subcategory includes capacity that is not usable—perhaps due to obsolescence. The last subcategory includes capacity that is idle but potentially usable. Productive capacity is capacity actually used for its intended purpose or for product or process development. Non-productive capacity includes all other capacity such as capacity used for maintenance, training, setup, and rework to name a few. Planned or unplanned outages would likely fall into one of these capacity states such as maintenance. Non-productive capacity also includes one other subcategory that is especially important in IT environments. This is buffer capacity or capacity that while not used, is required to accommodate peak requirements, process balancing, or reserved for specific customers. After building a time-based model of capacity, it is easily translated to other measures such as equivalent units. Other measures retain the same definitions. Retaining the same definitions enables easy communication between measure usages of the model. Another important measure is cost. Using the same time-based model, cost is traced to the states appropriate for that type of cost. For example,

178 Rated Capacity

chapter 4

the sum of it can be greater than its parts

Summary Model

Industry-Specific Model Not Marketable

Strategy-Specific Model Excess Not Usable Management Policy

Idle

Off Limits

Contractual Legal

Marketable

Idle But Usable Process Balance

Standby

Variability Scrap Rework

Waste

Yield Loss

Nonproductive Maintenance Rated Capacity

Scheduled Unscheduled Time

Setups

Volume Change-Over

Process Development

Productive

Product Development

Good Products

EXHIBIT

4.16

A Basic Time-based Capacity Model—

Source: CAM-I

depreciation or equipment rental applies to all capacity states whether idle, productive, or non-productive. Maintenance costs would be applied to the maintenance subcategory. The end result is a cost map overlay using the same category and subcategory definitions. The cost map is another tool that provides information for management decisions. CIOs and IT organizations can use this cost information to determine the cost to provide services to customers. They can easily trace productive capacity to services and customers. They can also easily trace most of nonproductive capacity. Even buffer capacity cost is easily traced because it is dedicated to specific services and/or customers.

understanding capacity

179

Some portion of idle capacity cost is a cost to provide services while the remainder should not be assigned to services and customers. Only offlimits capacity cost should be considered a cost to provide capacity for services and customers. This is proper because otherwise, the capacity could not be provided at all. Capacity that is not usable due to obsolescence or that is otherwise usable for other services and customers is not a cost properly attributable to current services and customers. Yet many IT internal organizations expect their internal customers to pay for this capacity. External IT organizations cannot charge their customers because their pricing is based on market conditions and not on their cost to serve. Where significant idle capacity is present, the cost differences can be significant. Without proper understanding and treatment of these costs, management decisions will be misguided. In the worst alternative, CIOs ignorantly continue to believe inflated service costs and make decisions on that basis. Alternatively, proper understanding of idle capacity cost gives management an opportunity to know the real cost to provide services to their customer and then to find value-adding uses for any idle capacity. Exhibit 4.17 summarizes capacity costing where each customer (A–E) uses capacity and has certain amounts of capacity reserved. In addition, IT maintains a certain amount of capacity to provide required services at peak usage times. This buffer benefits all of these customers. However, the remaining idle capacity does not support or benefit any customer. Its cost should not be assigned to any of them. Instead, it is an overhead cost of the IT organization. Exhibit 4.18 depicts a more advanced capacity consideration found in a commercial bank. In this case, service “A” requires a significant amount of additional capacity, and the month-end processing was a significant consideration in their purchase of a mainframe computer. The capacity requirement was to have enough power to process all month-end requirements between closing time on the 31st of the month and opening time the next day. This requirement was the basis for purchasing a larger and more expensive machine and supporting infrastructure. In this case, management recommended the creation of two capacity models. The first capacity model considered the applications and services that required peak month-end processing. Capacity was assigned to the various categories according to usage during the peak. The cost assigned to this

Assign to Consumers

180

Common Buffer

Reserved or Minimum

Actual

e Capacity Idle

A EXHIBIT

B 4.17

C

D

Assign to IT Overhead

Assign to Consumers

E

A Basic Capacity Model Showing Customer Capacity Usage

Assign to Customer “A”

Peak Buffer Driven by “A” Common Buffer

Idle Capacity

181

A

EXHIBIT

B

4.18

C

D

E

Reserved or Minimum

Actual

Assign to IT Overhead

Assign to Consumers

A n A d v a n c e d C a p a c i t y M o d e l S e p a r a t e s t h e I m p a c t o f Pe a k C a p a c i t y D e c i s i o n s

182

chapter 4

the sum of it can be greater than its parts

capacity model and its capacity states was the incremental cost of the larger computer and its support over the cost had it been sized only for non-peak requirements. The second capacity model considered all applications and services during normal operations. Capacity was assigned to these categories according to non-peak usage. The cost for this model was reduced by the cost assigned to the peak model. This model resulted in a good understanding of the consequences of the peak requirements as well as a good understanding of the real cost of off-peak processing. With these insights, off-peak applications no longer received the peak cost and were evaluated on their own merits.

conclusion IT can be greater than the sum of its parts. Overcoming the historic practice of managing by domain and technology expertise calls for new strategies, new approaches, and a new role for IT Financial management. The dated domain and technology approach to management leaves each of the domains operating in isolation: not only from each other but from IT’s management and IT’s business customers. To compound the situation, the isolation approach to IT management hides the fact that IT has key management sections missing—even from the CIO. Strategy overcomes the mixed management message delivered by the industry’s mindshaper community. One camp advises a Bottom-Up, operational concentric process maturity index that delivers business value at the end of the maturity process. Another camp advises IT to deliver business first and immediately. Rather than choose one approach over the other, SAS advocates a two-prong strategy that delivers maturity and value simultaneously. IT Finance plays a crucial role in both prongs of the strategy. From a financial perspective, the immediate business value strategy prong follows capital expenditures for new business applications while the maturity strategy prong concentrates on the expense portion of IT. For IT Finance to deliver upon this new role, new approaches are necessary. For both strategy prongs a new approach to Service Level Cost Management is needed. Equally important, IT Finance needs to overcome the traditional shortcomings of General Ledger–based accounting and budgeting in favor of service-based financial outcomes.

notes

183

Strategy guides IT financial management to overcome the various IT sections and practices trapped in isolation and identify what is important to measure. Strategy also suggests that IT financial management implement Activity-Based Costing/Management to surface and analyze important IT service outcomes. This chapter focused on several service areas that deserve illumination: Cost of Service, Cost of ITIL, Cost of Capacity, and combinations of all three areas. Each of the cost measurements are important in their own right, but to overcome the isolation syndrome and play the strategic business symphonies, cost results must be paired with service outcomes. When IT reports what service was delivered, how well the service was performed, and what the service cost, then IT can play in harmony rather than in isolation.

■ notes 1. Gartner, Inc. Publication Date: 4 April 2006/ID G00138514. 2. Capacity Measurement and Management, Thomas Klammar, editor (New York: McGraw-Hill, 1996).

chapter

5

IT Performance Management Using the Balanced Scorecard by paul r. niven

chapter roadmap Statistics chronicling high-profile IT project failures abound in the literature and the press with some pundits suggesting that upwards of 66 percent of all IT initiatives prove unsuccessful in some measure. Although not all technology endeavors are outright failures of course, many exceed the predefined budget, lag woefully behind schedule, or are eventually rolled out with far fewer functions and features than originally suggested.1 Histrionics and assaulting headlines aside, the stakes are incredibly high in this game as organizations spend billions of dollars on technology projects promising greater efficiency, business insights, and strategic effectiveness, all prerequisites to performing with any degree of success on today’s global stage. Although myriad reasons exist for IT project problems, a key contributor to the quagmire of murky results CIOs often find themselves trudging reluctantly through is a lack of alignment between the organization’s strategy and the portfolio of initiatives pursued by IT departments struggling to keep up with user demands as discussed in the first three chapters. Information capital, the domain of the CIO, and a vital raw material to organizational success in the so-called “new economy” is only valuable in the context of strategy, and thus IT spending must align with the 185

186

chapter 5

it performance management

organization’s stated strategic direction.2 Should, for example, a company be pursuing a strategy of customer intimacy, attempting to create longterm bonds with its clientele by offering total solutions and unmatched customer service, its IT projects must be consistent with this overall direction if it hopes to derive value from its efforts. Investing heavily in customer relationship management (CRM) software would make strategic sense in this context because the resulting data may yield numerous insights to be used in fostering stronger bonds with current customers and attracting new shoppers to the company’s value proposition (see Chapter 6). Conversely, an expensive and technologically challenging investment in software and systems to promote quality may deliver incremental improvements, but will eventually prove to be inconsistent with the company’s customer intimacy strategy and lead to questionable longterm benefits, ultimately driving the wedge between IT and executive and line staff deeper. To overcome this challenge, many IT groups are discovering the power of performance management, and particularly the Balanced Scorecard concept, as a means of demonstrating IT’s alignment with overall firm strategy and clearly communicating the value of information technology in delivering the company’s value proposition to all stakeholders, including customers, employees, boards, and regulators alike. These tools help IT organizations critically evaluate and ultimately execute their own strategies, ensuring they line up with corporate direction as discussed in Chapters 1 and 2 through the use of objectives and measures that can be tracked over time. This provides quick and valuable feedback that allows IT leaders to make necessary course corrections in their pursuit of alignment with corporate strategy. The pages ahead introduce the Balanced Scorecard system and describe how to use this powerful tool to drive efficiency, effectiveness, and strategic alignment throughout your IT organization. The chapter begins with a discussion of what has led to the prominence of the Balanced Scorecard and then describes the fundamentals of the system itself and a concise step-by-step guide of how to build a Balanced Scorecard for the IT organization. The chapter concludes with a case study of one IT group that effectively harnessed the Balanced Scorecard with a presentation of how they did it, what results they achieved, and the challenges they encountered along the way.

the balanced scorecard’s rise to prominence

187

the balanced scorecard’s rise to prominence: solving three fundamental it challenges Born from a research study conducted in 1990, the Balanced Scorecard has since become a critical business tool for thousands of organizations around the globe. In fact, recent estimates suggest a whopping 60 percent of the Fortune 1000 has a Balanced Scorecard in place.3 Further evidence of the ubiquity of the Balanced Scorecard is provided by The Hackett Group, which discovered in 2002 that 96 percent of the nearly 2,000 global companies it surveyed had either implemented or planned to implement the tool.4 Before discussing the structure of the Balanced Scorecard, let’s examine its origins and attempt to determine just why it has become such a universally accepted methodology. Three fundamental factors affect every organization, at times in gamechanging ways: (1) a reliance on financial measures of performance to gauge success, (2) the rise of value-creating intangible assets, and (3) the difficulty of executing strategy, all of which impact today’s IT departments. While separate and distinct factors, the trio is bound together by the inspiring ability of the Balanced Scorecard to overcome and maximize them to their fullest potential. Financial Measurement and its Limitations As long as business organizations have existed, the traditional method of measurement has been financial. Bookkeeping records used to facilitate financial transactions can literally be traced back thousands of years. At the turn of the twentieth century financial measurement innovations were critical to the success of the early industrial giants like General Motors. That should not come as a surprise because the financial metrics of the time were the perfect complement to the machine-like nature of the corporate entities and management philosophy of the day. Competition was ruled by scope and economies of scale with financial measures providing the yardsticks of success. In the twenty-first century, however, many are questioning our almost exclusive reliance on financial measures of performance. Perhaps these measures are better served as a means of reporting on the stewardship of

188

chapter 5

it performance management

funds entrusted to management’s care rather than charting the future direction of the organization. And as everyone knows, stewardship is an increasingly vital issue in light of the many corporate scandals witnessed over the past several years, and the surge of shareholder value and job losses left in their wake. Here are some of the criticisms levied against the overabundant use of financial measures: • Not consistent with today’s business realities. Today’s organizational valuecreating activities are not captured in the tangible, fixed assets of the firm. Instead, value rests in the ideas of people scattered throughout the firm, in customer and supplier relationships, in databases of key information supplied by IT, and cultures capable of innovation and quality. Traditional financial measures were designed to compare previous periods based on internal standards of performance. These metrics are of little assistance in providing early indications of customer, quality, or employee problems, or opportunities. The rise of intangible assets is discussed in the next section of this chapter and again in the final chapter of this book (see Chapter 8, p. 342). • Driving by rear view mirror. Financial measures provide an excellent review of past performance and events in the organization. They represent a coherent articulation and summary of activities of the firm in prior periods. However, this detailed financial view has no predictive power for the future. Experience shows that great financial results in one month, quarter, or even year are in no way indicative of future financial performance. Even so called “great” companies, those that once graced the covers of business magazines and were the envy of their peer groups, can fall victim to this unfortunate scenario. Witness the vaunted Fortune 500 list; two-thirds of the companies compiling the inaugural list in 1954 had either vanished or were no longer large enough to maintain their presence on the list’s 40th anniversary.5 • Tend to reinforce functional silos: Financial statements in organizations are normally prepared by functional area: individual department statements are prepared and rolled up into the business unit’s numbers, which are ultimately compiled as part of the overall organizational picture. This approach is inconsistent with today’s organization in which much of the work is cross-functional in nature. Today we see teams comprised of many functional areas coming together to solve pressing

the balanced scorecard’s rise to prominence

189

problems and create value in never imagined ways. Regardless of industry or type of organization, teamwork has emerged as a musthave characteristic of winning enterprises in today’s business environment. As an example, consider these three fields of endeavor: heart surgery, Wall Street research analysis, and basketball as played by the well-compensated superstars of the National Basketball Association (NBA). At first glance they appear to have absolutely nothing in common; however, studies reveal that success in all three is markedly improved through the use of teamwork: surgeon interactions with other medical professionals (anesthesiologists, nurses, and technicians) is the strongest indicator of patient success on the operating table. When it comes to Wall Street “stars” it is not the individual analysts and their erudite calculations that spell success, but the teaming of analyst and firm. Even in the NBA researchers have found that teams on which players stay together longer win more games.6 Our traditional financial measurement systems have no way to calculate the true value or cost of these relationships. • Sacrifice long-term thinking. Many change programs feature severe costcutting measures that may have a very positive impact on the organization’s short-term financial statements. However, these cost reduction efforts often target the long-term value-creating activities of the firm such as research and development, associate development, and customer relationship management. This focus on short-term gains at the expense of long-term value creation may lead to sub-optimization of the organization’s resources. Interestingly, an emerging body of evidence is beginning to suggest that cost-cutting interventions such as downsizing frequently fail to deliver the promised financial rewards and in fact sabotage value. University of Colorado Business School professor Wayne Cascio documented that downsizing not only hurts workers who are laid off, but destroys value in the long term. He found that, all else being equal, downsizing never improved profits or stock market returns.7 • Financial measures are not relevant to many levels of the organization. Financial reports by their very nature are abstractions. Abstraction in this context is defined as moving to another level leaving certain characteristics out. When we roll up financial statements throughout

190

chapter 5

it performance management

the organization that is exactly what we are doing—compiling information at a higher and higher level until it is almost unrecognizable and useless in the decision making of most managers and employees. Employees at all levels of the organization need performance data they can act on. This information must be imbued with relevance for their day-to-day activities. Given the limitations of financial measures, should we even consider saving a space for them in our Balanced Scorecard? With their inherent focus on short-term results, often at the expense of long-term valuecreating activities, are they relevant in today’s environment? I believe the answer is yes for a number of reasons. As the name implies, the Balanced Scorecard is just that: balanced. An undue focus on any particular area of measurement often leads to poor overall results. Precedents in the business world support this position. In the 1980s the focus was on productivity improvement, whereas in the 1990s quality became fashionable and seemingly essential to an organization’s success. In keeping with the principle of what gets measured gets done, many businesses saw tremendous improvements in productivity and quality. What they didn’t necessarily see was a corresponding improvement in financial results, and in fact some companies with the best quality in their industry failed to remain in business. Financial metrics will remain an important tool for organizations because they ultimately determine whether improvements in customer satisfaction, quality, innovation, and employee training are leading to improved financial performance, whether that is judged by cost containment (often used by support functions such as IT), revenue growth, or ultimately, shareholder value. The Rising Prominence of Intangible Assets What a difference fifty years can make. Writing in the Harvard Business Review back in 1957, Harvard professor Malcolm P. McNair had this to say about organizations paying excess attention to their people: “Too much emphasis on human relations encourages people to feel sorry for themselves, makes it easier for them to slough off responsibility, to find excuses for failure, to act like children.”8 Can you imagine the reaction business leaders would have to this quote if it were uttered today? What was your reaction? If you are like most you would probably completely disagree with

the balanced scorecard’s rise to prominence

191

McNair’s pessimistic view and instead assert the now prevailing notion that an organization’s people or its “human capital” represent the critical enabler in the new economy. Harvard Business Review editor Thomas Stewart captures the essence of this notion succinctly and powerfully when he says, “The most important of all are “soft” assets such as skills, capabilities, expertise, cultures, loyalties, and so on. These are the knowledge assets—intellectual capital—and they determine success or failure.”9 Consulting organizations offer a compelling example of creating value from intangible rather than physical assets. Consultants don’t rely heavily on tangible assets, instead they provide value for clients by drawing on relationships with subject matter experts throughout the firm and knowledge from past client experiences to provide innovative solutions. A client engagement I was involved with provides an example: the client encountered a problem loading data for their new performance measurement software. Automatic data interfaces for the software (pulling data directly from source systems throughout their locations) would have required significant human and financial resources to build, and this was not considered a viable option. The alternative of manual data entry was also deemed unacceptable because it would prove a time-consuming and non-value-added activity for system administrators. Our team was tasked with finding an innovative and cost-effective solution. We convened a team of experts on various subjects: the scorecard software program, the Balanced Scorecard methodology, desktop applications such as MS Access and MS Excel, and client data sources. The newly formed team brainstormed various approaches that would satisfy the criteria of cost efficiency and very limited manual data entry efforts. In the end we determined our best approach was to build a new data entry tool in Excel. Data owners would enter their individual data in the spreadsheet, and e-mail it to the system administrator who would then automatically upload the information into the software. The spreadsheets were custom designed to contain only those measures for which each owner was accountable. This solution ensured that both the innovative and costeffective criteria were satisfied. The new system cost very little to develop and implement and eliminated manual data entry for system administrators. It wasn’t the physical assets that led to this innovative solution to a client’s needs, but instead the skillful combination of an array of knowledge held by the individual team members.

192

chapter 5

it performance management

This kind of situation is happening in organizations around the globe in the transition from an economy based on physical assets to one almost fully dependent on intellectual assets. While this switch is evident to anyone working in today’s business world, it is also borne out by research findings of the Brookings Institute. Take a look at Exhibit 5.1, which illustrates the transition in value from tangible to intangible assets. Speaking on National Public Radio’s Morning Edition, Ms. Margaret Blair of the Brookings Institute suggests that tangible assets have continued to tumble in value: If you just look at the physical assets of the companies, the things that you can measure with ordinary accounting techniques, these things now account for less than one-fourth of the value of the corporate sector. Another way of putting this is that something like 75% of the sources of value inside corporations is not being measured or reported on their books.10

If you happen to be employed in the public sector you may have noticed Ms. Blair uses the term “corporations”. Believe me, your organizations are being affected every bit as much as your corporate counterparts. The challenges represented by this switch are not going unnoticed in Washington. David M. Walker, Comptroller General of the United States said in a February, 2001 testimony to the U.S. Senate that “human capital management is a pervasive challenge in the federal government. At many agencies human capital shortfalls have contributed to serious problems and risks.”11 In his President’s Management Agenda, U.S. President George W. Bush echoes Walker’s comments and adds that “We must have a government that thinks differently, so we need to recruit talented and imaginative people to public service.”12 In yet another demonstration of the importance of intangible assets, companies are opening the purse strings for intellectual investments. On second thought, opening the purse strings is a bit like saying World War II was a little skirmish, considering the fact that American companies spend a staggering 36 percent of their revenue each year on human capital related investments.13 This transition in value creation from physical to intangible assets has major implications for measurement systems. The financial measurements that characterize existing methods of tabulation were perfectly appropriate for a world dominated by physical assets. Transactions affecting property, plant, and equipment could be recorded and reflected in an organization’s

1982

1992

Today 75%

62% 38%

Source: Balanced Scorecard Step by Step: Maximizing Performance and Maintaining Results (2nd edition) by Paul R. Niven EXHIBIT

5.1

T h e I n c r e a s i n g Va l u e o f I n t a n g i b l e A s s e t s i n O r g a n i z a t i o n s

193

194

chapter 5

it performance management

General Ledger. However, the new economy with its premium on intangible value-creating mechanisms demands more from our performance measurement systems. Today’s system must have the capabilities to identify, describe, monitor, and fully harness the intangible assets driving organizational success. The Balanced Scorecard provides a voice of strength and clarity to intangible assets, allowing organizations to benefit fully from their astronomical potential. The Strategy Story Could there possibly exist a more passionately discussed and debated subject on the business landscape than strategy? While military strategy has been with us for millennia and continues to influence our thinking— witness the ever-popular Art of War by Sun Tzu—business strategy is a relatively new phenomenon with its greatest contributions arriving in the twentieth century. Despite its brief tenure the topic has spawned hundreds of books, thousands of scholarly articles, and countless gurus each espousing their version of the Holy Grail of strategy. Strategy is not a subject that can be unraveled by its academic and practical threads to reveal the one right method or version of the truth. Every reader of this book, if appropriately prodded, could undoubtedly produce a coherent and cogent definition of strategy. Ultimately we all cherish that spirit of discovery and rightly applaud our diversity of ideas, but practically speaking, it makes the study of strategy a frustrating one. Fortunately for all of us the one thing that pundits from every strategy corner do agree on is the fact that strategy execution or implementation is far more important than strategy formation. I have had the opportunity to sit in on a number of strategy setting workshops and have always relished the spirited debates, the “aha” moments of breathtaking clarity. The freshly minted strategy emerging from these often grueling sessions is a justifiably pride-invoking achievement; however, it is a far cry from producing the strategic document to actually living and breathing it day in and day out. To succeed in any business today that is precisely what we must do—bring the strategy to life with the unmistakable clarity necessary for everyone in the organization to act on it each and every day. Eighty-four percent of respondents in one recent poll said that competition in their industry had significantly

the balanced scorecard’s rise to prominence

195

increased in the last five years.14 Let’s face it—we have to execute not only to thrive but to simply stay alive in today’s business world. The good news is that strategy implementation has been proven to boost financial fortunes rather significantly—one study suggested a 35 percent improvement in the quality of strategy implementation for the average firm was associated with a 30 percent improvement in shareholder value.15 Unfortunately, many organizations fall off the strategy execution track, frequently in dramatic fashion. So why does strategy execution prove so elusive for the typical enterprise? Scorecard architects Robert S. Kaplan and David P. Norton believe the answer lies in the form of four barriers that must be surmounted before strategy can be effectively executed (see Exhibit 5.2). The Vision Barrier The vast majority of employees do not understand the organization’s strategy. This situation sufficed at the turn of the twentieth century when value was derived from the most efficient use of physical assets, and employees were literally cogs in the great industrial wheel. However, in the information or knowledge age in which we currently exist, value is created from the intangible assets—the know-how, relationships, databases of rich information, and cultures existing within the organization. Sadly, the news is no better at the department level. In one recent study 52 percent of IT and business executives said IT’s strategic plan is only somewhat understood or not understood at all across the company.16 Put simply, it is difficult to expect employees, already struggling under the burdens of a Mount Everest-sized pile of priorities, to act in concert with your strategy if they don’t understand it. The People Barrier In its 2005 “Reward Programs and Incentive Compensation Survey”, the Society for Human Resource Management found that 69 percent of companies offer some form of incentive compensation to their employees.17 Like most people, I’m a fan of incentive plans because of the focus and alignment they can drive toward the achievement of a mutually beneficial goal. However, companies take many liberties when constructing these plans, and often the designs leave something to be desired. For example, it is not at all uncommon for incentive plans to link a cash award with the achievement of a short-term financial target such as quarterly earnings. In fact, in our “meet the numbers or else” culture this evil twin of the effective compensation plan springs up frequently in

196

Only 10% of organizations execute their strategy

Barriers to Strategy Execution

Vision Barrier

People Barrier

Management Barrier

Resource Barrier

Only 5% of the workforce understands the strategy

Only 25% of managers have incentives linked to strategy

85% of executive teams spend less than one hour per month discussing strategy

60% of organizations don ’t link budgets to strategy

Adapted from material developed by Robert S. Kaplan and David P. Norton EXHIBIT

5.2

The Barriers to Implementing Strateg y

the balanced scorecard’s rise to prominence

197

boardrooms across the globe. When the focus is on achieving short-term financial targets, clever employees will do whatever it takes to ensure those results are achieved. This often comes at the expense of creating long-term value for the firm. Do the words Enron or WorldCom ring a bell? The Resource Barrier Sixty percent of organizations don’t link budgets to strategy. This finding really should not come as a surprise to us because most organizations have separate processes for budgeting and strategic planning. There is one group working to forge the strategy leading the firm heroically into the future, while independently another group crafts the operating and capital budgets for the coming year. This finding is particularly relevant to CIOs who must ensure their spending supports the organization’s strategy as discussed in the preceding chapter should they hope to demonstrate the alignment desired by all. Unfortunately, a recent survey conducted in part by CIO Insight found that just a tenth of respondents consider IT investment allocation decisions to be “strategic and based on explicitly strategic plans.”18 The Management Barrier In a sad, yet humorous commentary on modern organizational life a recent poll of U.S. office workers revealed that 41 percent would rather wash their kitchen floors than attend a management meeting at their company.19 What exactly is being said at these companies? And more importantly, if I offer to host their meetings will they do my laundry at my place? Most of the cleanliness-minded respondents of the survey would, if pressed, probably report that their management meetings are just plain boring, and in many cases that is undoubtedly an accurate assessment. With mind-numbing charts and graphs, sleep-inducing commentaries, and zero conflict, most meetings can rightly be classified as both a waste of time and, unfortunately, a huge lost opportunity. It certainly doesn’t have to be that way. With strategy forming the agenda for a management meeting new life can be pumped into an antiquated institution, instantly changing the dynamic from dull, rote presentations to stimulating debate and discussion on the factors driving the firm forward. How does your executive team spend their time during their monthly or quarterly reviews? If it is like most organizations they probably spend the majority of their time analyzing the financial results and looking for remedies to the “defects” that occur when actual results do not meet budget expectations. A focus on strategy demands that executives spend

198

chapter 5

it performance management

their time together moving beyond the analysis of defects to a deeper understanding of the underlying value creating or destroying mechanisms in the firm.

the balanced scorecard As the preceding discussion indicates, organizations face many hurdles in developing performance measurement systems that truly monitor the right things. What is required is a system that balances the historical accuracy of financial numbers with the drivers of future performance, while simultaneously harnessing the power of intangible assets, and of course assisting organizations in implementing their differentiating strategies. The Balanced Scorecard is the tool that answers this complex triad of challenges. Origins of the Balanced Scorecard The Balanced Scorecard was developed by Robert Kaplan, an accounting professor at Harvard University, and David Norton, a consultant also from the Boston area. In 1990 Kaplan and Norton led a research study of a dozen companies exploring new methods of performance measurement. The impetus for the study was a growing belief that financial measures of performance were ineffective for the modern business enterprise for the many reasons discussed in the opening pages of this chapter. People in the study companies, along with Kaplan and Norton, were convinced that a reliance on financial measures of performance was affecting their ability to create value. The group discussed a number of possible alternatives but settled on the idea of a scorecard featuring performance measures capturing activities from throughout the organization—customer issues, internal business processes, employee activities, and of course shareholder concerns. Kaplan and Norton labeled the new tool the Balanced Scorecard and later summarized the concept in the first of several Harvard Business Review articles, “The Balanced Scorecard—Measures that Drive Performance.”20 Over the next four years a number of organizations adopted the Balanced Scorecard and achieved immediate results. Kaplan and Norton discovered these organizations were not only using the scorecard to complement financial measures with the drivers of future performance, but were also communicating their strategies through the measures they selected for their Balanced Scorecard. As the scorecard gained prominence

the balanced scorecard

199

with organizations around the globe as a key tool in the implementation of strategy, Kaplan and Norton summarized the concept and the learning to that point in their 1996 book, The Balanced Scorecard.21 Since that time the Balanced Scorecard has been adopted by more than half of all Fortune 1000 organizations, and the momentum continues unabated with companies large, medium, and small taking full advantage of the tool’s profound simplicity and unmistakable effectiveness. Once considered the exclusive domain of the for-profit world, the Balanced Scorecard has been translated and effectively implemented in both the nonprofit and public sectors. These organizations have learned that by slightly modifying the scorecard framework they are able to demonstrate to their constituents the value they provide and the steps being taken to fulfill their important missions. So widely accepted and effective has the scorecard been that the Harvard Business Review recently hailed it as one of the 75 most influential ideas of the twentieth century. What Is a Balanced Scorecard? The Balanced Scorecard is a carefully selected set of quantifiable measures derived from an organization’s strategy. The measures selected for each organization’s scorecard represent a tool for its leaders to use in communicating to employees and external stakeholders the outcomes and performance drivers by which the organization achieves its mission and strategic objectives. Scorecard measures are contained in four distinct, yet related perspectives. Balanced Scorecard Perspectives The etymology of the word “perspective” is from the Latin perspectus: “to look through” or “see clearly”, which is precisely what companies aim to do with a Balanced Scorecard—examine their strategy and make it clearer through the lens of different viewpoints. To be effective, any strategy must contain descriptions of financial aspirations, markets served, processes to be conquered, and of course the people who steadily and skillfully guide the ship to success. Thus, when measuring progress it makes little sense to focus on just one aspect of the strategy when in fact as Leonardo da Vinci reminds us “Everything is connected to everything else.”22 An accurate picture of strategy execution must be painted in the full palette of perspectives that comprise it, therefore when developing a Balanced Scorecard

200

chapter 5

it performance management

companies typically use the following four: Customer, Internal Processes, Employee Learning and Growth, and Financial. Now let’s take a brief tour of those four perspectives, examining what the CIO might find at the corporate level of the company as well as what measures IT leaders may use to populate their own scorecard (see Exhibit 5.3). Customer Perspective When choosing measures for the Customer perspective of the scorecard organizations must answer three critical questions: (1) who are our target customers, (2) what is our value proposition in serving them, and (3) what do our customers expect or demand from us? Sounds simple enough, but each of these questions offers many challenges. Most organizations state that they do in fact have a target customer audience, yet their actions reveal an “all things to all customers” strategy. As strategy guru Michael Porter has taught, this lack of focus prevents an organization from differentiating itself from competitors. Choosing an appropriate value proposition poses no less of a challenge to most firms. Many will choose one of three “disciplines” articulated by Treacy and Wiersema in “The Discipline of Market Leaders”:23

• Operational Excellence. Organizations pursuing an operational excellence discipline focus on low price, convenience, and often “no frills.” Wal-Mart provides a great representation of an operationally excellent company. • Product Leadership. Product leaders push the envelope of their firm’s products. Constantly innovating, they strive to offer simply the best product in the market. Sony is an example of a product leader in the field of electronics. • Customer Intimacy. Doing whatever it takes to provide solutions for unique customer’s needs help define the customer intimate company. They don’t look for one-time transactions but instead focus on long-term relationship building through their deep knowledge of customer needs. In the retail industry Nordstrom epitomizes the customer intimate organization. Regardless of the value discipline chosen, at the corporate level the Customer perspective normally includes measures widely used today: customer satisfaction, customer loyalty, market share, and customer acquisition, for example. Equally as important, the organization must develop the

the balanced scorecard

201

performance drivers that lead to improvement in these “lagging” indicators of customer success. Doing so greatly enhances the chances of answering the third question for this perspective: what do our customers expect or demand from us? IT organizations must follow a similar path when developing their Customer perspective, beginning with a discussion of “Who is the Customer?” Most frequently the answer is business units and other departments utilizing IT’s many and varied offerings. While customers vary in their expectations and demands, many require the IT function to provide high-quality, reliable services at a reasonable cost. In other words, they expect all applications supported by IT to be “always on” just as Chapter 1 describes: “The thankless task is to make sure the systems infrastructure needed by an organization is operating correctly and efficiently 24 hours a day, seven days a week.” Quality and reliability, therefore, are popular measures on many IT Scorecard Customer perspectives. In addition to supplying reliable service, customers increasingly expect IT to make significant contributions to business unit success through the provision of analytics and innovative technology solutions necessary to tackle complex marketplace challenges.24 Measuring these contributions are very likely to highlight the important role IT plays in overall corporate strategy execution. Internal Process Perspective The Internal Process perspective of the scorecard identifies the key processes the firm must excel at in order to continue adding value for customers, and ultimately shareholders. Each of the customer disciplines outlined in the Customer perspective description entails the efficient operation of specific internal processes in order to serve customers and fulfill value propositions. The task in this perspective is to identify those processes and develop the best possible objectives and measures with which to track progress. To satisfy customer and shareholder expectations executives often have to identify entirely new internal processes rather than focusing efforts on the incremental improvement of existing activities. Product development, production, manufacturing, delivery, and post-sale service may be represented in this perspective. Once again, IT organizations follow a similar route in developing measures for their own scorecard. The challenge lies in determining which

202

chapter 5

it performance management

internal processes the organization must excel at in order to meet the outcomes described in the Customer perspective. For example, if you include a measure of reliability in the Customer perspective, you must then ask, “What drives reliability from a process standpoint?” Regular maintenance of all systems may be considered an essential process for any IT organization and one that contributes significantly to its ability to supply reliable service for end users. Therefore, you may choose to measure maintenance in your Internal Process perspective. When developing measures for this perspective it is also important to look beyond the day-to-day challenges that keep the IT organization hopping from 9 to 5, or 8 to 6, or even 7 to 7, and consider the differentiating processes that elevate its status as a strategic player in the company and ultimately highlight the critical part the IT organization plays in overall company success. This may be facilitated, for example, by reaching out to business unit leaders, forging partnerships, embedding IT personnel in different units to learn the challenges on the ground, and using the information and knowledge gleaned to produce innovative solutions well beyond the current scope of operations. This new “imperative” to work with other parts of the organization has been stated mildly, especially when compared with the words of Gartner Inc. Vice President Bill Kirwin who warns, “Any CIO who isn’t mingling with the business units to learn how IT can support various initiatives is going to be toast.”25 Employee Learning and Growth Perspective If a CIO wants to achieve ambitious results for internal processes, customers, and ultimately shareholders where are these gains found? The objectives and measures in the Employee Learning and Growth perspective are really the enablers of the other three perspectives. In essence they are the foundation upon which this entire house of a Balanced Scorecard is built. The CIO who identifies objectives, measures, and related initiatives in the Customer and Internal Process perspective can be certain of discovering some gaps between IT’s desired direction and current organizational infrastructure of employee skills (human capital ), information systems (informational capital ), and the environment required to maintain success (organizational capital ). The objectives and measures the CIO designs in this perspective help close that gap and ensure sustainable performance for the future.

the balanced scorecard

203

Employee skills, employee satisfaction, availability of information, and alignment could all have a place in this perspective. Many organizations I’ve worked with struggle in the development of Learning and Growth measures. It is normally the last perspective to be developed, and perhaps the teams are intellectually drained from their earlier efforts of developing new strategic measures, or they simply consider this perspective “soft stuff ” best left to the Human Resources group. No matter how valid the rationale seems, this perspective cannot be overlooked in the development process. As mentioned earlier, the measures developed in the Learning and Growth perspective are really the enablers of all other measures on the IT scorecard. Think of them as the roots of a tree that ultimately run through the trunk of internal processes to the branches of customer results, and finally to the leaves of financial returns. When creating this perspective, IT organizations should utilize the three areas of capital discussed previously: human, information, and organizational. Human capital relates to the mix of skills and talents required by IT personnel in meeting the strategic requirements of the organization’s users. Does your team have the skills and talents required to make the strategic contribution expected of you? Of course, IT has its own information requirements, and they should be measured and monitored under the heading of information capital. Finally, and perhaps most importantly, the IT organization must ensure that its culture is in alignment with the needs of its user community. An insular, silo-based culture will not be effective, or tolerated, in organizations that thrive on information sharing and a customer service ethic. Financial Perspective Financial measures are a critical component of the Balanced Scorecard, especially in the for-profit world. The objectives and measures in this perspective tell whether strategy execution—which is detailed through objectives and measures chosen in the other perspectives—are leading to improved bottom-line results. The IT organization could focus all its energy and capabilities on improving customer satisfaction, quality, on-time delivery, or any number of things, but they are of limited value without an indication of their effect on the company’s financial returns. Typical examples of financial indicators include profitability, revenue growth, and asset utilization.

204

chapter 5

it performance management

Most IT organizations use the Financial perspective to shine a penetrating light on their budgets, ensuring they balance effectiveness with efficiency. This perspective is particularly relevant in an era when some Fortune 100 company IT budgets rival the gross domestic product of small nations! Of course I’m being facetious, but the underlying message remains resonant—IT must avoid the perception of chasing every new technology and instead focus on assisting their customers reach their business goals while doing so with an unrelenting focus on best overall cost. Exhibit 5.3 outlines the typical structure of the Balanced Scorecard as it was originally conceived with profit-seeking enterprises in mind.

building the it balanced scorecard From time to time my phone rings with a request to help “turnaround” a troubled Balanced Scorecard implementation, and recently I received just such a call. Challenges in executing the Balanced Scorecard can stem from any number of sources, but in this large nonprofit the culprit was a distinct lack of planning. The agency was as unprepared from a planning standpoint as it was enthusiastic about the scorecard. Unfortunately the interest and exuberance they felt for the tool failed to compensate for their lack of organization. Virtually every meeting was slowed to a merciless crawl with discussions of process questions. Team members and other stakeholders were naturally curious about the next steps in the process, but the leaders of the scorecard implementation had barely thought through the current meeting let alone the entire implementation journey.26 This lack of planning significantly slowed what could otherwise have been a very swift and successful implementation. As with any major initiative, the CIO needs a carefully crafted development plan to produce an effective Balanced Scorecard. Every organization is different when it comes to planning and executing significant change efforts. Some feel a highly detailed plan that encompasses thousands of lines in Microsoft Project is the only way to capture all the necessary elements of the work. I recall arriving at the offices of one new client, barely completing introductions to the scorecard team, and having a phonebook-sized plan thrust upon my lap. Others use less formal means, outlining only the most critical tasks and tracking them on MS Excel or Word documents.

Financial To succeed financially, how should we appear to our financial stakeholders?

Objectives

Measures

Targets

Initiatives

Customer Objectives

Measures

Targets

Internal Processes Vision and Strategy

Initiatives

Who are our customers and what do they expect or demand?

To satisfy our financial stakeholders and customers, at what processes must we excel?

Employee Learning & Growth Objectives

To achieve our vision, how will we sustain our ability to grow and change?

205

EXHIBIT

5.3

The Balanced Scorecard

Measures

Targets

Initiatives

Objectives

Measures

Targets

Initiatives

206

chapter 5

it performance management

This section outlines the key steps in developing a Balanced Scorecard for the IT organization based on experience and research. Keep in mind that this presentation appears in summary form; I’ve written three books to capture the entire process. Therefore, please use this as an initial guide to help stimulate your Balanced Scorecard thinking. The Planning Phase Before beginning the work of building a Balanced Scorecard, the CIO must lay the groundwork for the implementation ahead. The planning phase includes the following steps. Step 1—Develop a Guiding Rationale for the IT Balanced Scorecard Creating a Balanced Scorecard because it “seems right” or “a colleague had good luck with it” almost always leads to an ineffective implementation. As with any other initiative, invest time, energy, and resources into adopting a Balanced Scorecard according to a guiding rationale and a legitimate business reason. Launching a new program that requires significant employee support for success without a compelling business reason is sure to invite disaster if your employees are already busy contending with the attendant IT firefighting and stress-inducing challenges that arise in their day-to-day work. “The voice created by the failure to communicate is soon filled with poison, drivel, and misrepresentation.”27 Establish a valid reason for embarking on this trail, and communicate that rallying cry relentlessly to win the support of an often change-fatigued employee base. Step 2—Secure Executive Sponsorship In his book Jack, Straight from the Gut, former General Electric CEO Jack Welch points to an undeniable truth of organizational life. “To make initiatives work it took passionate, all-consuming commitment from the top . . . Every leadership action must demonstrate total commitment to the initiative.”28 To break through the attention and commitment barriers that weary IT organization employees experience in the blizzard of change blowing relentlessly around them, the project must, repeat must, have an executive sponsor who believes in the value of the Balanced Scorecard who is willing to ceaselessly champion the cause both up and down the chain of command. Step 3—Form and Train Your Balanced Scorecard Team A robust Balanced Scorecard is best created by the hearts and minds of a small group

building the it balanced scorecard

207

of people committed to a common purpose. Forget the Lone Ranger, the CIO needs a group of bright people willing to engage in the spirited debate necessary to create a scorecard that truly shines a light on IT’s strategic contribution as exemplified by the leadership principles listed in Chapters 1 or 3. With the team formed, don’t neglect to invest in some upfront training on this concept, which admittedly appears simple at first glance, but is replete with nuances and subtleties, the attention to which often separates the winners in this game from the losers. Step 4—Formulate Your Implementation Plan As information technology experts, CIOs are very familiar with the importance of planning. Create an implementation plan for the IT organization’s Balanced Scorecard initiative and monitor major milestones to ensure it remains on track. When it comes to timing for a Balanced Scorecard implementation, every organization will be somewhat different depending upon urgency, availability of resources, and overcoming the inevitable logistical challenges; however, the CIO can expect to have a draft Balanced Scorecard constructed within four weeks. Step 5—Develop a Communication Strategy and Plan for Your Balanced Scorecard Implementation Professor and author John Kotter has said, “Without credible communication, and a lot of it, employees’ hearts and minds are never captured.”29 To their detriment, most organizations fail to heed this valuable advice and their change efforts are the worse for it. These challenges must be met head-on during the implementation efforts if the CIO expects the IT organization employees to begin using this tool to make real business decisions. A carefully constructed communication strategy and plan proves to be a great ally in the struggle to enlighten all employees and win support throughout the Balanced Scorecard development process. A document the size of a Manhattan phone book isn’t necessary here, simply focus on the basics: What are our communication objectives (key messages), who are our target audiences, what are their requirements, and how will we communicate (mechanisms, timing, and so on)?

The Development Phase Consider the steps presented in this section as a framework for development of a Balanced Scorecard for the IT organization. One of the many

208

chapter 5

it performance management

benefits of the scorecard, one that has greatly contributed to its longevity and unabated growth, is its flexibility in adapting to the constraints of every organization. Take advantage of that flexibility when constructing your plan. Step One: Gather and Distribute Background Material The Balanced Scorecard is a tool that describes strategy. In order to fulfill this promise your team must have ample access to background material on the IT organization’s mission, vision, values, strategy, and employee core competencies. Of course, because IT focuses on supplying services to other departments within the company it is important to gather information regarding user needs and business plans. Step Two: Provide Balanced Scorecard Education At this point in the process the development team has been steeped in the fundamentals of the Balanced Scorecard, but the tool still represents a great black hole to much of the IT organization. Plug this gap early and effectively with a comprehensive scorecard training session designed to outline the challenges that led to the selection of the scorecard, fundamental principles of the model, success stories, and how you plan to guide the implementation. Invite as many people as can comfortably fit into a venue for this first training session; this is no time to practice “education snobbery”. Winning the commitment of every employee, thus informing them of what this tool is all about, represents a vital early step on this journey. Step Three: Develop or Confirm Mission, Values, Vision, and Strategy Based on the information gathered in Step One, generate a consensus of where the IT organization rests in terms of these critical items. If missing one or all of these scorecard “raw materials”, go back, work with the leadership team, and develop them. Step Four: Develop Your Strategy Map A well-grounded executive understanding of strategy mapping is critical to Balanced Scorecard success. The Harvard Business Review has cited the Balanced Scorecard as one of the 75 most influential business ideas of the twentieth century. So how does a management tool ascend to such a lofty position when literally hundreds of others are relegated to has-been and flavor of the month status? First and foremost, the Balanced Scorecard has been proven to generate results for thousands of organizations in private, public, and nonprofit fields

building the it balanced scorecard

209

of endeavor, and this efficacy would seem a prerequisite of any tool destined to reach the pantheon of business systems. Dig a little deeper, however, to find another equally compelling rationale for the Balanced Scorecard’s continued growth—its adaptability. Perhaps evolution is a more suitable description. Brought into the world by Kaplan and Norton as a methodology to tame the power of financial metrics run amok, the Balanced Scorecard soon evolved into a system capable of bridging short-term leadership action with long-term strategy through links to such processes and budgeting and compensation. This discovery heralded a new chapter in its life and beckoned thousands of additional organizations to heed the call. But quite possibly the most powerful evolutionary leap in the Balanced Scorecard’s life has been from measurement system to strategy communication device through the advent of the strategy map. The subtitle of Kaplan and Norton’s first Balanced Scorecard book is “Translating Strategy Into Action,” which is exactly what is accomplished by creating performance measures to track the execution of a game plan for success. But creating effective performance measures that serve as true barometers of strategy and performance is tough sledding. Just imagine opening the three-ring binder housing most companies’ 50-page business strategy with the task of translating the contents into a coherent set of measures that indicate whether or not they’ve actually taken the proverbial hill. Even if it’s a two-page strategy pamphlet the chore is an onerous one because even the most well-conceived and carefully crafted strategies are bound to contain at least a portion of ambiguous terms like “customer service” or “product development.” Early Balanced Scorecard adopters faced this challenge and found themselves instinctively spanning the strategy/measures chasm with a discussion of objectives, or what needed to be done well in order to implement the essence of the strategy. So instead of beginning with “How do we measure this strategy?” they uncorked the process by asking themselves “What do we need to do well in order to execute?” Parsing the task in this way allows users to add a necessary layer of granularity to the strategy, ultimately rendering the job of measures creation significantly simpler. For example, if the strategy devoted a section to new product development, stressing the need to bring new products to market at a faster rate than competitors, this narrative was translated into the simple objective of “Accelerate new product development,” which may be accurately measured by the new product development life cycle.

210

chapter 5

it performance management

As with any groundbreaking business tool the Balanced Scorecard has a lexicon all its own, and this discussion distinguishes the meaning of two key terms: objective and measure. This is a critical distinction and one the CIO must master to create a scorecard that both accurately describes the IT organization’s game plan and brings it to life for those charged with the responsibility of executing it on a day-to-day basis—your employees. An objective is a succinct statement, normally beginning with a verb, describing what the IT organization must do well in each of the four perspectives in order to implement its plan. Examples vary widely but could include “Reduce costs”, “Improve service delivery time”, “Enhance reliability”, and “Close our skills gap”. Strategy maps are comprised entirely of objectives. Tracking success in achieving the objective is the domain of the measure, a (typically) quantitative device used to monitor progress. For those who grapple with an issue best by first defining it, try this for a strategy map: a one-page graphical representation of what the IT organization must do well in each of the four perspectives to successfully execute its game plan. Strategy maps do not take any measurements, no tallying of results here, instead the IT organization is communicating to all its audiences, internal and external, what it must do well to achieve its ultimate goals. This fulfills the description of the strategy map as a powerful communication tool, signaling to everyone within the enterprise what must occur to beat the almost overwhelming odds of strategy execution. So why use the term “map”? Why not a more mundane term such as “strategy sheet” or “must do” list? A map guides us on our journey, detailing the pathways to get us from point A to point B, ultimately leading us to our chosen destination. So it is with a strategy map—defining causal pathways that weave through the four perspectives, which lead to the implementation of the IT organization’s strategy. An example strategy map of a fictitious company is displayed in Exhibit 5.4. Using the raw materials previously captured—mission, vision, strategy, user expectations—the IT organization’s scorecard development team starts to build a strategy map for the entire IT organization that describes what it must do well in each of the four perspectives in order to succeed. Step Four (a): Gather Employee Feedback Ultimately, the CIO expects the IT organization’s Balanced Scorecard to provide information that allows

gy

p Grow shareholder value Improve asset utilization

Lower costs

Grow revenue

Be easy to do business with

Operations

Create loyalty through excellence in all we do

Provide high-value solutions

Managing Customers

Innovation

Good Citizen

Optimize customerfacing processes

Understand our customers

Research and evaluate trends

Monitor & evaluate compliance with laws & regulations

Enhance internal and external communication

Build life-long relationships

Create new products and services

Ensure effective internal controls are in place

Attract, develop, and retain talent

Leverage technology for success

211

Ensure a positive and healthy work environment

Source: Balanced Scorecard Step by Step: Maximizing Performance and Maintaining Results (2nd edition) by Paul R. Niven EXHIBIT

5.4

A Strateg y Map

212

chapter 5

it performance management

all IT employees to understand how their day-to-day actions link to the organization’s strategic plan. Therefore, the CIO polls IT employees to ensure they feel the strategy map has captured the critical elements of value to the whole IT organization. Step Five: Develop Performance Measures Returning to the ancestral homeland of the Balanced Scorecard, which was created many years ago as a measurement system, the IT organization’s scorecard development team translates each of the objectives on the strategy map into metrics that can be tracked to provide insight into the execution of IT strategy and establish accountability throughout the organization. Step Five (a): Gather Employee Feedback This represents an optional step. While the CIO desires employee feedback at every turn of the scorecard wheel, the appropriate managers must eventually own the highestlevel performance measures, and one would expect their “stickiness factor” to be off the charts if they have not had the chance to participate. Consider using this opportunity to explain to IT staff members precisely why the particular measures were chosen. Step Six: Establish Targets and Prioritize Initiatives Without a target for each measure, the CIO and measurement managers have no way of knowing whether improvement efforts are yielding acceptable results. The data from the IT scorecard metrics provides the IT organization with only half the picture. A target gives meaning to measure results by affording a point of comparison. Additionally, all measures should be accompanied by initiatives designed to bring the targets to fruition. An initiative may be a specific action, project, or plan that supports the achievement of the target. Step Seven: Gather Data for Your First Balanced Scorecard Report Dare to be bold and proclaim that within 60 days of developing your performance measures the IT organization will conduct its first meeting with its scorecard at the helm. This requires gathering the data necessary to supply that initial report. You may be thinking, “We’ll never have all the data!” And you are probably correct, because most new scorecard adopters are missing at least a portion of the data for performance metrics as they ramp up their reporting efforts. However, don’t let that stop you from the many significant benefits that can accrue from discussing the measures you do have: focus, alignment, and improved resource allocation decisions to name

putting it all together

213

but a few. Please refer to the discussion in Chapters 1 and 3, about team building, and Chapter 8, for the return on such an investment. Step Eight: Hold Your First Balanced Scorecard Meeting Those rockin’ Granddads and elder statesmen of music royalty, the Rolling Stones, recently made a stop on their world tour here in San Diego, and I would love to have seen them in action. But as the concert date loomed ever closer did I take any action? No, I just kept saying to myself, “I’d love to see them.” Earth to Paul: buy a ticket! There was absolutely nothing in the way of me wailing my heart out to “Satisfaction” with the exception of that tiniest of details—that for some reason I let the opportunity slip away. Some scorecard implementing organizations make the same mistake by talking a great game about the alignment and focus they are going to derive from the tool, but they fail to achieve it because they simply refuse to place the scorecard at the center of their management meeting and reporting agenda. Repeat after me: “To execute strategy, we must discuss strategy.” Getting to the first Balanced Scorecard report should be the CIO’s number one priority in the initial stages of the IT organization’s scorecard implementation. Unlike me with the Stones (knowing them, they will probably be touring for another 20 years), CIOs don’t have the luxury of time, so make reporting a high priority on your list. Step Nine: Develop the Ongoing Balanced Scorecard Implementation Plan The preceding steps will get the CIO and the IT organization from point zero to the development of a Balanced Scorecard measurement tool. The word measurement is stressed here because you can do so much more with your scorecard—install the system as the cornerstone of the IT organization’s management processes such as budgeting, compensation, and professional development.

putting it all together—the journey of the orange county transportation agency Under the leadership of CIO Bill Mao, the information services (IS) department’s team of 35 employees and 10 contractors provides the Orange County (California) Transportation Agency (OTCA) with a broad portfolio of services including data management, business support, security, and

214

chapter 5

it performance management

technical services. That list of offerings probably sounds familiar, but as many CIOs know, prioritizing staff workloads and determining IS success while attempting to remain in alignment with overall organizational strategy is a tremendous challenge. To help overcome those potential barriers OCTA IS introduced the Balanced Scorecard in 2003, with the following objectives for the implementation: • Align stakeholders, sponsors, leaders, and employees to do the right things for the organization. • Make strategy the job of all IS employees through a personal contribution to strategic implementation. • Translate the IS strategy to operational terms so that everyone understands it and demonstrates how they contribute. • Provide reliable data for business cases to negotiate budgets (up or down), prioritize work, and allocate resources. • Ensure rewards and positive reinforcement continually occur. • Tie employee compensation to performance as defined and measured within the IS BSC. • Provide IS management and staff a common context in which to make daily decisions, both individually and as a group, with a similar pace and congruent results in mind. • Help all employees focus on the future and not dwell on the past. Achieving such ambitious objectives would require a dedicated executive sponsor willing to freely share one’s time, expertise, and guidance. CIO Bill Mao immediately assumed the role and developed strong relationships with other OCTA stakeholders including the Director of Finance and Administration, the Director of Operations, and the Assistant Chief Executive Officer. Forging close bonds with these stakeholders proved to be a critical advantage for the initiative because two of the three had personal experience with the Balanced Scorecard and demonstrated advocacy for the implementation from the earliest stages. Laying the Foundation for Balanced Scorecard Success In keeping with the discussion of scorecard “raw materials” earlier in the chapter, the IS group began their efforts by developing a mission, vision,

putting it all together

215

and strategic themes for the department, each of which would serve as pillars for the scorecard work to follow. The mission statement reads: Through teamwork, provide leadership, guidance, and support for information and communication technologies within the Authority. Our goal is to add value and provide business solutions that satisfy our customers.

The IS vision builds on the mission and focuses on what is necessary for IS to ensure success in the challenging environment they face: Success: driven by customers, fueled by innovation, achieved through partnerships.

It would certainly be difficult to argue with the choices inherent in the vision statement, as success truly is driven by customers; understanding their needs and providing them with the tools they require to drive the organization’s strategy. Similarly, innovative new technologies and solutions are more necessary than ever. And finally, it is only through building bridges with users by forming partnerships and alliances that establish true alignment in this or any organization. With the mission and vision statements in place the group turned their attention to the development of “strategic themes”, which they defined as broad directional priorities used to steer the overall IS ship. Four such themes were created: 1. Have a Business/Customer focus 2. Keep pace with technology 3. Work smarter 4. Always “on” With the necessary scorecard building blocks in place, two teams were created for the work to follow: a leadership team comprised of IS managers would provide overall guidance and approve all scorecard materials, and a core team consisting of six representatives from the various IS disciplines was responsible for creating the department’s strategy map and Balanced Scorecard of measures. Job number one was Balanced Scorecard training for both newly minted teams, and with the assistance of outside consultants the groups were provided with a curriculum of strategy and scorecardrelated concepts including BSC background and fundamentals, developing strategy maps and measures, and managing with the BSC system.

216

chapter 5

it performance management

The Balanced Scorecard is primarily an agent of change within an organization; a change in the way it measures, in the way it manages, and if utilized effectively, a change in results. As we all know, change can prove to be painfully difficult, so it should come as no surprise that despite the careful foundation poured for the BSC by IS leadership, both core team members and employees were initially hesitant to jump on board. As Scorecard Coordinator Annette Hess explains, Employees were very resistant and reluctant. The BSC was initially perceived as just another flavor of the month that would disappear off the radar in due time. When people realized it was not going away any time soon they began to resist it. Reactions were mixed but mostly staff felt they did not have time for it, they were too busy as it was and this was just another chore piled on top.30

For some, only proof in the form of results would help sway their sentiments. But for many, simply learning more about the scorecard itself and why IS was launching the initiative proved to be an effective antidote to reluctance and resistance. The IS team communicated to staff in a number of ways: updates and discussions occurred in general department meetings, PowerPoint presentations were delivered, and posters were placed throughout the department highlighting specific aspects of the IS Balanced Scorecard. The IS Strategy Map and Measures Exhibit 5.5 shows the IS department’s strategy map of key objectives. The first thing that stands out about their map is that they don’t use the four standard Balanced Scorecard perspectives previously discussed. In place of a Financial perspective they’ve chosen to use the label “Mission” and include within it their overall objectives of increasing OCTA value, increasing customer satisfaction, and getting more bang for their buck. Although the standard scorecard monikers have proven effective for many organizations around the globe, they may not match the language many organizations use on a day-to-day basis. To enhance understanding and acceptance of the scorecard, be sure and use perspective titles that fit your IT organization’s culture and represent the language spoken by your teams. The IS department also decided to use their four strategic themes as headings with objectives appearing in each of the perspectives telling a

Business/ Customer Focus

Keep Pace With Technology

Work Smarter

Always On

Increase OCTA value

Mission Increase customer satisfaction

Participate knowledgeably and contribute to meeting needs

Customer

Understand customers’ business needs

Internal Processes

Proactively provide effective and innovative solutions

Encourage customers to keep pace with technology

Get more bang for our buck

Deliver agreedupon results

Keep systems up and running

Develop, review, and simplify internal practices and procedures

Build it right, keep it healthy

Explore options

Employee Learning and Growth

217

EXHIBIT

Get off the 3rd floor

5.5

Encourage, recognize, and reward contribution

O C TA I S S t r a t e g y M a p

Communicate and collaborate

Find, develop, and retain superior performers

Foster accountability

218

chapter 5

it performance management

strategic story related to the particular themes. For example, under the theme of “Business/Customer focus” in the Internal Process perspective they place the objective “Understand customers’ business needs.” The team feels that if they are able to do this it will positively influence the objective of “Participate knowledgeably and contribute to meeting needs” as shown in the Customer perspective. Participating knowledgeably in turn drives customer satisfaction in the Mission perspective, which in turn increases OCTA’s value, their overarching objective. These “theme stories” as they came to be known throughout the IS department turned out to be a critical enabler of the scorecard’s success. Managers have noted the value of the stories in explaining the organization’s strategic direction with their employees, making the linkages among objectives plain for all to see, understand, and most important, act upon. Using this system of cause and effect among the objectives allows the leadership team to critically examine results in light of the hypotheses represented within the map. “But,” you say, “Why are there no one-to-one direct upward arrows extending from the Employee Learning and Growth perspective?” As discussed earlier, objectives in this perspective are typically seen as enablers, and each could potentially impact every objective in all remaining perspectives. For example, “Communicate and collaborate” is critical to the success of any organization, OCTA IS included, and impacts the success of every objective comprising the map. Drawing arrows from Communicate and collaborate to all objectives above would simply confuse readers and dramatically diminish the strategy map’s power as a communication tool. An important lesson to draw from the OCTA IS strategy map is the simple language employed throughout the document. As all CIOs know, working in technology provides nearly limitless opportunities to pepper one’s speech and written communication with acronyms and phrases that can leave the rest of us technology neophytes scratching our heads in utter confusion. This team recognized the importance of communicating effectively to all stakeholders: managers, employees, senior leaders outside of IS, and outside vendors. Consequently, IS worked diligently to create a map that is at once readable and powerful in its elegant simplicity. Perhaps my favorite objective, a wonderful exemplar of this simplicity principle, is “Get off the 3rd floor.” Assuming you don’t work for this organization, what do you think that means? I’m sure many of you are thinking to yourself, “It means get out and speak with our customers, build

putting it all together

219

relationships, and learn more about their needs.” Exactly! This is the kind of language you should be using in such a document, which is at its core a communication vehicle, signaling to all stakeholders the critical objectives of the IT organization’s success. OCTA’s Scorecard Coordinator Annette Hess suggests that keeping the map easy to understand and resonant with the department’s culture is a key to success in this process: “You should keep the map current and simple; make it yours. Don’t try to mimic other companies just to say you have one.”31 Each objective on the strategy map is translated into one or more performance measures demonstrating how the organization will gauge its success on that particular item. Although I can’t share all of the IS team’s measures in this chapter, a sample has been provided in Exhibit 5.6. With a strategy map and measures in place the IS leadership team continued their scorecard education efforts by introducing all employees to these new tools for executing strategy. In group sessions, facilitators walked participants through the map and measures explaining why IS was focusing on the themes appearing on the map and how the objectives and measures related to the ultimate fulfillment of the promise inherent in each. The sessions also served to steep employees in the new language and terminology of the Balanced Scorecard system. The Results According to IS leadership, the greatest benefit from implementing the Balanced Scorecard has been increased employee knowledge of how they are able to personally contribute to the department’s strategy. Through discussions of scorecard results and the ongoing communication campaign launched by the leadership team, employees not only recognize their vital link in the chain of events leading to improved customer satisfaction but are offering ideas and suggestions as to specific actions everyone can take to increase OCTA’s value—their overarching mission objective. Stakeholders outside of IS have also taken notice of the changes and the department is viewed as providing value-added service to the entire organization. Challenges in Creating the OCTA IS Balanced Scorecard Though the IS Balanced Scorecard can be deemed a success it has not been without challenges, the type which plague many such change-oriented

220

Objective

Measure

Participate knowledgeably and contribute to meeting needs

Business unit meeting survey (monthly), percentage very satisfied with IS contribution

Encourage customers to keep pace with technology

Number of classes offered by IS Number of articles published in newsletter with IS topics

Explore options

Number of solutions provided

Develop, review, and simplify internal practices and procedures

Number of functions covered by procedures and practices

Foster accountability

Number of initiatives with defined roles and responsibilities

EXHIBIT

5.6

S a m p l e o f O C TA I S M e a s u r e s

notes

221

initiatives. A barrier erected at the outset of the implementation was the fact that the BSC was not being developed at higher levels of the OCTA organization, thus employees were concerned they were “going it alone” without the necessary support of senior executives throughout the organization. The ceaseless efforts of the executive sponsor, CIO Bill Mao, and the support of other directors within OCTA were, and will continue to be, necessary to reassure employees this is not a flavor of the month offering but instead represents a fundamental shift in the way the department does business. In hindsight the leadership team believes it would have proven beneficial to dedicate more time and resources to the initiative at the outset, getting the program up, running, and self-sustaining in a shorter period of time. In the early days of the initiative much of the work fell upon the shoulders of the Balanced Scorecard Coordinator, which not only significantly increased her already considerable workload but did little to generate buy-in and support for the tool from the wider employee base. Establishing theme and objective owners has improved the scorecard’s prospects significantly by spreading the work across a number of individuals and in the process enhancing knowledge of, and commitment to, the process itself. As with any major change, initiative challenges remain as the IS department continues its journey with the Balanced Scorecard system, but the indicators thus far are very positive: enhanced knowledge of strategy, increased alignment with overall OCTA goals, and an unrelenting focus on key performance measures all combining to make the IS team a key contributor to OCTA’s ongoing success.

[Note to readers. Much of this chapter is drawn directly from Mr. Niven’s book: Balanced Scorecard Step by Step: Maximizing Performance and Maintaining Results (2nd Edition), Wiley 2006. He has updated the work with an emphasis on the role of the BSC for the IT organization.] ■ notes 1. Accessed at http://www.computerworld.com/managmenttopics/management/ story/0,10801,109087,00.html. March 6, 2006.

222

chapter 5

it performance management

2. See, David P. Norton, “Creating Strategic Alignment and Readiness for IT,” Balanced Scorecard Report, September-October 2002: 1-5. 3. From the presentation delivered by Robert S. Kaplan, “Creating StrategyFocused Public Sector Organizations,” September, 2004. 4. David P. Norton and Randall H. Russell, “Translate the Strategy Into Operational Terms,” Balanced Scorecard Report, May-June 2005: 1-5. 5. Thomas A. Stewart, “Intellectual Capital, (New York, NY, Currency, 1999) xxi. 6. Scott Thurm, “Teamwork Raises Everyone’s Game,” The Wall Street Journal, November 7, 2005: B8. 7. Lauri Bassi and Daniel McMurrer, “Are Employee Skills a Cost or an Asset,” Business Ethics, Fall 2004. 8. Malcolm P. McNair, “What Price Human Relations?” Harvard Business Review (1957). 9. Quoted in 11th Annual Worldwide Luminary Series: Leading to Greatness” participant workbook, November 2, 2005. 10. Interview on National Public Radio’s Morning Edition October 27, 2000. 11. Testimony by David M. Walker, Comptroller General of the United States, before the Subcommittee on Oversight of Government, Management, Restructuring, and the District of Columbia Committee on Governmental Affairs, U.S. Senate. 12. Found at: www.whitehouse.gov/omb/budget/fy2002/mgmt.pdf. 13. Haig R. Nalbantian, Richard A. Guzzo, Dave Kieffer, and Jay Doherty, Play To Your Strengths (New York: McGraw-Hill, 2004). 14. McKinsey Quarterly Global Survey of Business Executives, November 2004. 15. Brian E. Becker, Mark A. Huselid, and Dave Ulrich, The HR Scorecard, (Boston: Harvard Business School Press, 2001). 16. From the Strategic Alignment Research Study, “Communication Gap,” 2002. Study Sponsored by CIO Insight Magazine and the Balanced Scorecard Collaborative. 17. Reported in: Synygy Magazine, Fall 2005. 18. From the Strategic Alignment Research Study, “Communication Gap,” 2002. Study Sponsored by CIO Insight Magazine and the Balanced Scorecard Collaborative. 19. Julia Neyman and Julie Snider, “USA Today Snapshots,” USA Today, November 15, 2004. 20. Robert S. Kaplan and David P. Norton, “The Balanced Scorecard—Measures that Drive Performance,” Harvard Business Review, January-February 1992: 71-79. 21. Robert S. Kaplan and David P. Norton, The Balanced Scorecard (Boston: Harvard Business School Press, 1996). 22. Michael J. Gelb, How to Think Like Leonardo da Vinci (New York: Random House, 2004). 23. Michael Treacy and Fred Wiersema, The Discipline of Market Leaders (Reading, MA, Perseus Books, 1995).

notes

223

24. Robert S. Kaplan and David P. Norton, Alignment (Boston: Harvard Business School Press, 2006)146. 25. Tad Leahy, “The Elusive IT Balanced Scorecard,” Business Finance, August 2003. Article accessed at www.businessfinancemag.com/magazine/archives. 26. Paul R. Niven, Balanced Scorecard Diagnostics: Maintaining Maximum Performance (New York: John Wiley & Sons, 2005) 58. 27. Quoted in: Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler, Crucial Conversations (New York: McGraw-Hill, 2002). 28. Jack Welch with John A. Byrne, Jack: Straight From The Gut (New York: Warner Business, 2001). 29. John P. Kotter, Leading Change, (Boston: Harvard Business School Press, 1996). 30. From a correspondence with the author dated May 16, 2006. 31. See note 30 above.

chapter

6

How to Measure and Manage Customer Value and Customer Profitability by gary cokins, sas, [email protected]

part 1 the rising need to focus on customers Shareholder Wealth Creation Is More Than Just Growing Sales In 2005 Best Buy, a leading “big box” retail chain stunned the business media by formally announcing that it was focusing its marketing and sales efforts to attract and grow those types of customers who were more likely to generate profits for Best Buy. This implied it would pay little or no attention to the types of customers who infrequently shopped in its stores or minimally purchased goods, or only discounted items. Some of Best Buy’s competitors immediately pounced on this in an attempt to embarrass Best Buy and broadcast to the marketplace that they would cater to everyone. That reactive maneuver by competitors was a short-lived marketing campaign, and Best Buy held its ground and continued to earn above-industry average profits. Best Buy was simply pursuing what many organizations have intuitively sensed and some have actually measured— there are certain types of customers who are more profitable today and more valuable in the future with long-term potential. 225

226

chapter 6

how to measure and manage customer value

Best Buy was acknowledging a shift in business thinking. It is no longer just about increasing sales but more appropriately increasing sales profitably. In short, measuring gross margin profitability on sales from products and standard-service lines is not the only metric to monitor. It is important to additionally acknowledge and distinguish the cost-to-serve between high demanding and low demanding types of customers to get a full picture of where a business is making or losing money. Accountants refer to this as computing fully loaded costs. This obvious but often neglected reality is well described by two Columbia University professors: Most sales people manage for short-term revenues (regardless of profits). . . . With an increasingly sophisticated customer base that wants lower prices, greater service, and more control; this strategy most often results in declining profit margins and commoditization. Increasingly buying power and market influence is being concentrated in an ever-smaller number of strategic customers. Hence, going forward, we believe that companies will have to think beyond short-term revenue and profitability of today. They will have to take the long view and manage their strategic customer relationships as assets. They will attempt to maximize the net present value (NPV) of future profit streams from these customers, thus shifting to the enhancement of long-term Customer Relationship Capital.1

Companies must improve in several areas when it comes to strategizing, measuring, and acting on customer value. Organic growth, by focusing on existing customers, should be viewed as sustaining strategy, and understanding customer value is the key to organic growth. But this is not easily achieved because at the strategy level many companies remain focused on “product-out” rather than “customer-in”. If the strategic focus is to sell as many products as possible, customers get swamped by irrelevant marketing and sales offers, and they are subjected to poor experiences. It is very difficult to acquire, grow, or retain profitable customers in that kind of environment. To further complicate matters, the CIO is tasked with the challenge of satisfying two somewhat disparate views and perspectives of their organization—the information technology (IT) stakeholders and the business management leaders. Of course, there is overlap and some would argue these two views are one in the same. Regardless of the outcome of

the rising need to focus on customers

227

that debate, the CIO function is challenged today to deliver well beyond just maintaining and improving reliable transaction-based information systems and include effective decision support as well—which some refer to as business intelligence. This chapter addresses the evolving relationship between an enterprise’s CFO and the CMO. The CIO’s role is to service both functions as the bridge between them is strengthened. How to Measure the Return on Investment (ROI) on Sales and Marketing Estimating the ROI on purchasing equipment is near science. In contrast, determining the ROI on some marketing programs may be considered more of an art than a science. Thus, a large part of the marketing budget is typically based on faith that it will somehow grow the business. There is a very old rumored quote from a company president stating, “I am certain that half the money I am spending in advertising is wasted. The trouble is, I do not know which half.” This expresses a valid concern—and it applies to the many marketing programs in addition to general advertising. Marketing spends money in certain areas, and the company hopes for return. Was that brochure we just mailed a waste of time and money or did it actually influence someone to purchase? No one in senior management seems to question that sales, marketing, and advertising is something the company must spend money on—but how much money? How much is too much? Where is the highest payback to focus and where to avoid? Companies are extremely vigilant about all spending. They exercise draconian actions, such as layoffs, to right-size their cost structure. The budget expenditures for sales and marketing should be subject to the same intense examination of the COO and CFO as any other spending programs. The ROI on marketing, and each marketing program or campaign, must be better projected—not with fuzzy math but by using modern analytical techniques, fact-based logic, and financial data. After all, in the absence of facts, anyone’s opinion is a good one. (And the biggest opinion usually wins! And that opinion is usually one’s supervisor or the supervisor of that supervisor.) The CIO function can aid the chief marketing officer here. Many marketing functions rely on imperfect metrics, anecdotes, and history that may have been a result of unusual occurrences unlikely to be repeated.

228

chapter 6

how to measure and manage customer value

I am not arguing to slash all marketing budgets by exposing them as a waste. In fact, I mean just the opposite. The marketing spend is critical—but treat it as a preciously scarce resource to be aimed at generating the highest long-term profits. This means the need for answering questions such as, “Which type of customer is attractive to newly acquire, retain, or win back? And which types are not? How much should we spend attracting, retaining, or recovering them?” Some firms have already enacted programs in these areas to begin trying to answer these questions. More must do this. Although the marketing and sales functions clearly see the links between increasing customer satisfaction and generating higher revenues, the accountants have traditionally focused on encouraging cost reduction as a road to higher profits. A way for investors, shareholders, and a management team to think about measuring a company’s promise for long-term economic value growth performance is to measure its customers. Although today the CFO’s managerial accounting planning and control systems typically focus on operations management, the CFO is now shifting their assistance to the chief marketing officer (CMO) and sales director—and the benefits can be substantial.

the perfect storm is creating turbulence for marketing management In the past ten years, five major forces are converging that place immense pressure on companies, particularly on business-to-consumer (B2C) ones: 1. Customer Retention. It is generally more expensive to acquire a new customer than to retain an existing one—and satisfied existing customers are not only likely to buy more but also “spread the word” to others like a referral service. Hence there is an increasing focus on customer satisfaction. The trend in emphasis is toward growing existing customers and making them loyal rather than a focus on acquiring new ones. This has resulted in loyalty programs and other frequency points programs growing in popularity. 2. A Shift in the Source for Competitive Advantage. In the past, companies focused on building products and selling them to every potential prospect. But many products or service lines are one-size-fits-all and

the perfect storm is creating turbulence

229

are managed like a commodity. To complicate matters, product development management methods (PDM) have matured and accelerate quick me-too copying of new products or service lines by competitors. Consequently, as products and service lines become commodities, where competitors offer comparable ones, then the importance of service rises. There is an unarguable shift from productdriven differentiation toward service-based differentiation. That is, as differentiation from product advantages is reduced or neutralized, the customer relationship grows in importance. This trend has given rise to many marketing organizations focusing on segment, service, and channel programs, as opposed to traditional product-focused initiatives. Business strategists all agree that differentiation is a key to competitive advantage. This was a main revelation in Michael Porter’s seminal book published in 1998, Competitive Advantage, which launched strategic planning as an essential company function. 3. “One-to-One” Marketing. Technology is being hailed as an enabler to (1) identify customer segments, and (2) tailor marketing offers and service propositions to individual customers (or segments). There is now a shift from mass marketing products a seller believes it can sell to a much better understanding of each customer’s unique preferences and what they can afford. Spray-and-pray marketing campaigns waste spending needlessly. Companies may even need to better understand their customer’s customer. Traditional marketing measures like market share and sales growth are being expanded to more reflective measures of marketing performance such as additional products and services sold to existing customers. There is frequent reference to “share of customer wallet”. Customer lifetime value, to be discussed later, is a trendy new indicator for customer economic value. In short, the message is that companies must now continuously seek ways to engage in more contentrelevant communications and interactions with their customers. Each interaction is an opportunity to gain knowledge about customer preferences—and to strengthen the relationship. 4. Expanded Product Diversity, Variation, and Customization. As product and service lines proliferate, such as new colors or sizes, it results in complexity. As a result, more indirect expenses (i.e., overhead costs)

230

chapter 6

how to measure and manage customer value

are needed to manage the complexity; and therefore indirect expenses are increasing at a relatively faster rate than direct expenses. With indirect expenses growing as a component of an organization’s cost structure, managerial accounting practices typically require enhancing. (Many costing systems arbitrarily allocate overhead to products based on broad-brush averages, such as product sales or direct labor hours; so they do not reflect each product’s unique consumption of indirect expenses. Activity-based costing (ABC) is now accepted as the method that resolves this problem (see Chapter 4, pg. 156–82, for applications of ABC to IT Finance). ABC traces and assigns costs based on cause-and-effect relationships (Appendix 6.A describes a basic outline of ABC). This does not mean that an increase in overhead costs is a bad thing. It simply means that a company is required to invest and spend more on expanded product offerings and services to increase its customers’ satisfaction. 5. Power Shift to Customers. The Internet is shifting power—irreversibly— from sellers to buyers. Thanks to the Internet, consumers and purchasing agents can more efficiently explore more shopping options and they can more easily educate themselves. Customers have an abundance of options; and now they can get information about products or services that interest them in a much shorter amount of time than what today appear as the antiquated ways of the past. The customer is in control more than ever before. Consequently, from a supplier’s perspective, customer retention becomes even more critical and treating customers as “a lifetime stream of revenues” becomes paramount. This shift in power from sellers to buyers is placing relentless pressure on suppliers. Supplier shakeouts and consolidations are constant. The combination and convergence of these five forces means that suppliers must pay much more attention to their customers. The implication is clear. Profit growth for suppliers and service providers will come from building intimate relationships with customers, and from providing more products and services to one’s existing customer base. Earning, not just buying, customer loyalty is now mandatory. But how much should a company spend in marketing to retain customers, and which type of customers should it spend more on? Few organizations can answer these questions.

Marketing Metrics Decomposition Tree Customer ROI Customer value management (acquire, retain, recover)

Profit and ROI metrics

CP / CLV Customer base growth*

Customer satisfaction

Effectiveness

Products per customer

$ revenue per campaign Time to market

Marketing team and campaigns

# of campaigns

Efficiency and productivity

$ cost per communication

231

$ revenue per FTE . Copyright © 2006 SAS Institute Inc. ( [email protected] ) All rights reserved.

EXHIBIT

6.1

M a r k e t i n g M e t r i c s D e c o m p o s i t i o n Tr e e

232

chapter 6

how to measure and manage customer value

When it comes to measuring the overall marketing function, many companies miss the ROI mark. They do not have meaningful, consistent, and reliable marketing performance metrics. Worse yet, in an attempt to build customer loyalty, they continue to deploy blanket mass-marketing strategies rather than differentiate (i.e., segment) their customers based on cross-sell and up-sell opportunities. Good customer intelligence systems help organizations make smarter decisions faster. A workflow or business process without the ability to measure, analyze, and improve its effectiveness simply perpetuates a problem. A good customer relationship management (CRM) system allows end-to-end functionality from sales lead management to order tracking—potentially seamlessly. Exhibit 6.1 illustrates key components for measuring the performance of marketing with examples of performance metrics. The top half of this decomposition tree focuses on customer value management, which is the topic of this article. The lower half describes the effectiveness and productivity of the marketing function itself and one of its tools of the trade—marketing campaigns. The CFO should help the CMO measure both. This chapter digs deeper into the two key financial measures for customer valuation management: customer profitability and customer lifetime value (CLV). Part 2 places customer relationship management into a broad framework and context.

part 2 a foundation for customer portfolio management Focusing, but not Obsessing on the Customer The focus in this part of the chapter is customer portfolio management to reward the company’s shareholders. To create higher shareholder wealth, a company must continuously analyze its customer portfolio in innovative ways to discover new profitable revenue growth opportunities. The CIO becomes critical because data typically resides in multiple and disparate databases. A business strategy to realize revenue and profit opportunities will generally pursue the following objectives: • Identify, understand, and address your best (and worst) customers. • Target and sell existing products and services to existing customers.

foundation for customer portfolio management

233

• Target new prospective customers with similar profiles as your most valuable existing customers. • Develop compelling new product and standard service line offerings, price schemes, and marketing programs for the entire customer portfolio. • Retain and maximize the share of wallet for the most profitable customers as well as those who have a high probability of becoming profitable, hence more “valuable,” in the future. A company must possess a number of core capabilities in order to accomplish these objectives. Exhibit 6.2 illustrates how these begin by constructing a foundation of customer information that is a 360-degree perspective with the capacity to reach customers on a one-to-one basis via effective marketing delivery systems. Let’s explore these capabilities in more detail.

Interaction Management Marketing Automation

Marketing Delivery Systems

Cross-selling Programs

Up-selling Programs

Profitability Drivers

Marketing Optimization

Retention Programs

Segmentation Process

Single Customer View . Copyright © 2006 SAS Institute Inc. ( [email protected] ) All rights reserved.

EXHIBIT

Management

6.2

A F o u n d a t i o n f o r C u s t o m e r Po r t f o l i o

234

chapter 6

how to measure and manage customer value

Single View of the Customer Companies often have difficulty accessing, consolidating, and analyzing the necessary customer data that exists across their various business systems. This issue is exacerbated with time as the number of systems and discrete customer databases expands. Becoming customer-centric requires a view of data that involves no walls. For example, a bank should ideally consolidate its information into a single database rather than keep its credit card data in one silo, its bank account data in another, and its mortgage data in yet another. A “single view” of the customer must be created—a view that consolidates relevant and accurate data related to a single customer across different organizations, databases, and operational systems. An Understanding of Customer Value and Profitability Drivers Meaningful transactional and descriptive customer data coupled with the right analytic processes and software provided by the CIO can prove or refute theories about which customers are most valuable to serve and retain and which are not. Understanding customer value and profitability using activity-based costing methods helps define value and profitability segments and their profitability drivers. It also provides clues on how to improve costs-to-serve (and therefore, profitability) in the future. Whether your cost accounting approach is limited in scope to only assign product, standard service line, and distribution costs to customers, or beyond that scope also fully allocates all other costs and capital, identifying customer profitability drivers is a necessary dimension to understanding and segmenting the customer base. These approaches also identify the less profitable (and in some cases unprofitable) customers and provide alternative strategies for how to unlock value hidden in customers as assets. Meaningful Customer Segmentation Schemes A customer-centric approach segments the customer base in multiple ways. As an example for a bank, it is not enough to simply know the ages of customers and say, “We’ll market IRAs to the 40-year-olds” or to simply know the total assets a customer holds with the bank and in which

foundation for customer portfolio management

235

accounts. Customer segmentation is much more granular. Continuing with the bank example, it means knowing which customers respond to e-mail marketing efforts or mailers, whether they move money in and out of their accounts and how often, or whether they prefer carrying debt on a home equity line versus a credit card. It means packaging all of this data into a single view of the customer that can be updated in real time. It is useful, almost essential, to know what the customer is doing today, not only what she did six months ago, and to be able forecast her future behavior based on predictive models. Each industry has its own examples of customer behavior; however, they all typically involve a substantially greater depth of understanding customers than their relatively simplistic monitoring today. Many organizations primarily segment their customers by the classic “recency, frequency, and monetary spend (RFM)” metrics, by demographics, and by the products and service lines that their customers purchase. In the advanced analytics organizations, these segmentation approaches are viewed as rudimentary, and they do not necessarily relate to customers’ future needs or likely behaviors. Without more effective customer segmentation with respect to current needs and/or likely future behavior, companies have difficulty executing successful strategies for improving their profitability—current and long-term—from existing and future customers with new products and standard service lines or increased marketing campaigns. A deficient segmentation scheme may also negatively impact customer loyalty and ultimately increase costs by mismatching product/pricing offers and appropriate customer segments. Incorporating robust segmentation schemes helps identify movement between segments of specific customers (based on changes in needs and/or behavior) and pinpoints the emergence of new and distinct segments over time. Exhibit 6.3 illustrates the traditional view of how a company may attempt to shift a customer “up to a higher” customer category. In contrast, Exhibit 6.4 illustrates how geo-demographic segments of customers can be shifted across attitudinal and behavioral dimensions. More sophisticated schemes of segmenting customers by meaningful dimensions, including transaction and mix volumes, demographic, geographic, attitudinal, behavioral, and profitability, yield distinct and manageable groups for targeted activities and differentiated services. Programs

236

chapter 6

how to measure and manage customer value

High Medium

Many companies believe that this is a segmentation scheme that they should manage

V A L U E

Low

across the customer base. BUT it’s not—it’s only half the story!

‘Zero ’ . Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.3

T h e C u s t o m e r Va l u e P y r a m i d

such as marketing campaigns tailored for specific offerings or deals have much higher success rates over time due to greater customer response. Targeted and Appropriate Cross-Selling, Up-Selling, and Retention Programs Undisciplined mass-marketing efforts can cost more than the incremental revenues from new business they bring in. That is, the ROI on some marketing can be negative. Spray-and-pray marketing to broad undifferentiated segments of customers is out. They can also be a turnoff to customers whose mailboxes are bursting with offers. Micro-segmenting is in—with the smallest micro-segment being an individual or a household. Using the foundation of a single customer view, an understanding of customer value and profitability drivers, and a refined customer segmentation scheme, a company can use sophisticated analytic software to predict “what next?” for individual customers. Analytic software allows a company to build predictive models based on customer segment characteristics and outcomes (i.e., demonstrated behaviors), and then apply those models to other customers to determine which customers are good candidates for similar cross-selling and up-selling offers, as well as which customers may

Attitudinal/Behavioral Dimension Conservative simple outlook

Sophisticated but safe

Sophisticated high-risk / highreward outlook

Young/Single Young Family Older Family Empty Nester Retired 237

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.4

A Segmentation Matrix

Unsophisticated high-risk outlook

238

chapter 6

how to measure and manage customer value

be at risk of leaving–either defecting to competitors or no longer purchasing products or services. The CIO must provide users with tools to facilitate these types of models based on an understanding of their uses. Market basket analysis allows an organization to predict likely candidate customers for cross-sell opportunities given historical data on products and service lines previously purchased by customers, as well as customer demographics, purchase patterns, and other telling variables. Continuing with a bank example, one can identify the purchase stream path certain customers take starting from simple checking and savings accounts upward to more profitable automobile loans and home mortgages. Market basket analysis can lead to insights and potential inputs to predictive models and clusters to identify with greater confidence cross- and up-sell opportunities. This kind of analysis helps companies understand product affinities by looking for an association between the purchasing of one product or standard service line and another. This association can be detected if two products or services are sold at the same time or even if there is a time lag between purchases. Either way, organizations can identify cross-sell and up-sell patterns and then create models to predict this behavior with more certainty. These models can then be identified to aid targeted marketing campaigns aimed at increasing customer value. To be clear, market basket analysis and predictive modeling differ in that market basket analysis is more exploratory for learning, whereas predictive modeling applies scoring of customers that enables rule-based decisions for actions. Retaining profitable and potentially profitable customers is a top priority. Analytics like these examples can be used in a similar way to identify which customers are likely to leave and why—information that can then be used to target effective customer care and retention programs to ensure that the best customers remain with the organization. This ability to predict which customers are likely to defect to competitors—and address the drivers before they become issues—can be a critical competitive differentiator. Effective Marketing Delivery Systems After a company understands its customer profitability and their drivers and develops risk mitigating actions and programs appropriate to serve

foundation for customer portfolio management

239

their segment characteristics, then they need to apply an array of effective marketing mechanisms to deliver the right offer to the right customer at the right time at the right cost. Fortunately, there are commercial software providers with solutions to accomplish just those objectives for the CIO to evaluate in concert with IT organization’s customers: • Marketing automation software helps companies plan, automate, execute, and measure marketing campaigns. Advanced analytic software integrates with the “single view” customer database, as well as the processes and analytics used to assess customer value and profitability, to develop segments and appropriate cross-sell, up-sell, and retention programs. • Interaction management software enables marketers to immediately respond to changes in individual customer behavior to execute realtime cross-sell, up-sell, and retention strategies. Sophisticated algorithms can track and recognize changes in individual customer behavior and create real-time triggers and alerts that enable businesses to take instant action. For example, upon an inbound customer phone call to a call center, the customer service representative can follow rule-based instructions to offer deals or offers to entice the customer to purchase more. • Marketing optimization software helps companies model and assess the cost/benefit trade-offs of increasingly sophisticated and frequent customer communications. It can provide insight on how marketing constraints affect profitability and can recommend the best assignment of offers to customers to maximize profitability (or some other objective) given defined constraints. Though many of these software offerings are fairly new, the best ones integrate with marketing automation software to ensure a closed-loop marketing delivery system. The use of real-time customer behavior to improve customer retention and increase cross-sell and up-sell revenue gives companies an opportunity to take a major step toward one-to-one customer communications. Best practice CIOs increasingly take advantage of technology’s ability to provide real-time data.

240

chapter 6

how to measure and manage customer value

realigning the organization around customers rather than products Even when armed with fresh customer insight, companies fall short if this knowledge does not become a central part of the organization’s everyday work activities and priorities. Where are companies dropping the organizational ball? It starts with managing the customer experience. For example in a bank, from relationship managers and call center representatives to segment managers and ATM machines, the bank must deliver a positive and consistent experience to high-value and high-growth customers. In doing so, the entire organization works together to increase customer value, loyalty, and profit. The majority of companies continue to organize around product groups or lines-of-business rather than customer groups. Such organizational misalignments create poor customer experiences with real financial impacts. Organizational realignment around customer value cannot happen without technology. Fortunately, technology has matured to the point where it can collect and distribute the customer intelligence needed to keep employees focused on building customer value. When a breakdown does occur, it is because technology is not tied to a focused strategy of acquiring, retaining, and growing the right customers. The CIO can help correct this. Technology cannot do its job if the lines-of-business are working independently with separate solutions and business rules. Technology’s role is to integrate data, processes, and people to gain a single view of customers. The best approach is to deploy a suite of solutions that deliver analytics based on rigorous data management. A single technology platform is the organizational backbone for rolling out business rules on how to identify and treat high-value and high-growth customers. In CIO jargon, some refer to this platform as a unified meta-data repository. CIOs must be moving their IT infrastructures so their applications and analytics can access data this way. Ownership, accountability, and performance measures are another important piece of the puzzle. It must happen at the management level and the customer-facing level. This is where the strategy maps and Balanced Scorecards discussed in Chapter 5 fit in. Once the company has accurate customer value scores and tracking mechanisms in hand, managers can

preparing for customer analysis integration

241

establish the strategy, processes, and policies for increasing that value and managing the customer experience. It is then up to customer-facing teams to coordinate to implement management’s strategic intent and directives. The company is now in a position to incent, reward, and assess performance based on changes in customer value. Rather than traditional volume-based benchmarks, such as sales, companies can ask “how much has the profitability of the customers under your watch changed?” Realignment around customers involves balancing a product-driven environment with manageable steps to make better use of customer insight. By mapping the experiences of customers across channels and at each stage of the customer life cycle, a company gets a clearer picture of where the gaps in execution are taking place. It can then identify which organizational capabilities it must improve upon to close the gaps, including people, processes, infrastructure, and culture. The final step is to prioritize the needed capabilities and draw action plans for achieving results in a manageable time frame.

preparing for customer analytics integration Executives must evaluate their company’s ability to proactively manage its customer portfolio. They should ask some of these questions: • Can we build a single view of our customers using all available data sources? How quickly can we merge an acquired firm’s data into ours? And with what level of data integrity? • Do we understand the profitability (and drivers) of our existing customers? Are we more product-centric than customer-centric in our understanding of profitability? • How do we create and target customer segments? Is each defined segment distinct and manageable? • If we acquired a company today, could we rapidly determine which of our customers might be interested in a unique product offering of the acquired company? Likewise, how long would it take to tailor a pitch to our new customers about products we currently offer? How would we identify those desirable customers who are at greatest risk of leaving?

242

chapter 6

how to measure and manage customer value

• Can we create high-volume, opt-in e-mail campaigns that provide a highly personalized communication with compelling response rates? • Can our managers and customer service reps access customer profiles on their desktops, allowing for smarter customer interactions? Affirmative answers to these questions and the ability to execute customer-centric strategies can mean the difference between meeting or disappointing the expectations of shareholders and owners. Customer value insight drives success. Measuring and acting on customer value is proven to deliver higher profitability, organic growth, and competitive advantage. But the why behind customer value is not the problem. It is the how that gets overlooked. The result is that most companies have not captured the substantial benefits from more loyal and profitable customer relationships. At least not yet. By refocusing customer strategy, retooling measurement mechanics with aid from the CIO function, and taking steps to realign the organization around customers, companies unlock the vast profit potential of the customer asset. They retain and grow existing customers and acquire new high-potential customers that drive the greatest amount of profit today and in the future. Lasting competitive advantage is not far behind.

part 3 distinguishing high from low economic customer value Why Do Customer-Related Costs Matter? Increasing shareholder wealth comes down to three areas: costs, potential customer value, and customer needs. When companies do not sufficiently understand these three areas, they end up placing customers into the wrong value buckets. This ripples out to sub-optimal managerial decisions, the misallocation of marketing and sales resources, and the familiar outcomes of lower profits, slower growth, and no competitive advantage. The CIO function plays an important role merging these three areas. “The only value your company will ever create is the value that comes from customers—the ones you have now and the ones you will have in the future,” state Don Peppers and Martha Rogers, Ph.D. in their most recent book, Return On Customer .2 “To remain competitive, you must figure out

distinguishing high from low customer value

243

how to keep your customers longer, grow them into bigger customers, make them more profitable, and serve them more efficiently.” Over time, enterprise value goes up because the company is maximizing its Return on Customer sm.2 Increasing the profitability of each customer, not simply products and service lines, is a way to sustain long-term economic value growth for the enterprise and its investors. How many customers does it have? How much profit is it earning from each customer (or at least each customer segment) today and in the future? What kinds of new customers are being added and what is the growth rate of additions? How and why are customers migrating through segments over time? As a result of varying customer demands for different levels of service, the cost-to-serve component of each customer’s profit contribution requires measurement and visibility. As widely varying customization and tailoring for individuals becomes widespread, how will companies distinguish their profitable customers from their unprofitable ones? In a sense, it is these customers who are partners selected to grow the supplier’s business and wealth creation. Companies now need financial measures for how resource expenses are uniquely consumed, below the gross margin line for product costs, by each diverse customer. The problem, however, is that managerial accounting systems of most companies concentrate on product or service line costs (which are often flawed and misleading by arbitrary broad-average-based cost allocations) because regulatory financial accounting rules (i.e., GAAP) require compliance (see Chapter 4). But when it comes to the below the gross margin line expenses, such as distribution channels, sales, and marketing, the accounting rules require these expenses to be recognized during the month period in which they were incurred; they cannot be capitalized and stored in the balance sheet as inventoriable product costs can. Accountants refer to these as period costs. But classifying expenses that way is for external financial accounting for banks, investors, and regulatory agencies. The discussion here focuses on internal managerial accounting to support the analysis and decision making of managers and employee teams. The accountants must begin applying the same costing principles for product costing, typically based on activitybased costing (ABC) principles, to types of channels and types of customers so that there is visibility to all traceable and assignable costs. Otherwise, the company has no clue where it is making and losing money.

244

chapter 6

how to measure and manage customer value

Today, services are increasingly being added to products, and unique services are being tailored for individual customers. ABC data is essential to validate and prioritize the financial merits of which services to add and for which customers.

all customers are not created equal There is an unchallenged belief that focusing solely on increasing sales dollars eventually leads companies to depressed profitability. I support this belief. What matters is a mind-shift from pursuing increased sales volume at any cost to pursuing profitable sales volume. Some customers may purchase a mix of mainly low-margin products and service lines. After adding the “costs-to-serve”, such as phone calls for customer service, transactions exclusively in high-cost channels or special delivery requirements, these customers may be unprofitable. Other customers who purchase a mix of relatively high-margin products may demand so much in extra services that they also could potentially be unprofitable. How does one properly measure customer profitability? How does one migrate unprofitable customers to profitability or de-select them and eventually “urge them out”? After the less profitable customers are identified, how can they be managed toward higher profitability? How can profiles of existing highly profitable customers be applied to attract new customers with similar characteristics? If each customer’s value is not known, then the company is likely misallocating resources by underserving the more valuable customers, and vice versa. To answer these questions, the company must first properly measure its level of customer profitability (or at least segments of customers). To be competitive, a company must know its sources of profit and understand its cost structure. The CIO and IT organization must provide systems to facilitate this understanding. For outright unprofitable customers, a company should explore passive options of substantially raising prices or surcharging its customers for the extra services. In most cases, this establishes a “market-driven” value proposition between the company and the customer, resulting in either a profitable customer or intentional customer attrition by terminating the relationship. Remember, sending an unprofitable customer to your competitor isn’t a bad thing. For profitable

all customers are not created equal

245

customers, increased profit margins can be accomplished by doing the following: • Manage each customer’s costs-to-serve to a lower level. • Improve and streamline customer-facing processes, including adding self-service models where possible. • Establish a surcharge for or re-price expensive cost-to-serve activities. • Reduce services; focus first on labor-intensive ones that add the least value yet cost the most. • Introduce new products and service lines. • Raise prices. • Abandon products or service lines. • Improve and streamline internal business processes. • Offer the customer profit-positive service-level options with varying prices. • Increase investments on activities that a customer shows a preference for. • Up-sell or cross-sell the customer’s purchase mix toward richer, higher-margin products and service lines. • Discount prices to gain more business with low cost-to-serve customers. But to accomplish these actions, a company first needs fact-based data about its profits and costs. With this, management will have reliable cost information that can be used to build solid business cases for actions instead of relying on potentially risky intuition or hunches or, worse yet, flawed and misleading cost data. Focusing on the most valuable and most “growable” customers in the short- and long-term can have a large impact on the bottom line. However, many marketing retention and acquisition programs indiscriminately address the entire base rather than effectively center on the more profitable customer segments. Having a way to value different types of customers is powerful for developing customer-centric strategies and subsequently determining what level of priority and effort to engage each customer segment.

246

chapter 6

how to measure and manage customer value

should we pursue the most profitable or the most valuable customers? The goal of marketing is to not only identify potential new customers, but to reach out to existing customers through cross-selling (e.g., When I sell you golf clubs, I try to sell you a golf glove) and up-selling (e.g., When I sell you a boat, I sell you an extended warranty option with it). Maximize the value of the relationships the company already has. This is referred to as “organic” growth. Metrics to evaluate customers might include retention (loyalty) rates, attrition rates, churn propensity, and the marketing standard metrics trio of a customer’s purchase history: recency, frequency, and monetary spend—or RFM. Indirect considerations can include a customer’s referral propensity to recruit new customers. Of course, there is a myriad of other sociodemographic (e.g., age, income level, gender) and attitudinal variables that marketers analyze about their customers to understand their tastes and preferences. Analytical tools are becoming essential for marketers to formulate tailored marketing campaigns to the customer segments defined by their analysis. The CIO and IT organization must increasingly provide effective analytic tools for its user community for purposes like this. Exhibit 6.5 illustrates that just knowing the existing level of profitability for a customer may not always be sufficient. For some kinds of existing customers, such as a young promising dentist or imminent university graduate, their potential future profit as a customer is sizable. However, their current level of profitability does not reveal this. In contrast, for an established dentist near retirement, she may currently be a very profitable customer, but her longer-term value will not be substantial. Therefore, the future potential of a customer, measured along the horizontal axis in each image of Exhibit 6.5, should also be considered. Each quadrant in Exhibit 6.5 suggests different types of actions and treatments to take toward a type of customer to improve profitability. Exhibit 6.5 also displays how the customer data points can be rankordered into a single customer financial value score based on each customer’s distance from the upper-left corner, where the most valuable customers are located. The challenge is to determine the profit return on spending opportunities in order to shift customers to the upper-left corner to increase shareholder wealth.

EXHIBIT

6.5

C u r r e n t v s . L o n g - Te r m Po t e n t i a l C u s t o m e r

Va l u e

247

248

chapter 6

how to measure and manage customer value

caution to not misinterpret the data There can be risks to automatically acting based on a customer’s current quadrant location in this matrix. For example, one could misjudge a customer with current low profits as being low future potential and abandon them, thus missing substantial future profit opportunity. For a high future potential customer, one might unwisely entice them with loss-leaders only to not have profit-followers to recoup the losses or, worse yet, lose their business to a competitor. Reacting to a customer’s quadrant location can also get complicated. For example, if a student, currently an unprofitable bank customer but the niece of her highly profitable aunt, requests her bank to match an auto dealer’s low loan rate offer to thus making her more unprofitable to the bank, should the bank reject the niece and jeopardize the relationship with her aunt? Or does the bank accept her seeing the potential to cross-sell (e.g., credit card) and generate longterm profits? Another risk may be revealing too much about your decisionmaking process to customers, potentially appearing foolish or mean. Customer intelligence systems using data mining techniques can be designed to send data into the operational CRM systems derived from the profitability data. So, for example, a bank teller should not say to a customer, “You’ve got a low profit score, so therefore I cannot waive your service charge” but rather say, “I’m sorry, but we already extended our one-time courtesy waiver, so I can’t waive your service charge at this time.”

The more advanced-analytic organizations have become competent in measuring current period customer profitability—the vertical axis of Exhibit 6.5. The activity-based costing (ABC) methodology and its supporting technology provide the capability to trace and assign the unique consumption of cost that customers, channels, services, and products draw on the organization’s resource expenses—their salaries, supplies, and so on. CIOs whose CFO has yet to pursue ABC need to investigate if the CFO’s reason for not pursuing ABC is justified or simply due to the fear of too much extra work or some other misconception. Later this chapter discusses

measuring customer lifetime value

249

the challenge of locating customers along the horizontal axis—measuring the long-term potential financial value of a customer. Knowing where customers are goes to the heart of customer relationship management systems. Decisions should be made considering the more valuable customers, not just the currently more profitable customers. These examples involve balancing current customer satisfaction with shareholder and owner wealth creation demands—and both involve tradeoffs among short-term and long-term decisions: • Achieving customer satisfaction and intimacy—Gaining customer loyalty is more than offering “bribes” with perpetual discounts. Loyalty must be earned, not bought. • So-called “loyalty” programs are typically just frequency programs lacking intimacy. • Increasing the company’s profitability—How do we apportion our marketing spend between customer retention and new customer acquisition or recovery (i.e., win-backs)? The sales and marketing functions increasingly require more financial information for trade-off analysis. Measuring customer lifetime value is an important source for financial information.

part 4 measuring customer lifetime value Customer Lifetime Value—Viewing Customers as an Investment To consider the future profit potential of customers, marketing and sales functions have begun exploring an equation called “customer lifetime value” (CLV) that treats each customer (or segment) as an investment instrument— similar to an individual stock in a portfolio. There can be winners and losers. Because changes in customer behavior are usually not volatile, CLV can be useful to understand profit momentum. Unlike financial statement reporting, CLV measures are not interrupted by “one-time charges” and other short-term but substantial financial statement surprises. CLV links customer revenues to organizational profits. They should never be assumed to always go in the same direction because, as mentioned earlier, high-maintenance customers can be unprofitable regardless of their sales volume.

250

chapter 6

how to measure and manage customer value

CLV is a forward-looking view of wealth creation. CLV can be defined as the net present value of the likely future net positive cash flow stream from an individual customer. This involves multi-period discounted cash flow (DCF) investment evaluation math, not just a single period. This math gets trickier than measuring historical customer profitability levels because the company needs to consider factors other than what happened in the past month, quarter, or year. CLV also considers the probability of losing some customers. By using DCF math, companies can equate the future stream of net positive cash flow (which are indirectly profits) into a single cash amount (i.e., the expected value) of profit stated in today’s money. One appeal of CLV is that it focuses on the customer as the influencer of a company’s profitability rather than only the products and service lines that are purchased (although they are included in the CLV equation). Another appeal of CLV is it can also be applied to evaluate which new customers, not just existing ones, to target and attract through marketing campaigns, and more importantly, to determine how much the firm can afford to spend on acquiring new customers based on their CLV. Exhibit 6.6 illustrates some of the tactical actions mentioned earlier that a company may take to lift the profitability of a customer relative to the customer’s current expected life cycle. CLV synthesizes current level of customer profitability, future potential, and attrition probabilities at the level of an individual customer or household. Customers can exercise their rights to switch to from one supplier or service provider to another. A good example is in the telecommunications industry–cell phones in particular–where annual churn rates can be 30% of the customer base and the relative cost to acquire a new customer can be multiples of the cost to retain an existing one. Predictions of customer attrition are critical because that event terminates any further stream of revenues and associated costs. Industries such as in telecommunications and banking are becoming increasingly competent at developing survival curve models to predict attrition. CLV can be implemented in multiple ways. It can be used as a customer segmentation tool to segment customer value. It can also be used to segment customers by their churn behavior (i.e., likelihood do terminate being a customer). CLV can also be used to measure marketing campaign effectiveness. For existing customers, CLV can help companies develop customer loyalty and treatment strategies to maximize customer eco-

+$ Better crossand up-selling

More effective customer retention

cash flow (after)

More efficient acquisition

cash flow (before)

$0 Intensify

−

Acquisition Cost

$

Retention

Termination & Recovery

Stages

251

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.6

Leveraging Customer Life Cycles

252

chapter 6

how to measure and manage customer value

nomic value for the company’s shareholders. For newly acquired customers, CLV can help companies develop strategies to grow the right type of customer. Exhibit 6.7 illustrates ten revenue and cost elements that determine the CLV of a customer segment over its lifetime. Ideally, the marketers tailor marketing campaigns and differentiated services and offers to assure this planned CLV of each segment is realized. Understanding the CLV of existing customers allows creating profiles, based on characteristics of customer segments, to attract similar types of new customers. Exhibit 6.8 displays the cumulative CLV of all existing customers and potentially newly acquired ones. The exhibit illustrates actions and priorities reflecting decisions made for the ten elements in Exhibit 6.7. All customer segments should be managed for higher value, but the strategies will differ depending on the segment. The graph line is rank-ordered from the highest to lowest CLV customer. The most valuable customer segments should be protected—their retention being a high priority. Earning their loyalty is critical. Growing value from valuable customers comes next. The less valuable customer segments should be managed for higher returns. For new sales prospects, marketing can allocate appropriate budget to acquisition programs to attract customers with “clone” characteristics to valuable existing customers. The marketing budget spending should focus on higher payback rather than on potentially unprofitable sales prospects. In effect, just like a factory, work to achieve the highest profit yield for each incremental amount of spending in sales and marketing. Exhibit 6.9 illustrates that calculating CLV involves assumptions and forecasts with uncertainty. Even with customers segmented, forecasting models can be quite sensitive to assumptions. For example, how long will an active customer continue the relationship? How much and when will an active customer spend? If a customer is inactive, is it temporary or did they switch to a competitor? If so, what and how much are they purchasing from a competitor? They may spend $100 with you, but $500 with your competitor. For these last two questions, a company only sees its own data, not external data, forcing it to make assumptions about the missing data. But that simply means the need to gain more competency in statistical forecasting. It is inevitable that to truly manage performance a shift in competencies will be from control to planning.

+

− (1) − acquisition cost

$

(2) + recurring revenues (3) − recurring cost to serve (4) + up-selling, cross- selling (5) − credits, returns

Possibilities throughout customer’s “lifetime ”: (9) churn

(6) − renewal & retention promotions

(10) Win-back

(7) − downward migration (8) − bad debt and/or removal costs = Customer Lifetime Value

= CLV $

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

253

EXHIBIT

6.7

D e t e r m i n a n t s o f C LV

Source: “Going the Distance with Telecom Customers ”; The McKinsey Quarterly ; 2003 Number 4

254

Customer Equity $

CLV (or CP) is calculated and rank-ordered. Be prudent attracting new customers.

Be selective pursuing these Get more value from these

Protect these

Source: Customer Equity Marketing; European Mgmt. Journal ; Vol 20, No. 3; June, 2002

Existing Customers Retain

Develop, Streamline

Possible New Customers Acquire, Retain

Do not acquire

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.8

C LV Va l u e C r e a t i o n

$ Value of an existing customer

Present Value

Future Value

Potential Value

Forecast & Uncertainty Today

Time End of prediction period

255

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.9

C LV D e p e n d s o n P r e d i c t i o n s

256

chapter 6

how to measure and manage customer value

customer lifetime value— investment analysis math Customer value management (CVM) is becoming a buzzword among marketers and is based on CLV math. CVM is an acquisition and customer retention management approach geared to economic value creation for shareholders. As mentioned earlier, a challenging task is to locate customers along the horizontal axis in Exhibit 6.5—measuring the long-term potential financial value of a customer. This requires a mindset change to begin viewing a customer as an investment. Similar to managing equity stocks in an investment portfolio, some types of customers may be big winners while others disappoint. In accounting and finance, evaluating investments requires calculating future streams of revenues and their associated costs. In contrast to calculating the profit from the past month, quarter, or year—a descriptive view—calculating projected financial returns involves discounted cash flow (DCF) math that considers both the timing of future cash inflows and outflows as well as the cost of capital. If the financial interest rate is 10 percent, then $1.10 a year from now equates to $1.00 today. Exhibit 6.10 displays an equation for computing a customer’s value score as being the sum of the CLVs for both existing and future customers. Challenges with Using CLV Math There are some questions, challenges, and difficulties involved with computing CLV. For example, the CLV equation works assuming that the start time for measuring it begins with today. Given this, do you need to go back in time and determine what the historical acquisition cost was for existing customers? And how would you derive that amount? Or alternatively should you treat past acquisition costs as a sunk cost? Also, how should you assign retention-related expenses? How many periods into the future should be used because CLV is a discounted cash flow investment calculation, not a past period static one? The resolution to the confusion here is solved when you recognize there are different assumptions based on different questions. The DCF of a customer’s future purchases net of the costs to service the customer is synonymous with the term customer lifetime value (CLV). Calculating the DCF of a customer is not as complicated as one may imagine. Although Exhibit 6.11, an example of a DCF equation for measuring future customer value, may initially appear highly theoretical and

CE = ∑ CLV $ existing customers + ∑ CLV $

new customers

Where CLV is “the net present value of the likely future profit stream from an individual customer. ”*

CLV $ =

( − acquisition cost)

+∑ (monthly $ margin)

adjusted for probable number of years of retention * Peppers and Rogers Web site glossary EXHIBIT

6.10

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

Customer Equity (CE) Involves Math

257

258

Future Value

Present Value t =T

CLV

k

=∑ t =0

CLV k Et At k t (t=0) T i

E tk − Atk ( 1 + it ) t

=

(

E 0k

−

A0k

)+

E 1k − A1k ( 1 + i1 ) 1

+

E 2k − A2k ( 1 + i2 )2

+ ... +

ETk − ATk ( 1 + iT )T

= customer lifetime value of a customer k = revenue from a customer k = expenses for a customer k = customer k = time period (t=0, 1, 2, … ) = today = predicted duration of a customer’s relationship = interest rate . Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.11

Calculation of a CLV Can Be Complex!!

Segment

Year 1

Year 2

Year 3

(A) Sales Prod 1 Prod 2 Prod n

$1 = qty x price $2 = qty x price $n = qty x price

$1 = qty x price $2 = qty x price $n = qty x price

$1 = qty x price $2 = qty x price $n = qty x price

(B) Costs Products Channel Cost-to-serve

∑ $n = qty x cost ∑ $n = qty x cost ∑ $n = qty x cost $x = qty x cost $y = qty x cost

Profit =

A–B

∑

DCF =

$x = qty x cost $y = qty x cost

A–B

$x = qty x cost $y = qty x cost

A–B

(A – B) for t at i=10%

259

Factor in probabilities for the (1) quantities of unit sales and activity cost drivers for each segment and year, (2) churn date, (3) credit events, (4) etc. … and calculate and sum! Copyright © 2006 SAS Institute Inc. (gary.cokins @ sas.com) All rights reserved. EXHIBIT

6.12

Is CLV Math Really That Difficult?

Customer Segments

260

chapter 6

how to measure and manage customer value

intimidating, Exhibit 6.12 recasts key elements of the equation into a more comfortable spreadsheet view. The equations basically quantify the price less cost for the expected purchased volume of each product or standard service line less the cost-to-serve (including the cost-to-maintain). These costs are calculated for each customer (or more manageable for each customer segment), and then factored for probabilities. Assumptions and forecasts with uncertainty are involved with calculating CLV. Even with customers segmented, forecasting models can be quite sensitive to assumptions for each segment. For example, how long will an active customer continue the relationship? How much and when will an active customer spend? If a customer is inactive, is it temporary or did they switch to a competitor? If they switched, what and how much are they purchasing from a competitor? They may spend $100 with you, but $500 with your competitor. For these last two questions, you only see your data, not external data, forcing you to make assumptions about missing data. But that simply means you need to gain more competency in statistical forecasting. It is inevitable that to truly manage performance, then a shift in competencies will be from control to better planning and forecasting. In CLV calculations, the difficulty with determining the length of the proper planning horizon can be resolved by simply limiting it to only a few years—perhaps just three to five years. With DCF’s “net present value”, the impact of time on the “expected value” diminishes quickly. I would not endorse starting off with elaborate CLV equations as in Exhibit 6.11. An organization can begin with simpler equations, using computer modeling, and use estimates for some of the elements in Exhibit 6.7. The benefits will be more in the organization’s learning about how to view its customer segments and how to think about the probabilities for elements such as churn and win-backs.

part 5 balancing shareholder value with customer value Evaluating Customers by Combining Their Financial Value with Loyalty Characteristics Knowing customer loyalty is important because the degree of loyalty directly influences the amount of spending that may be required to retain the customer as an existing customer. Advanced-analytics companies use business intelligence (BI) software technologies to understand psycho-demographic

balancing shareholder value, customer value

261

characteristics of customers to predict their future behavior. The CIO is often the catalyst to recognize the need for BI tools for purposes like these. It is not unusual for the customer analytics departments in companies with progressive BI tools to claim the accuracy of their customer “survival” (i.e., defections) projections is reliably high. They can almost predict by name which customer is likely to defect—the question remains, is it worth the extra cost to attempt to retain them? Are they worth it for the shareholders to benefit? The lower portion of Exhibit 6.5 equated the two-axis data points of the upper and middle portions into a single customer financial value score in order to combine the customer financial value information with nonfinancial information about degrees of a customer’s loyalty. Exhibit 6.13 places the high-to-low rank-ordered customer financial value score from the lower portion of Exhibit 6.5 on the vertical axis and combines it with a customer loyalty score on the horizontal axis. With both pieces of

The spending on “actions” to acquire or retain customers should be proportional to their loyalty and churn propensity.

High

High $ …… Low $

C u s t o m e r V a l u e

High value offer

Low value offer

No Offer

High value offer

Low value offer

Low Loyal

Churn Score

Not Loyal

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.13

C o m b i n i n g C u s t o m e r Va l u e w i t h L o y a l t y

262

chapter 6

how to measure and manage customer value

information reported about a customer, the location of that customer’s intersection in the Exhibit 6.6 grid implies the level (and associated cost) of offering incentives, deals, discounts, and the like to retain the customer’s ongoing revenue stream from their purchases. Less loyal customers will require, if deemed worth it to do so, relatively higher retention spending— and vice versa. The controllable variable becomes how much to spend. How does the integration of customer financial value and loyalty translate into decisions and actions? Stepping back, companies must realize that the spending budget for sales and marketing is critical, but that spending must be treated as a preciously scarce resource to be aimed at generating the highest long-term profits. This means answering questions like, “Which type of customer is attractive to newly acquire, retain, grow, or win back? And which types are not?” Then, after identifying the valid types of customers to target (and rejecting those types to not target), “How much should we spend attracting, retaining, growing, or recovering each targeted customer segment?” The last question is the needed calculus that leads us to next point—maximizing shareholder wealth.

the trade-off between customer value and shareholder value creation or destruction That last question includes determining how much sales and marketing spending is too much or too little. This is the first derivative of calculus— similar to what acceleration is to velocity. It is about the next increment of change—up or down. What impact do I get by spending an extra dollar or Euro on each customer or by reducing that planned spending by an extra dollar or Euro? Exhibit 6.14 expands on Exhibit 6.13 by indicating that not only can there be various levels of marketing spending for each segment, but also that too much or too little spending can destroy shareholder wealth. The added graph on right side of the exhibit visually displays these trade-offs as an optimization problem intended to maximize shareholder wealth. Combining customer financial value scores with customer loyalty measures can determine the optimal level of marketing and sales retention spend for each customer cluster. However, today most senior managers treat customer intelligence analytics as a harmless curiosity in a permanent phase of

For optimal spending, to who and how much do we spend to maximize shareholder wealth creation? High

High …… Low

C u s t o m e r V a l u e

Rich

High value offer

Low value offer

No Offer

High value offer

Low value offer

S h a r e h o l d e r

W e a l t h

Poor

Low Loyal

Churn Score

Not Loyal

Low

Spending

263

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.14

Va l u e a n d L o y a l t y Tr a d e - O f f A n a l y s i s t o O p t i m i z e S p e n d i n g

High

264

chapter 6

how to measure and manage customer value

development and trials. As a result, these senior managers wonder if their situation is “should we know?” or “do we know?” It is incumbent on the CIO to educate senior management that these types of analytics are increasingly being adopted and to avoid falling behind the competition who may get a head-start jump where they cannot be caught. A company constantly interacts with its customers and their loyalty, both by actively pursuing them with new offers or deals and by passively assigning them to a customer segment that is entitled to a set of dormant offers— no actions or deals. How much is too much or too little? Excess spending can in some cases lead to shareholder wealth destruction. You can overspend on a customer to retain their loyalty, but potentially at a permanently lower (perhaps negative) long-term return on investment spending per customer. On the other hand, insufficient spending on a customer can also lead to shareholder wealth destruction. This is because the company risks losing that under-served customer to a competitor or risks its reduced spending frequency or amounts purchased, thus sacrificing the customer lifetime value for that customer. Are there skeptics that CLV math is too much ivory tower? Of course there are. Even the academics have yet to deeply explore these interdependent relationships. Here is a quote from an academic journal: Customer value management can be regarded as the key driver of Shareholder Value . . . (but) surprisingly, although being of obvious importance, literature taking a more comprehensive view of customer valuation has only recently been appearing. A composite picture of customers and investors is hardly found in business references.3

However, such skepticism may be unwarranted. For example, although survival analysis modeling (a component of CLV) appears challenging, more and more companies involved with subscription renewal customers are achieving competency with these projections. Further, the concept of integrating customer value and shareholder value is being addressed by the leading authorities in the field of customer relationship management, Don Peppers and Martha Rogers. Here is a quote from their 2005 book, Return on Customer:4 A higher promotion budget might improve customer acquisition. But each new acquisition will be more expensive. It’s possible to wind up

clv or only customer profitability?

265

spending more than a new incremental(ly lower profit) customer will ever be worth. Creating value from customers is an optimization problem. Often, however, the tradeoffs occur in terms of generating increased future cash flows with adverse results of reduced current cash flows, or vice-versa. . . . If CLV doesn’t improve enough to offset increased costs, then value will be destroyed, even as loyalty improves.

By integrating customer relationship management with shareholder wealth creation and destruction, both of these topics are placed into the context of performance management.

clv or only customer profitability? when is clv applicable? CLV is understandably perceived as difficult to calculate with any degree of certainty. It is also perceived as hard to use. Hence, those managers who are cognizant that customers generate different profit levels relative to their sales typically only have confidence in a customer’s current profitability— that is, if their accountants are measuring it—which most do not. So is it feasible to measure CLV, and is it practical to try? For some companies, periodic customer profitability reporting with ABC can be a sufficiently good proxy or surrogate for the CLV measure. This could preclude any need to get more sophisticated. Others may see usefulness in calculating CLV, but wonder if the climb is worth the view—that is, will the benefits from using the data outweigh the administrative effort to collect and compute the data plus train employees how to use it? Companies with ABC systems have proven they can repeatedly and reliably report and score customer profitability information. The benefits with actual customer profitability reporting come from the insights managers and analysts gain by comparing profiles of customers with varying degrees of profitability. This information alone, particularly for business-tobusiness (B2B) companies whose customers do not experience life cycles, may be sufficient to formulate new marketing strategies and to budget future marketing spending for higher payback. CLV is more applicable when a company has a database with customer profiles and their transaction history data. That is, the company already

266

100%

How much more is learned?

0% Little

Modest

Great

Level of CP/CLV Sophistication CP

CP + CLV

. Copyright © 2006 SAS Institute Inc. ( gary [email protected]) All rights reserved.

EXHIBIT

6.15

U s e C u s t o m e r P r o f i t a b i l i t y a s a P r o x y f o r C LV ?

the cfo and cio must shift emphasis

267

knows a lot about them. CLV is less applicable if a company works through B2B sales channels that preclude a direct relationship, and hence intelligence, with end-consumers. That is, it may be sufficient to simply begin with measuring current profitability for existing customers rather than advance to the more sophisticated CLV. Exhibit 6.15 illustrates the rate of learning about a customer’s value relative to the level of analytical sophistication. It implies that much can be learned just with measuring customer profitability and applying rankorders to formulating marketing strategies. Beyond that, adding CLV insights about future potential can add to the learning and enhance formulating even better marketing strategies. Much can be learned just with measuring customer profitability and applying rank-orders to formulating marketing strategies. Beyond that, adding CLV insights about future potential can add to the learning and enhance formulating even better marketing strategies. There should be little argument, given the power of computers and data warehouses, that computing CLV with some degree of accuracy is feasible.

part 6 the cfo and cio must shift emphasis The CFO and CIO Must Serve the CMO and Sales Director This discussion began by stating that senior management has had unquestioned views that marketing and advertising is something the company must spend money on—but how much money? How much is too much? Where is the highest payback to focus and where to avoid? It is inevitable that the answers to these questions require a contribution from the business analysts using managerial accounting techniques. The day is coming that the CFO, supported by the CIO, must now turn their attention from operations and cost control to support the CMO and sales director to more intelligently focus on the right kinds of customers and sales prospects. The CIO faces challenges because there is confusion today about what the difference is between mainstream business intelligence5 (BI) and performance management (PM). Are BI and PM synonymous? Is BI a part of PM? Or is PM a part of BI?

268

chapter 6

how to measure and manage customer value

This ambiguity arises because the underlying inputs, processes, outputs, and outcomes of an organization—whether a public sector government agency or a commercial business—may arguably have some parts that belong to BI, while others belong to PM. The key word in that sentence was “arguably”. This argument arises because IT-centric people often see an enterprise as a ravenous consumer of billions of bytes of data intended to manage the business (a BI view). In contrast, leaders, managers, and employee teams typically view the same enterprise as an organism with a purpose and mission (a PM view); they desire solutions and applications that achieve results. How can BI and PM be reconciled? It is important that CIOs assist their organizations in answering this question.

how do business intelligence and performance management relate to each other? There are two things related to this topic that most people can agree upon: 1) BI involves raw data that must first be integrated from disparate source systems and then transformed into information; and 2) BI and PM leverage that information. In this context, information is much more valuable than data points, because integrating and transforming data using calculations and pattern discovery results in potentially meaningful information that can be used for decisions. The key point here is to apply analytics with BI and PM for better decision making. For example, an automobile manufacturer’s warranty claims can be globally analyzed to detect a design problem. In another instance, the history of an individual’s credit card purchase transaction data can be converted to information that, in turn, can be used for decisions by retailers to better serve the customer or provide customized offers to sell more to them. A survey by the global technology consulting firm Accenture reported that senior U.S. executives are increasingly more disenchanted with their analytic and BI capabilities.6 Although they acknowledged that their BI (regardless of how they personally define it) provides a display of data in terms of reporting, querying, searching, and visual dashboards, they felt their mainstream BI still fell short. An organization’s interest is not just to monitor the dials; it is, more importantly, to move the dials. That is, just reporting information does not equate to managing for better results; what

how do business intelligence and performance relate

269

is needed are actions and decisions to improve the organization’s performance. Having mainstream BI capability is definitely important, however, it often came about as the result of departments needing advances that the IT function could not provide. Extending BI across the organization so that mini-BI applications can talk is a mission-critical differentiator for organizational success and competitiveness. Some organizations refer to this extension as “big BI” to emphasize the importance of using analytic analysis with BI information and the portfolio of methodologies that comprise performance management. Professor Tom Davenport of Babson College authored a January, 2006 Harvard Business Review article proposing that the next differentiator for competitive advantage will be predictive analytics. He has coined the phrase, “competing on analytics.” His premise is that change at all levels has accelerated so much that reacting after-the-fact is too late and risky. He asserts that organizations must anticipate change to be pro-active rather than reactive, and the primary way is through robust quantitative analysis that is forward-looking. Predictive analytics becomes an obvious feature for BI and performance management to help an organization understand where it has been and why, and then to determine strategy-aligned actions for decision-making with realistic target-setting. Managing and improving are not the same things. Many people are managers, like a coach of a sports team, and they get by. Improving, on the other hand, is how an organization wins. To differentiate BI from PM, performance management can be viewed as deploying the power of BI, but the two are inseparable. Think of PM as an application of BI. PM adds context and direction for BI. BI is an enterprise information platform for querying, reporting, and much more, which when combined with the methodologies of performance management makes them both the foundation to drive organizational improvement with analytics. PM drives the strategy and leverages all of the processes, methodologies, metrics, and systems that monitor, manage, and most importantly, improve enterprise performance. Together, BI and PM form the bridge that connects data to decisions when powered by analytics. With PM, the strategy spurs the application of technology, methodologies, and software. As methodologies—which are typically implemented or operated in isolation of each other—are integrated, the strength and power

270

chapter 6

how to measure and manage customer value

of PM grows. Technologies, such as software that the CIO is responsible for installing, support the methodologies. Software is an essential enabler, but the critical part is in the thinking. That is, one must understand the assumptions used in configuring commercial software and, more importantly, have a vision of the emerging possibilities to apply the new knowledge that BI and PM produces. Ultimately it is advisable that organizations not waste valuable energy debating BI versus PM—they may get caught up in semantics—and agree that PM deploys the power in BI with its enterprise information platform so that organizations can advance from managing to improving.

optimizing the balance between customer value and shareholder value To maximize shareholder wealth, the company must dig much deeper than predicting income statements and balance sheets to compute “free cash flow” as the financial community does today. They must look at CLV and return-on-customer concepts as the core determinant (i.e., driver) of shareholder wealth creation, combined with these other factors—customers. CVM is a “bottom-up” rather than a “top-down” calculation. In summary, it is essential to have the analytical tools, such as for customer segmentation, loyalty analysis, forecasting, and activity-based costing for calculating customer value, reducing internal debates, and making tradeoff decisions. It is inevitable that a company’s executive team will navigate shareholder wealth creation based on facts, not hunches and intuition.

appendix 6A. Activity-Based Costing Is a Cost Reassignment Network In complex support-intensive organizations, there can be a substantial chain of indirect activities prior to the work activities that eventually trace into the final cost objects. These chains result in activity-to-activity assignments, and they rely on intermediate activity drivers in the same way that final cost objects rely on activity drivers to reassign costs into them based on their diversity and variation.

Network Salary, Fringe Benefits

Resources

Direct Material

Phone, Travel Supplies

Depreciation

Rent, Interest, Tax

(General Ledger view)

People Activities

Work Activities

Support Activities

(verb-noun)

Final Cost Objects

“Cost-to-serve ” paths

Equipment Activities

Products Services Business Sustaining

Suppliers

Customers

271

EXHIBIT

6.A

ABC/M Cost Assignment Network

272

chapter 6

how to measure and manage customer value

The direct costing of indirect costs is no longer, as it was in the past, an insurmountable problem given the existence of integrated ABC/M software, like the SAS Institute’s SAS ABM software. ABC allows intermediate direct costing to a local process or to an internal customer or required component that is causing the demand for work. ABC cost flow networks no longer have to “hit the wall” from limited spreadsheet software that is restricted by columns-to-rows math. ABC/M software is arterial in design. Eventually via this expense assignment and tracing network, ABC reassigns 100 percent of the costs into the final products, service lines, channels, customers, and business sustaining costs. In short, ABC connects customers to the unique resources they consume—and in proportion to their consumption. The ABC cost assignment network in Exhibit 6.A consists of the three modules connected by cost assignment paths. This network calculates the cost of cost objects (e.g., outputs, product lines, service lines, or customers). It is basically a “snap-shot” view of the business conducted during a specific time period. (Life cycle costing is described under the topic, “Customer Lifetime Value”.) Resources, at the top of the cost assignment network, are the capacity to perform work because they represent all the available means upon which work activities can draw. Resources can be thought of as the organization’s checkbook; this is where all the period’s expenditure transactions are accumulated into buckets of spending. Examples of resources are salaries, operating supplies, or electrical power. These are the period’s cash outlays and amortized cash outlays, such as for depreciation, from a prior period. It is during this step that the applicable resource drivers are developed as the mechanism to convey resource costs to the activity. “Expenses” must be distinguished from “costs”. They are not the same thing. All costs are calculated costs. It is important to recognize that assumptions are always involved in the conversion and translation of expenses into costs. The assumptions stipulate the basis for the calculation. Expenses occur at the point of acquisition with third parties, including employee wages. This is when money (or its obligation) exits the company. At that special moment, “value” does not fluctuate; it is permanently recorded as part of a legal exchange. From the expenses, all costs are calculated representations of how those expenses flow through work activities and into outputs of work.

notes

273

In sum, resources are traced to work activities. It is during this step that the applicable resource drivers are developed as the mechanism to convey resource expenses into the activity costs. A popular basis for tracing or assigning resource expenses is the time (e.g., number of minutes) that people or equipment use to perform activities. Note that the terms tracing or assigning are preferable to the term allocation. This is because many people associate the allocation with a redistribution of costs that have little to no correlation between source and destinations; hence to some organizations overhead cost allocations are felt to be arbitrary and are viewed cynically. The activity module is where work is performed. It is where resources are converted into some type of output. The activity cost assignment step contains the structure to assign activity costs to cost objects (or to other activities), utilizing activity drivers as the mechanism to accomplish this assignment. Cost objects, at the bottom of the cost assignment network, represent the broad variety of outputs and services where costs accumulate. The customers are the final-final cost objects; their existence ultimately creates the need for a cost structure in the first place. Cost objects are the persons or things that benefit from incurring work activities. Examples of cost objects are products, service lines, distribution channels, customers, and outputs of internal processes. Cost objects can be thought of as the what or for whom work is done. Once established, the cost assignment network is useful in determining how the diversity and variation of things, such as different products or various types of customers, can be detected and translated into how they uniquely consume the activity costs that draw on resource expenses. ■ notes 1. Peter F. Mathias and Noel Capon, “Managing Strategic Customer Relationships as Assets,” Velocity 5 no. 2 (1st quarter, 2003): 46. 2. Don Peppers and Martha Rogers, Ph.D., Return on Customer: Creating Maximum Value from Your Scarcest Resource, (New York: Currency/DoubleDay, 2005) 9. Return on Customers and ROC are registered service marks of Peppers & Rogers Group, a division of Carlson Marketing Group. 3. Bayon, Gutsche, and Bauer, “Customer Equity Marketing,” European Management Journal ( June 2002) 213.

274

chapter 6

how to measure and manage customer value

4. See note 2 above, pages 12-13. 5. The information technology community distinguishes between “little” business intelligence for query and reporting and “big” business intelligence for the platform where information is stored and managed. This chapter’s emphasis is on the latter. 6. Accenture.com, 2005 News Release; “Companies Need to Improve Business Intelligence Capabilities to Drive Growth, Accenture Study Finds” www. accenture.com/xd/xd.asp?it=enweb&xd=_dyn%5Cdynamicpressrelease_809.xml.

chapter

7

Consider the Outsource: Right from the Start by karl schubert

Outsourcing is one of the hottest topics in CIO circles today: a general online search yields tens of millions of hits; an online search through CIO magazine’s online Web site alone yields tens of thousands of hits; a similar search on Harvard Business Review Online yields nearly 200 hits. It is also a hot topic in professional circles. A search on the IEEE and ACM portals limited to the past three years yields more than 500 hits. Outsourcing is clearly one of the most significant topics for senior managers in all industries and enterprises of all sizes. Taking a step back from this overwhelming amount of information, what does outsourcing mean? This chapter investigates the many interpretations of outsourcing, but let’s start with the proper definition from Webster’s Online Dictionary:1 The practice of subcontracting manufacturing work to outside and especially foreign or nonunion companies.

Although Webster’s defines this as a noun, it is in practice more a verb: the entire process of proactively deciding and managing the what and why and how of business-to-business partnerships up front, during the ongoing activity in the middle, and while finishing up or cleaning up (if need be) at the end. Then there’s the approach to outsourcing: is it “outsourcing” or 275

276

chapter 7

consider the outsource

Enterprises Outsourcing Operations and Applications Total <$100M $100–$999M >$1B Revenue Revenue Revenue Yes 73% 65% 70% 88% No

27%

35%

30%

12%

Increase in 2005 over 2004

4.9%

3.5%

7.7%

3.2%

EXHIBIT

7.1

Outsourcing Spending Prevalence

“offshoring” or “outhosting” or “insourcing” or some combination of these? Perhaps first and foremost, is any form of outsourcing what you really need? In a recent survey by CIO Insight magazine summarized in Exhibit 7.1, nearly three-fourths of surveyed companies spent money outsourcing in 2004, and they expected their IT outsourcing spending to increase by almost 5 percent in 2005.2 The same survey asked how the monies would be spent across a wide range of categories with application and Web development, application and systems integration, and application and Web hosting (including e-mail hosting) at the top of the list (see Exhibit 7.2).3 For the most part, enterprises that use outsourcing are satisfied with the return on their investments, and they plan to continue to invest at more or less the same spread as in the previous year.4 This is very good news for the outsourcers, too. For every outsourcee there is an outsourcer ! Because the heart and soul of CIO responsibilities is rooted in defining IT resources in terms of business goals and strategies, let’s be clear about the definition of these two important terms: Outsourcee—The entity contracting-out with another entity to accomplish specified goals and/or objectives (deliverables). Outsourcer—The entity that works to accomplish the specified goals and/or objectives (deliverables) of the outsourcee entity.

There seems to be no limit to what CIOs are willing to outsource, but the patterns speak volumes. When asked if they were willing to outsource strategic IT functions and applications, 43 percent of CIO respondents were willing to do so—meaning that 57 percent thought otherwise. What

consider the outsource

277

Satisfaction for Outsourcing Operations and Applications Outsourced in 2004

Plan to ou tsource in 2005

Very Satisfied

Somewhat Satisfied

Diss atisfied

Application & Web development

64%

56%

37%

45%

18%

Application & systems integration

47%

43%

31%

52%

17%

Application & Web hosting (including e-mail hosting ) Help desk/end-user support

38%

38%

45%

35%

20%

40%

35%

48%

37%

15%

Network/telecom management

31%

30%

44%

39%

16%

Training and education

25%

27%

48%

35%

18%

Data Center

28%

25%

48%

39%

13%

Infrastructure design/build-out

21%

22%

38%

43%

20%

Project management

20%

17%

50%

38%

13%

Security

16%

16%

57%

30%

13%

Storage management

15%

16%

43%

49%

8%

Source: Adapted from “The Perfect Pursuit of Platform—Trend 8: Outsourcing Will Get Bigger, But Not More Critical,” accessed at http://www.cioinsight.com/article2/0,1540,1909298,00.asp, December 15, 2005.

EXHIBIT

7.2

O u t s o u rc i n g Sp e n d i n g Pa t t e r n s

drives outsourcing choices in the minds of these CIOs? It is not solely cost savings—74 percent of respondents believe that outsourcing is overrated as an IT cost-cutting strategy. Other drivers include 24-hour/365-day coverage and development and skills availability (see Exhibit 7.3).5 In fact, 51 percent of the CIOs said they had not cut full-time IT jobs when they outsourced to an offshore partner, and about two-thirds said that fear of losing jobs to outsourcing did not have a disruptive effect on their organization. This may well be the result of the person to whom different CIOs report: CIOs who report to people higher up in the company are more likely to have the necessary support they need to manage their budgets and resources in a way that optimizes the enterprise’s objectives rather than the objectives of a particular function within the enterprise.6 Although CIOs increasingly report to COOs, the vast majority reports to the CEO (see Exhibit 7.4).7 Taking this preliminary outsourcing analysis farther into the future,

278

chapter 7

consider the outsource

Outsourcing Strategic Operations and Applications Willing to outsource strategic IT Total <$100M $100–$999M >$1B Revenue Revenue Revenue functions & applications Agree Disagree Cost-cutting is overrated as a rationale for outsourcing Agree Disagree

43% 57%

49% 51%

41% 59%

39% 61%

74% 26%

71% 29%

76% 24%

76% 24%

Source: Adapted from “The Perfect Pursuit of Platform—Trend 8: Outsourcing Will Get Bigger, But Not More Critical,” accessed at http://www.cioinsight.com/article2/0,1540,1909298,00.asp, December 15, 2005.

7.3 CIO Willingness to Outsource Strategic IT Functions and Applications EXHIBIT

what are business and technology researchers investigating and evaluating? From a business point of view, one of the greatest concerns (and, therefore, an area of significant active investigation) is the loss of “higher-order” capabilities employees bring to bear when directly applied. A “directly applied” employee actually performs the work; the “indirectly applied” employee guides and directs another person but does not actually perform the work themselves. Gary Hamel summarizes the issue and the solution provided by good indirectly applied employees: “It’s tough to build eyepopping differentiation out of lower-order human capabilities like obedience, diligence, and raw intelligence . . . [A] company must be able to deliver the kind of unique customer value that can only be created by employees who bring a full measure of their initiative, imagination, and zeal to work every day.”8

Chairman / CEO / President

2005 2004 2003 55% 58% 62%

CFO or senior financial executive

19%

19%

16%

COO or senior operations executive

22%

14%

9%

Business unit head

1%

N/A

N/A

Other

3%

8%

13%

Source: Adapted from “The Perfect Pursuit of Platform—Trend 8: Outsourcing Will Get Bigger, But Not More Critical,” accessed at http://www.cioinsight.com/article2/0,1540,1909298,00.asp, December 15, 2005.

EXHIBIT

7.4

C I O Re p o r t i n g Pa t t e r n s

the whys of outsourcing

279

the whys of outsourcing “Common wisdom” in financially driven business climates says that outsourcing saves costs. However, practitioners with operational responsibilities know that cost savings are only one of many reasons why companies outsource. The why is a continuing story whose end may never come. Today, the primary reasons (normalized) for outsourcing are shown in Exhibit 7.5.9 It is worthwhile to take a look at each of these in turn. For John Valente, a senior executive with more than ten years experience in this area,10 cost did not even make it into the top three (it placed sixth). John’s top three reasons for outsourcing are: 1. Pace/Speed: The ability to get more work done in the same time or to get work done that would not otherwise get done. 2. Talent: The ability to get access to “talent” that he was not able to find locally. 3. Innovation: The ability to get access to skills and specific productrelated experience in areas that he didn’t even know initially he needed. John does see cost savings advantages, but he sees them as fortunate outcomes that result from better upstream operational choices regarding people and processes. Let’s take a look at some of the ways that cost savings derive from these better upstream choices.

g

g

Benefit Cost savings

Importance 1.6

Access to key skills

1.6

Follow-the-sun capability

1.2

Improved flexibility & agility

1.1

Taking advantage of host country’s universities

1.0

Source: Adapted from Djavanshir, G.R., “Surveying the Risks and Benefits of IT Outsourcing,” IT Professional 7, no. 6 (Nov–Dec, 2005): 33.

EXHIBIT

7.5

Importance Ratings of Outsourcing Benefits

280

chapter 7

consider the outsource

Cost Savings—Costs and Total Cost The cost of labor around the world continues upward. The operationally minded CIO, however, focuses on the cost of skilled operations, development, and management labor relative to the skills level for that cost. True cost of labor is derived from a combination of a number of factors: 1.

Cost of Acquisition

2.

Salary: base salary

3.

Bonus

4.

Perquisites (aka “Perks”)

5.

Benefits

6.

Costs of Retention

7.

Support & Infrastructure Costs

8.

Separation and/or Termination Costs

9.

Skills Level(s)

10.

Communication and Transfer Efficiency Factor

In most calculations of the true costs of labor, the first eight factors form the numerator and the 9th and 10th factors form the denominator. In other words, although the out-of-pocket expense for an individual outsource resource varies from business to business, the CIO must factor at least two important operational considerations for deriving the total cost of labor: (1) the skill level of the resource and (2) communication challenges involved in turning those skills into the anticipated value-added deliverables for the business. Take, for example, two separate situations: • Situation 1: “Your enterprise” is considering outsourcing to Company “A” based in Country “A”. • Situation 2: “Your enterprise” is considering outsourcing to Company “B” based in Country “B”. Situation 1 Conditions of Company A: A multinational, financially very healthy company based in Country A. Your enterprise benefits from Company A’s multicultural and multilingual workforce with its wide range of skills and experiences. Company A provides outsourcing services not only in its home country but also in your country and other countries.

the whys of outsourcing

281

Company A has labor costs that are said to be 20 percent of those in your enterprise but once finally calculated are approximately35 percent of those in your enterprise, and Company A has a high enough profile that it has name recognition with most (if not all) CIOs. Conditions in Country A: This country has a neutral stance toward your country, being neither friend nor foe. However, your country’s language is either the second or third language for the educated talent pool of Country A. Contribution and/or ownership requirements associated with doing business in this country demand that your partner must have a profitability objective with a reasonable event horizon (perhaps 5–7 years). It may be necessary to buy all supporting hardware, software, and other purchases through Country A–based companies or pay a significant tariff or duty on these items being imported into Country A. Last but not least, travel between your country and Country A is only marginally inconvenient. Situation 2 Conditions of Company B: A non-multinational that only has offices and operations in Country B. The company culture and its predominant languages are different than your country’s languages. Company B can provide outsourcing services only in their home Country B. Company B has labor costs that are said to be 15 percent of your enterprise but once finally calculated are approximately 25 percent of your enterprise. Company B has no real name recognition with most—if not all—CIOs. Conditions in Country B: This country has a negative political relationship with your country. Your country’s language is neither the second nor third language for the educated talent pool of Country B, though that situation is improving. Contribution and/or ownership requirements associated with doing business in Country B make it very difficult to ensure that your intellectual property can be adequately protected. It may be necessary to buy all supporting hardware, software, and other purchases through Country B–based companies or through suppliers who import what you need at significant tariff or duty. Travel between your country and Country B is fairly inconvenient. So, which situation is more appealing? Which situation makes more sense? Which situation would be the better choice? It depends. John Valente’s view is that “outsourcing never saves you money: if you were disciplined enough to do it yourself you could get the same margin of

282

chapter 7

consider the outsource

savings.” Although cost savings may not be sixth on everyone’s list, take a closer look if it falls on the top of your list. At this point, a cry of “foul” might be heard. How can it be that cost savings are not the top reason (maybe the only reason) for outsourcing? However, Exhibit 7.6 is legitimate. Many enterprises have been “outsourcing” for decades for the reasons mentioned earlier in this section. The point made in the first chapter’s section called “Strategic IT Questions–Starting from Scratch” applies: learn from your experiences, but remember that what happens in the future will be different in some important respects from your past experience—especially because this is such a rapidly growing and maturing practice. The point of Exhibit 7.6 is that there are costs and there is total cost. There is more to costs than just wages and apparent cost of living; to even begin to approach total cost the CIO starts with wages but also has to account for (1) direct and indirect costs, (2) relationship management resources and expenses, (3) program/project management resources and expenses, (4) capital and equipment expenses including export/import and shipping, (5) changes in project scope or requirements or designs, and (6) risk factors that can contribute significantly to total cost. Such risk factors include:11 • Geopolitical risk: includes stability of government, corruption, geopolitics, security

Company “A” Situation 1 Wipro

Country “B” Cost India Low

Risk Medium

IBM Global Services Switzerland

High

EDS

USA

Medium Medium

China

Low

Medium

France

High

Low

Armenia

Low

High

Situation 2

Low

Note: The multinational and local-country examples were randomly suggested; they neither represent an endorsement nor a lack o f on e.

EXHIBIT

7.6

Making Sense of Cost Savings

the whys of outsourcing

283

• Human capital risk: includes quality of educational system, labor pool, number of new IT graduates • IT competency risk: includes project management skills, high-end skills and competence (custom code writing, system writing, R&D, business process experience) • Economic risk: includes currency volatility, GDP growth • Legal risk: includes overall legislation, tax, intellectual property • Cultural risk: includes language compatibility, cultural affinities, innovation, adaptability • IT infrastructure risk: includes IT expenditure, quality of key access infrastructure The combination of these risks for each country and for each company may have a major effect on the total cost of outsourcing. For example, using Exhibit 7.6 as a basis, if “your enterprise” profile matches Situation 1 for evaluating an outsourcing relationship between your IT operations and an established company in India, your evaluation might look like this:12 1. Costs are Very Low. 2. Risk is Medium based on: a. Geopolitical risk: medium based on stability of government, corruption, geopolitics, security b. Human capital risk: very low based on quality of educational system, labor pool, number of new IT graduates c. IT competency risk: low based on project management skills, high-end skills and competence (custom code writing, system writing, R&D, business process experience) d. Economic risk: very low based on currency volatility, GDP growth e. Legal risk: medium based on overall legislation, tax, intellectual property f. Cultural risk: very low based on language compatibility, cultural affinities, innovation, adaptability g. IT infrastructure risk: high based on IT expenditure, quality of key access infrastructure 3. Total Cost therefore appears to be Low (rather than Very Low)

284

chapter 7

consider the outsource

It would not be difficult to imagine a series of factors related to the choice of outsourcee country that would cause the risk to rise to High or Very High with a corresponding change from “costs” to total cost being a factor of up to 5. Such a change would be enough to make the outsourcing for that particular situation unaffordable. Let’s round out the remaining additional costs that can significantly contribute to the total cost of outsourcing listed at the beginning of this section: • Relationship management resources and expenses are incurred to manage the ongoing relationship at the management, supervisor, and organizational level. There may be additional expenses required to integrate outsourced work back into your enterprise infrastructure. • Program/project management resources and expenses are incurred indirectly to liaison and manage the outsourced program/project with the outsourcing partner. These responsibilities commonly consume a majority of time or even become a full-time job for someone in the enterprise. Naturally, there may be travel or other expenses associated with doing so. • Capital and equipment expenses including export/import and shipping are incurred to provide required equipment, and if specialized environments are required, facilities upgrades and/or enhancements to allow the outsourcing partner to perform their contracted activities. These expenses may be fully or partially included and spelled out in the contract or may be wholly left for your company to provide. There are trade-offs to be made in deciding whether to buy equipment in the outsourcing partner’s home country or to buy it in your country and ship it. Many enterprises do both: purchase common off-the-shelf IT equipment in the outsourcing partner’s country and the specialized capital equipment in your company’s country for shipment to the partner’s country. This approach adds two levels of complexity for the CIO outsourcing to a company in a foreign land: ensuring the legal export requirements for one’s home country and the specific equipment and the legal import requirements and duties for the outsourcing partner’s country. All these costs may not be visible in the planning stages and may surprise people when they show up in a calculation of the total cost the enterprise eventually pays for the outsourcing relationship.

the whys of outsourcing

285

• Changes in project scope or requirements or designs are costs incurred when an enterprise alters course, learns that something was forgotten, or fails to fully consider and account for the important variables. Work-in-progress costs are much like additional charges incurred building a new house when the homeowner decides to change the design or change some appliance after work has started. Work-inprogress changes generate a “change order” or “work order” that nearly always result in additional charges. Experience shows that no amount of careful planning can predict all work-in-progress costs, therefore build a contingency plan (or contingency budget) to account for them. The old saying still applies: cost, performance (schedule), and quality—choose any two. While any number of these cost factors may be present in situations where an enterprise is not outsourcing, it is easy to forget about invisible, in-house work assumptions that may end up being a realized expense when outsourcing and “costs” becomes total cost. Nevertheless, additional outsourcing benefits complement carefully planned cost management. Access to Key Skills From an outsourcer’s point of view, access to key skills may seem like a weak motive in the initial wave of outsourcing considerations, but it has actually been one of the strongest motivators for many of the U.S.-based multinationals for years. IBM has reaped the advantages of this outsourcing resource for years. IBM has had major research and development laboratories in the major industrial countries for decades—not because these sites were the best “price performers” but because they possessed critical world-class talent that provided significant contributions to IBM’s products, revenues, and profits. These outsourcing sites provided bases from which IBM could conduct business in the site countries. Brilliantly, IBM places native citizens in senior management roles of these sites, staffs these sites with native citizens, and cycles through U.S.based managers and individual contributors on temporary assignments to help cross-pollinate company and country cultural understanding. All IBM sites emphasize an IBM culture base, yet each site has its own unique blended culture that combines IBM culture, the site country’s culture, and the site’s individual local culture. But make no mistake, when people

286

chapter 7

consider the outsource

walk into any IBM facility they walk into IBM itself, and the employees call themselves IBMers. Emerging countries now bring a significant number of talented and skilled resources. Dr. Rick Rashid, Vice President and Head of Microsoft Research, has first-hand experience with this trend. He is responsible for defining, creating, and staffing the heads of Microsoft’s research laboratories worldwide. Dr. Rashid has explicitly focused on culture as an important element of attracting and retaining the key skills Microsoft Research needs while ensuring the Microsoft corporate culture is not lost. There are cultural differences, but the dominant “culture” in each of the labs is MSR [MicroSoft Research] culture. Senior people typically trained in the US or Europe already and may have worked in Redmond so they already bring that perspective. For the younger people, a lot of our training focus is to bring them into the western research culture. We do language courses where needed, help teach research and writing skills, and our managers model behavior. Obviously there are still some cultural differences, but they mostly give a cultural “tint” to the labs rather than provide the dominant theme.13

John Valente’s approach with Accenture for Best Buy also stresses the importance of melding local and company culture. And, for understanding other cultures, John highly recommends the book Kiss, Bow, or Shake Hands.14 Culturally sensitive approaches are also important to the outsourcee’s employees, or in the case of wholly-owned subsidiaries, to the company subsidiary’s employees. It gives them both a local identity and a corporate identity and becomes the context in which their endeavors contribute to overall company success. From the outsourcee’s point of view, the outsourcer’s skills access dilemma is a business opportunity. Successful outsourcees must supply access to the skills required by the outsourcer at the right time and the right place. This usually means that the requisite skills need to already be on-board in the outsourcee company. For boutique outsourcee companies, this generally means moving from project to project (singly or in small numbers) and careful planning to avoid resource conflicts due to unscheduled overlapping of projects. Larger outsourcing companies manage a balance of their resources to a higher number of employees and skills mix than their least demanding activity, and optimally, just high enough to meet the requirements of their

the whys of outsourcing

287

most demanding activity. This forces a “wedge” because employees are not always fully employed, but it is necessary to ensure that they capture all key opportunities. Requirements for Doing Business Many countries require that a company have a country-based subsidiary or country-based operations to do commercial business. One way of achieving this is through an outsourcing partnership with a company that can also be a distributor for outsourcee products or services in the outsourcer country. This presents advantages from the outsourcee’s perspective because they obtain a wider range of products and services (and therefore revenue and profits potentially). Experts and educational curricula abound on the requirements of doing business with many, if not all, probable countries. For example, CalTech University has a course called “Doing business with India”;15 Squire Sanders Legal Counsel has a consulting arm and uses a document called “Doing Business in China”;16 Freshfields Bruckhaus Deringer consultants produced a document called “Guide to doing business in Russia”;17 the US Commercial Service developed a document called “Doing Business in Slovenia: A Country Commercial Guide for U.S. Companies,” published on the “buyusa.gov” Web site18—to name just a few. Behind every such publication, experts with (and without) personal experience work through the requirements of doing business in other countries. Examples of specific requirements and challenges for doing business in other countries appear in the proper context throughout the remainder of this chapter. Productivity From the outsourcer’s perspective, outsourcing presents the potential for significant productivity improvements, particularly when leveraging time zone differences. In a very common product service and support realm scenario, the support “follows the sun”. As “noon” moves from East to West the service center people supporting a particular product of organization transfer from a location in the East to one in the West and repeat this transfer to and from every 24-hour period. The simplest way to accomplish this uses two or three equally spaced geographic service and support regions spaced 12 or 8 time zones from each other. Most large multinational

288

chapter 7

consider the outsource

corporations now use this method to provide 24/7 call center support and many (such as international airlines and service-oriented groups such as IBM Global Services and Unisys) have done so for decades. Enterprises involved in outsourcing product development or application development can create productivity improvements by performing development, testing, debugging, fixing, and revalidation around the clock— literally. Xiotech Corporation uses several methods to increase outsourcing productivity with a multiregional workforce. Let’s look at two: 1. Split development and Quality Assurance/Test: In this method, people perform development work in Time Zone 1 and Quality Assurance/ Test (QA/Test) work in Time Zone 2. As development proceeds in Time Zone 1, people in Time Zone 2 test incremental improvements to the product. By the time the people from Time Zone 1 arrive for work the next morning, Time Zone 2 people have prepared and sent the triage results of the testing. The Time Zone 1 people then review the test results, make the necessary corrections, and address those corrections for testing by the Time Zone 2 people come in the next morning. 2. Cooperative Development and Quality Assurance/Test: In this method, both development and quality assurance/test occur during each time zone. This requires more sophisticated processes and management to work optimally, but the reward is obvious: 24-hour product development. When organized so that the development and quality assurance have a specific Time Zone 1 team member partnered with a specific Time Zone 2 team member, people can pick up where the others left off.19 This is called “GeoPairing.” And, this method provides some protection for loss of skills should the project lose one or two people. Typically, staffing skills differ from task to task across time zones. One zone may be very strong in one area but weak in others. In this case, the CIO works to coordinate a complimentary pairing of the skill levels and work people perform in each zone. Consider an example of an eight-person development team with three people located in Time Zone 1 and five people in Time Zone 2 where the three in Time Zone 1 have overlapping technical and experiential skills—but generally higher than the five in Time Zone 2. As illustrated in Exhibit 7.7, coordinating a

the whys of outsourcing

Time Zone 1 Dev 1

289

Time Zone 2 Dev 4

Dev 2 Dev 5 Dev 6 Dev 3 Dev 7 Dev 8 EXHIBIT

7.7

Time Zone Locality and Overlapping

Skill Sets

complementary working relationship might pair Development Team Member 1 (Dev 1) with Team Member Dev 4, Dev 2 with Devs 5 and 6, and Dev 3 with Devs 7 and 8. If there were Dev 9 and 10 in Time Zone 1 it would also be possible for Dev 8 to take the lead in a group consisting of Devs 9 and 10 (of course Dev 8 would not be associated with Dev 3 in that case). The sophisticated management challenge involves how to ensure overlapping efficiency and avoid re-creating work done in the previous period. In both methods, the outsourcee benefits from a tighter relationship with the outsourcer and therefore is more likely to see a flourishing and longer-term relationship. Business Continuity As with “follow the sun” development and/or service and support, an enterprise that leverages time zone and geographic differences also adds a degree of improvement in business continuity to its competitive attributes. Deploying round-the-clock development and/or operations (and therefore probably backup) could provide the basis and/or base of operations for business continuity in the event that either the outsourcee or the outsourcer has a critical failure. For example, Northeastern University20 uses off-hosting where its applications and its hardware reside at a SunGard location. This service provides

290

chapter 7

consider the outsource

tremendous value for Northeastern. SunGard hosts Northeastern hardware and applications if the primary site is down anywhere in the world they are needed. SunGard (www.sungard.com) is a $4B company whose claim to fame is the ability to provide business continuity with replica hardware that allows customers to run their own application(s) should their own primary equipment fail or become unavailable. The replica hardware, and associated software, can be located anywhere with suitable networking bandwidth, power, and security. In fact, SunGard has facilities in 50 countries. Geographic dispersion means that even when disaster strikes at 3:00 A.M. there is at least one site around the world where it is normal business hours and that staff can bring your applications back online. According to Hoover’s International Online,21 SunGard has 14 competitors. In reality, it has an almost infinite number of competitors because many companies do this themselves with their own geographically dispersed sites.

what can and what should be outsourced Just because something can be outsourced does not mean that it should be outsourced. There are many risks associated with outsourcing for both the outsourcee and the outsourcer. A recent survey of more than a hundred senior IT managers in different companies in the United States and Europe identified five key risks associated with outsourcing summarized in Exhibit 7.8.22

Risks Political Legal, enforcement of intellectual property rights and business contracts Information vulnerability and security Immature business environment Socio-cultural problems EXHIBIT

7.8

Importance 1.17 1.12 1.1 1.05 1.0

Normalized Ratings of Outsourcing Risks

what can and what should be outsourced

291

Many more risks exist than uncovered by this survey—and some may be even more important than the five in the survey. Additional risks include, ordered from highest to lowest risk:23 1. Frequency of interactions required 2. “Hearing” versus “understanding” calibration 3. Skills and experience normalization required 4. Time-shifting requirements 5. Equipment handling and management Given the risks and the potential for catastrophic consequences, what means do successful CIOs use to decide whether or not to outsource? It would be a significant mistake to outsource the enterprise’s core intellectual property. However, to outsource the added support needed for an existing product in a new environment where the new environment is too risky to use in-house resources may be an excellent limited risk scenario. From the outsourcer’s perspective, they do not want to take on what can be seen from the beginning as a certain failure. One of the most insightful books in this area is Attracting Perfect Customers: The Power of Strategic Synchronicity 24 by Stacey Hall and Jan Broqniez. They describe that to be successful with each other (as adapted for our purpose), both the outsourcee and the outsourcer need to be clear on their mission and cultural fit: • Be clear about who is being served • Hire only people truly aligned with the mission • Ensure that products, management practices, and organizational structures all align with the mission • Measure how well the organization achieves its mission every day • Trust that the money naturally follows when work is true to the mission: A business that stays true to its mission is an “attractive” business. An attractive business is one that is standing still and solid, emanating the light of its mission, so that its most perfect customers can easily find their way to the company.25

292

chapter 7

consider the outsource

how to outsource Once the decision has been made to outsource, the next question is: How? The answers to several fundamental questions point in the right direction: 1.

What are we going to outsource?

2.

Why outsource? What benefits do we expect?

3.

What level of our business activities are we outsourcing—strategic, developmental, operational, or . . . ?

4. Are we outsourcing something that crosses organizational boundaries? 5.

Does the outsourcing relationship include significant knowledge transfer?

6.

Does the outsourcing relationship require significant equipment transfer or acquisition?

7.

Are we outsourcing something with significant tie-ins back to the origination point?

8.

Do we have a management or corporate mandate to outsource?

9.

Is this our organization’s first outsourcing project?

10.

Is this the first outsourcing project you have done?

There seems to be no limit to the “resources” that address the processes for starting outsourcing projects where process advice ranges from the “just barely enough to call it a process” to “more than would be required to pass ISO 900x certification”—much like Emperor Joseph II’s “Too many notes” complaint about Mozart’s compositions. In other words, there can be too much of a good thing. Experience shows26 a common thread for initiating a plan and starting an outsourcing project. This section strikes a happy medium by discussing a step-by-step process that assumes little or no prior experience with establishing an outsourcing relationship by using the list in Exhibit 7.9 as the skeletal structure for the details of each step. Definition, Rationale, and Benefits Expected CIOs define IT resources and strategic opportunities for the entire enterprise, so start with (1) the definition of what it is that is going to be outsourced, (2) a clear agreement on why the outsourcing is being done—the

how to outsource

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. EXHIBIT

293

Definition, Rationale, and Benefits Expected Timeline and Path to Project Kick-off Survey Request for Information Review and Select the Best RFI Responses Request for Proposal Review and Select the Best RFP Responses Site Visit(s) Select the Best Negotiate the Contract Kick-off the Project

7.9

How to Outsource—Step-by-Step

rationale, and (3) the benefits expected to be realized from the outsourcing. All three elements must be defined up-front because they eventually need to be communicated to the outsourcer, the outsourcee, and their respective teams. The outsourced item can include new product development, product testing, ongoing product maintenance and support, IT operations, IT application development, hosting of applications and subsequent maintenance, call center support, installation support, and break/fix support to name a few. Next, the CIO must thoroughly understand the rationale for outsourcing. This affects the focus for the steps that follow and the final contract negotiation. For example, if the primary outsourcing objective is to reduce costs, then the outsourcing project will be defined and negotiated as a costsavings venture. On the other hand, what if the primary outsourcing objective is to develop a variation of an existing project and to use the outsourcing relationship as a means of quickly developing this capability in parallel to other activities currently in place? In this case, the outsourcing project should be defined and negotiated as one or more statements of work or work orders and negotiated on features and functions, delivery, quality, and cost bases. Finally, the benefits expected from the outsourcing relationship need to be defined; these reveal how the outsourcing project is expected to finish up—a vision of the end-state and end-result. The CIO must articulate this vision at the beginning of the process as something to guide the project as it progresses and ensure that the project stays on the path to achieving the

294

chapter 7

consider the outsource

end-goal. For instance, if the CIO expects that application development can be taking place essentially 24/7 (“follow the sun”) as the project’s primary benefit, use this as the litmus test to which the outsourcing project must be measured, and make it clear up-front that this holds for both the outsourcer and the outsourcee. Timeline and Path to Project Kick-off At this stage, the CIO must create a timeline with milestone deliverables that map out how to get from survey to project kick-off. An example is a timeline for outsourcing the development of a software-based product. For this particular product, the timeline and deliverables looked like: 1.

First two weeks of March: Identify the dozen or so potential outsourcing partners; create and populate survey spreadsheet.

2.

Third week of March: Complete survey spreadsheet with available information.

3.

Last week of March: Issue Request for Information (RFI).

4.

First week in April: Completed spreadsheets due back from potential outsourcing partners.

5.

Second and third weeks in April: In-person meetings with U.S. contingent of potential outsourcing partners.

6.

Third week in April: Notify qualified finalists for Non-Disclosure Agreement (NDA) and Request for Proposal (RFP) distribution.

7.

Last week in April: RFP distributed and telecon to answer any questions.

8.

First week in May: Distribution to potential partners of clarification document.

9.

Second and third weeks in May: Onsite visits to potential outsourcing partners for due diligence.

10.

Third week in May: Product planning document draft.

11.

Third week in May: Select and notify winner.

12.

Last week in May: Complete contract negotiations.

13.

Last week of May: Architectural document draft.

14.

June 1st: Sign contract; start project.

how to outsource

295

15.

August 1st: Begin Phase 1 Customer pilot.

16.

August 31st: Release to Manufacturing (RTM); i.e., make the product available for sale.

Survey After completely identifying the definition, rationale, expected benefits, and timeline it is time to do a survey of potential outsourcing partners. This can be accomplished any number of ways, such as performing a simple Web search, reading surveys of outsourcing companies produced by IT analysts, obtaining input from a professional colleague’s network, and employing a consultant to partner with a company that worked with yours in the past. The survey forms the basis for potential outsourcee analysis and is the base “company profile” information for the Request for Information analysis—the next step in this process. Spreadsheet tables are the best way to organize this information where the columns show the information to be gathered and the rows show the potential outsourcing partner companies. Column topics include: Company Name Company Headquarters and Key Contact Information U.S. Presence Public or Private Company Number of Employees Hardware Expertise Operating System & Utilities Expertise Applications Expertise Operations Expertise Accreditations (e.g., Microsoft Certified Partner, SEI CMM Level, ISO 900x) Business Models Project Types Customers The information required for these columns is generally available through a Web search; the information can be updated as responses and additional information become available. Expect to see three to four times the number of companies on your list than will ultimately receive Request for Proposal (RFP) letters.

296

chapter 7

consider the outsource

At the survey stage, it is both too early and unnecessary to weigh the topics. It soon becomes obvious which of the potential partners meet your criteria. For example, if you have a need for significant hardware experience, strike those companies in the survey off the list that lack such experience. Or, if one prospect already has a relationship with one of your direct competitors, you either eliminate this prospect or look for ways that they can guarantee no cross-information transfer. Once the list is narrowed down to those companies that would appear to qualify, the next step gives you more detailed information: create and issue a “Request for Information” letter. Request for Information After completing the survey analysis, write and issue the Request for Information (RFI) to those remaining on the list. The purpose of the RFI is two-fold: (1) gather more detailed information applicable to your specific requirements from the potential partners and (2) provide a vehicle to meet and interview the principles (or their representatives) of these potential partners. The meeting/interview is particularly important in getting the first “up close and personal” measure of the potential outsourcee. Write an RFI that is more detailed than the survey and less detailed than the Request for Proposal (RFP). The RFI focuses on gathering detailed capability and operational information to narrow down the field of potential partners to “the few”, and the RFP focuses on narrowing “the few” down to “the one”. There are two parts to the RFI: a spreadsheet and a document. The spreadsheet columns added to those from the survey with additional columns can include: System Software Utilities Operating System Environments Programming Languages Development Environment Development Processes Experience with Similar Requirements Ability to staff the project on the required timeline with skilled and experienced people

how to outsource

297

Fill in these columns with detailed information you receive from the responses to the issued RFI. To ensure appropriate analyses of this information, weight the values in each of the columns according to your enterprise priorities. Weight each value by analysis of the importance of each of the evaluation criteria relative to one another using one of two approaches for weighting factor scales: relative or absolute. Relative scales emphasize the importance of each evaluation criterion as being the same or higher or lower than the other criteria. One of the criteria is determined to be highest, lowest, or middle and the remaining criteria are comparatively evaluated and placed in relation to the middle or ends. With relative scales, more than one criterion can have the same weighting. Absolute scales emphasize the importance of each evaluation criterion regardless of the importance of the other criteria. Although it is possible for more than one or two criteria to have the same weighting value, the old saying still applies, “If they are all the highest weighting factor then they are all the lowest weighting factor, too.” The document portion of the RFI can be as straightforward as an e-mail used to transmit the spreadsheet and the schedule expectations as described in the RFI letter. Appendix 7.A shows the format of a Request for Information. Sending the RFI letter to potential outsourcing partners usually yields a 75 percent return rate. After the teleconference, about 50 percent move on to the face-to-face visit stage. Following the face-to-face meetings, the field usually narrows another 25 percent. So, if 12–16 entered the race, the field drops to 3–4 contestants for an on-site visit, but it all starts with the survey. Review and Select the Best RFI Responses In the next step for selecting the best outsourcee, the CIO reviews the RFI submissions and decides which potential partners will be invited to present their proposals in person for more detailed discussions based on the responses. This decision should correspond to the results of the weighted analyses with the additional stipulation that if any of the critical requirements regarding skills, experience, or availability score very low, the CIO automatically removes the candidate company from the going-forward list. Those who have made the going-forward list should be notified through an e-mail or letter (see Appendix 7.B).

298

chapter 7

consider the outsource

After finalizing the date, conduct the meeting within one week to ensure timely analyses with the information fresh in mind. A sample agenda for those invited to present in-person appears in Appendix 7.C. The length of meeting depends on the level of detail required for the discussions; however, a good rule of thumb limits the meetings to 90–120 minutes forcing a focus on their roles and yours. It is very important for the outsourcer’s people who will be based in your enterprise with whom you will deal on a regular basis attend in-person. This allows you to begin to develop the necessary face-to-face relationships and take the “measure of the person”. Your review of the findings from the in-person meetings usually results in three to four stand-out potential partners: the ones you will contact and take to the next phase, the Request for Proposal. Promptly notify those outsourcee representatives who did not make it to the short list and give them the reasons why they did not make the cut. This is important feedback to them, and it leaves an opening for them to participate in a future RFI. Also promptly notify representatives from potential outsourcee companies who did make the short list that they will soon receive an RFP with a schedule for the RFP process. Request for Proposal Candidates selected to receive the RFP show a high level of interest in the project(s) and as far as can be determined possess skilled and experienced people available to work on the project. Issue the RFP by e-mail or letter with the invitation and the required schedule. Additionally, this communiqué should introduce the expected in-person visit dates. An example e-mail or letter with timeline expectations for each of the finalists is provided in Appendix 7.D. The contents of an example RFP are outlined in Appendix 7.E. Effective RFPs are carefully constructed to state the goal(s) and scope of what is to be done, to identify the skills believed to be required, contract information requirements, and specifications of the work to be done, qualifications of the key people who need to be involved, pricing and evaluation criteria, and more general information such as deadlines, intellectual property rights, publicity, and contact information. Unless you explicitly declare otherwise, your enterprise will be expected

how to outsource

299

to provide marketing or user requirements and product architecture guidance for the project. The potential outsourcing partner can be responsible for design, development, integration, and testing the work output to the point defined in the RFP. After release (acceptance), the outsourcing partner can be tasked with providing additional enhancements (Phases 2 and 3, for example) based on new requirements defined by your enterprise. These additional requirements can be added to your base agreement through mutually negotiated addendums. After distributing the RFP to the potential partners expect to receive any number of questions as they analyze the RFP and prepare their responses. Although it would be tempting to answer each question as it comes in, doing so generates a significant amount of duplicate work and could result in inconsistent responses that would have to be corrected by subsequent communications. Therefore, the best approach is to collect the questions, make them non-company-specific, and subsequently distribute the accumulated questions and your responses to all RFP responders. They all get the benefit of each other’s questions and you get the benefit of all their responses! Review and Select the Best RFP Responses Now analyze all the responses based on the criteria established earlier and the qualitative information available. Though procedurally similar to the earlier “review and select” step, this step narrows the number of potential partners to those finalists who will be visited in person. It is nearly impossible to generalize the analysis of the RFP responses. In fact, the process requires flexibility because the different candidate responses usually show as many similarities as differences. However, experience shows that several areas should receive careful attention. The response should demonstrate that the potential partner clearly understands what you want them to do. This is important because the detailed responses in the RFP are usually completed by those who will be doing and/or managing the work. It is also important to watch the cost base: when one response is significantly different from the other responses (either high or low) it could indicate a lack of understanding of the work involved. Watch closely for how changes to the requirements while the project is in process are handled and how those changes are paid and accounted for from the base.

300

chapter 7

consider the outsource

In the end, carefully examine the expenses associated with necessary trips to and from your facility by any members of the outsourcee’s team, and look for additional costs associated with them. Consider this carefully and assume it will happen. Whether they are covered in contingency funds or in the project budget the money has to come from somewhere. Budgeting for one trip a quarter would be a reasonable place to start. John Valente has quarterly in-person meetings with his team alternating between Best Buy headquarters and the non-U.S. member sites. Additionally, because his staff also travels to and from non-U.S. sites someone from Best Buy headquarters can almost always be found at the non-U.S. sites some part of every month. Site Visit(s) The decision about whether to make a site visit is an important one. Although it may seem extravagant, rest assured: it is not. The site visit provides the means to ensure that the potential partner has the ability, people, equipment, means, and wherewithal to realize the results they have promised. Don’t forget your visa and other requirements for visits to different foreign countries. For some countries, an invitation to visit is required for visa approval. A letter or e-mail, similar to Appendix 7.F, prompts the potential partner to respond with an invitation to visit. There may also be recommended medical preparations advised such as inoculations; visit your local physician or international travel clinic to be sure. It is highly recommended that travel be scheduled for arrival a full day early to ensure that your team recovers from jet lag and the first of the meetings are fully productive when traveling overseas or a long distance for the site visits (especially for those who do not regularly travel internationally). Failure to do so could easily result in a very painful first day’s meeting and not allow full consideration of the first site visit when several visits are scheduled sequentially. It is also recommended that two people make the site visit(s); this reduces the likelihood that something said or covered (or not) is missed. Combining notes at the end of each day while the memory is fresh is essential. Once the visits are completed, a final review of notes and impressions is a prerequisite to the final evaluation from the site visit(s). Site visits can provide other benefits. For example, they establish relationships that may

how to outsource

301

be of value in follow-on projects, a comfort level gained from knowledge of the potential partner’s environment, and insights into their working environment. Once you have returned from the site visit(s), re-review the RFP responses and cross-correlate them with the results of the trip. Now you are ready to make the final selection of two candidates with whom you make final negotiations. Select the Best You are now at the point where it is time to choose the two companies with whom you will negotiate a final contract. Negotiating with two candidates not only shows a final balance of their attributes but also ensures that you are able to reach agreeable terms with at least one. The ultimate objective, of course, is to select the best. Of course, what you really select is the right choice—the best choice may become evident some time in the future but much later than matters, in reality.27 Negotiate the Contract Now that you are down to two choices, the time has come to tighten up the expectations on what, when, how, how much, and quality. This will again be a matter of trading the how much for various levels of the other expectations. Experience shows that the negotiations and contracts are best handled in your country’s currency—not the currency of the potential partner’s country—because managing the partnership will be much easier for you and your enterprise when the budgeted amount(s) do not fluctuate month-by-month with changes in currency values. Although this means there may be a cost savings missed if currency movements happen in your favor, you are also shielded from fluctuations to your detriment. It is also a good time to review the negotiation and communication culture and norms for the potential partner’s country while preparing for the final negotiations. There are many strategies to use for negotiating the contract; too many to delve into for this chapter. Once the contracts are negotiated to their right points it is time to decide which contract to choose to sign. The probability is high at this point that either contract would be fully acceptable, so the final choice is most likely going to be made based on the references provided of successful projects in a similar area and your final analysis of which potential partner more closely matches your enterprise

302

chapter 7

consider the outsource

culture, style, and approach. Once the final choice is made, both parties need to be notified and the project officially started. It may well be that the company that did not win the business may ask that they be allowed to run a parallel project at their own expense as a learning exercise and—of course—an opportunity in case your other contract does not work out. This may consume time and resources from your enterprise but does not consume funds directly. If the capacity and inclination exists, then the loser’s willingness to learn could be a very good contingency plan and a potential trial run that brings a secondary partner up-to-speed. This puts the “loser” and you in a comfortable spot for future possible projects.

Kick-off the Project Both teams—and senior management—are probably anxious to get the project started by the time the contract negotiations have ended and the contracts signed. This pending excitement can be shared and the anxiety reduced through an official “kick-off” meeting. Such a meeting could be centered around the official signing of the contract(s) or could coincide with the first meeting of the two companies’ project teams. It is always a good idea to start out on the right foot, and the business and personal bonds formed early on will undoubtedly be needed and tested as time goes on. Kicking-off the project also gives the operational and senior management an opportunity to review the expectations, to ensure joint understanding of those expectations, and to meet the team charged with making the project(s) successful. Do not shortchange this step.

managing what is outsourced Once the contract is signed, the project team is in place, and the project has been kicked off, it is time to move immediately into “manage” mode. Outsourcing, offshoring, outhosting methodologies are not “set it and forget it” operations. The first CIO responsibility is that of “trust but verify”. The specifics vary depending on what exactly is being outsourced and by the maturity of the organizations (outsourcee and outsourcer), but take the

managing what is outsourced

303

time to periodically review relationship progress as it unfolds over the first months according to the document. There are a multitude of ways to manage the what of outsourcing. Exhibit 7.10 lists a few of the more important methods, and each merit a brief description. When using Management by RFI/RFP/SoW both outsourcer and outsourcee focus on the document, and all activities are governed by and through the document and its constructs. When using Management by “MD” (Managing Director) the focus and communications are through the Managing Director as the management entity with the responsibility, authority, and accountability for outsourcing management. The Direct Management method uses a peer-level manager-to-manager structure between the outsourcer and outsourcee, yet the entities are separate. In Management by Wholly-owned Subsidiary the relationship between the outsourcer and outsourcee is more one of multiple groups working toward a common goal (both working for the “same company” as opposed to one doing work for another company). The Geographic Dispersion method spreads the organizations across time zones and/or countries and/or continents taking advantage of “followthe-sun” activity and disaster resilience. When using Co-Location the outsourcer and the outsourcee work in the same location allowing closer and higher bandwidth interactions. And, of course, permutations and combinations of these methods are more often than not becoming the norm. The RFI/RFP selection process is the best time to anticipate and sort out choices for the what and the how of outsourcing management.

A. B. C. D.

Management by RFI/RFP/SoW Management by “MD” (Managing Director) Management by “Direct Management” Management by Wholly-owned Subsidiary 1. Domestic 2. Foreign 3. Permutations & Combinations E. Geographic Dispersion F. Co-Location G. Permutations & Combinations EXHIBIT

7.10

Styles of Outsourcing Management

304

chapter 7

consider the outsource

Outsourcing Management Opportunities As the relationship matures and proves itself successful, ongoing outsourcing management opportunities can run the gamut of product and/or applications development, testing, service and support, operations, call center, planning and forecasting, financial instruments, or even the actual hardware and software infrastructure (also known as outhosting). In terms of a full or partial development cycle, product and/or application development may not be the first type of outsourcing that comes to mind; yet, it can become the most rewarding professionally for the outsourcer and the outsourcee as the relationship matures. Testing is often the first type of outsourcing that comes to mind particularly for product or applications development organizations. Look for opportunities to add and manage testing services from the outsourcing partner. Service and support may not be an obvious outsourcing type; however, many companies find it advantageous to take advantage of a partner’s “reach”. For example, companies like Unisys and IBM Global Services have made a significant business of providing “break/fix” and parts logistics support for companies of all sizes as part of their ongoing outsourcing management activities. Call center staffing and management is another attractive outsourcing opportunity after the outsourcing partner has established its English language and customer relationship competence. Operations is more likely to be done via outhosting and is not used as an outsourcing alternative as frequently as it was several years ago, but it remains a very popular opportunity with the right partner. Planning and forecasting, capital and capital leasing, and outhosting itself round of the list of some of the CIO’s more common outsourcing management opportunities. Ending the Relationship At some point in time, the outsourcing relationship might come to an end and then the question becomes: how is the outsourcing relationship wrapped up? If the contract has a clear end-point, then that end-point is a marker of anticipated success! On the other hand, the partnership might continue with new projects or other projects already underway or through statements of work (SOWs) that extend the original contract—situations when “finished” becomes hard to define.

outsourcing and the anna karenina principle

305

When making the decision to “end” the outsourcing contract and/or agreement it is nearly always advantageous to leave some door open to a later re-start or even a continuation. The contract itself may have postdevelopment aspects such as ongoing maintenance, incremental enhancements, up-leveling of hardware and software, and training to name just a few. Once a good relationship has been established and tested through a real project, keep it active and productive whenever possible. There is, of course, the darker side of ending an outsourcing relationship— not knowing when the party is over. When dealing with unrefrigerated fish or visiting in-laws, there comes a time when it’s time to part ways. It is important to build all agreements with the appropriate clauses to ensure that if the relationship gets to the point where it cannot be salvaged, then you can reasonably extricate yourself from the contract. (You are, after all, the customer.) The earlier such relationships are terminated the less traumatic it will be for both parties. With good planning, evaluation, and execution by the outsourcee and the outsourcer both can realize a satisfactory and mutually acceptable outcome.

outsourcing and the anna karenina principle Is outsourcing Nirvana achievable—forming marital bliss between two entirely separate companies in one of the many forms of relationship discussed in this chapter? Yes, and like anything worth having (or achieving) it does not come without a lot of careful, objective scrutiny and planning. Careful planning, evaluation, selection, contract creation and agreement, and shared goals are critical to the success. Leo Tolstoy captured the essence of successful and unsuccessful outsourcing relationships in his novel, Anna Karenina: “Happy families are all alike; every unhappy family is unhappy in its own way.” Think of all the many essentials that a man and a woman must harmonize to make a successful marriage after choosing to live together: how to spend money, how to spend free time, religious beliefs, mothers-in-law, how to reach compromise, where to live, selection of mutual friends, number of children, methods of discipline for the children, pets or no pets, practicing a faith, setting up a budget, sticking to a budget, where to take vacations, and closet space to name a few.

306

chapter 7

A. B. C. D. E. F. G. H. I. J.

Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: Phase 6: Phase 7: Phase 8: Phase 9: Phase 10:

EXHIBIT

7.11

consider the outsource

Deciding To Outsource Deciding What to Outsource Deciding How to Outsource Deciding to Whom to Outsource Deciding What to Share & What to Transfer First Deliverables (Contracts & Product Output) Repeatable Deliverables On-Going Management Branching Out (multiples in parallel) Continue, Change, or Terminate The Phases of Outsourcing Relationship

Planning

Now think of the same set of harmonized requirements necessary for a successful outsourcing relationship. Here is Tolstoy’s point: when a marriage or any other complex relationship succeeds, the participants find a way to make all the essential requirements work—all successful relationships are alike in this way. When a complex relationship fails, it is because any one of a number of different combinations of the essential challenges cannot be met to the satisfaction of one or all participants—all unsuccessful relationships differ in terms of the unique combination of one or more failures to harmonize. Exhibit 7.11 is a summary and reminder of the key planning phases that need to be harmonized to establish a successful outsourcing relationship. With globalization moving from assertion to reality, there has been no better time to engage an outsourcing relationship. Take the time to find the right match.

appendixes 7A. Sample Request for Information Letter Dear _____________: is adding to our development capabilities by engaging an offshore outsourcing partner. We expect this to be a long-term partnership.

appendixes

307

—a market leader—combines world-class innovation and industry experience, enabling people to <what’s done>. <More about the company and its customers or the IT group and its customers.> We are on a very tight schedule and plan to make a decision by the end of April. Please indicate your level of interest and qualifications by completing the attached spreadsheet. It includes a company information sheet, a qualification sheet, and an RFP analysis criteria sheet (this one is for your information only). Following is the schedule for the RFI: • April 2: Return completed spreadsheet via e-mail • Week of April 5: Face-to-face meetings will be scheduled with qualified potential partners at which time you and your team can present your qualifications and meet us • April 14: to select the top 3–5 qualified finalists for NDA and Request for Proposal (RFP) • April 16: will notify the qualified finalists and forward NDA for signature When we move to the RFP phase, we will disclose the specific projects, requirements, and time lines. Qualified finalists will have two weeks to respond to the RFP with their proposal. By the end of the first week, any questions must be submitted in writing (via e-mail), and a teleconference will be scheduled to walk through these questions. Following the teleconference, the finalists have one week to submit their quote. Our ultimate selection will be based on the following criteria: • Relevant technical capability and relevant skills availability • Quality, infrastructure, and management processes • Commitment to • Company viability • Cost We look forward to receiving your response to the attached RFI by April 2nd. If you have any questions prior to that time, please do not hesitate to call or e-mail me.

308

chapter 7

consider the outsource

7B. Sample Communiqué for In-person Meetings to Present RFI Submission Dear : We are pleased to advise you that has moved to the second round of our investigations. We would like to schedule a meeting to have you present more information on and to discuss your capabilities. Please contact me at your earliest convenience to schedule a date and time that you are available to come to . I look forward to hearing from you. Regards, 7C. Sample Agenda for RFI Review-and-Select Meeting Dear < Potential Partner Company Representative’s name >: Here is the proposed agenda for our meeting. Please advise if you have any requested changes. • Introductions & Agenda Review —All • RFI response presentation

—< Potential Partner Company >

•

Concentration on areas relevant to ➢ Experience Type #1 ➢ Experience Type #2 ➢ Experience Type #n ➢ Availability to begin within next 30–45 days with experienced personnel

•

Concentration on areas relevant to ➢ Experience with ➢ Development process with ➢ Business process with

•

Applicable references who can be contacted

appendixes

• Feedback

—

• Next Steps

—All

309

Please let us know who (name and responsibility or role) from your company will be participating in this meeting. We prefer that your key -based participants attend in-person. Regards, 7D. Sample Request for Proposal Letter Dear Attached is the Request for Proposal (RFP). The schedule for the RFP is noted on page 2. Also, attached are FAQs in response to queries, the specification for the project, and additional background information on our existing environment. The timeline for our RFP process appears below. We look forward to your response. • RFP issued: Wednesday, April 21 • Questions of related to the RFP: due by close of business, Monday, April 26 • Questions made generic, consolidated, and distributed as FAQ: Wednesday, April 28 • RFP response: Due by close of business, Monday, May 3 • RFP reviews by : Completed by Wednesday, May 5 • Follow-up questions by : Completed by close of business Friday, May 7 • On-site () Visits by : Week of May 10 • Final selection: notification on or before Friday, May 21 • Final negotiations: May 21–30 • Project start: Week of May 31 • First full project deliverable for production use: Friday, July 30

310

chapter 7

consider the outsource

Would you please send me the address and other appropriate contact information for the proposed visit to your facilities in for the week of ? We are scheduling this trip. Regards, 7E. Sample Outline for Request for Proposal I. Section 1: Introduction and Scope A. Introduction 1. Invitation to bid for the RFP and the RFP timeline [Appendix 7.D] 2. A brief paragraph about B. Scope of Proposal 1. If the proposal could develop into more phases than the one in the RFP, this is the place to so indicate. 2. The follow-on phases are included to get “order of magnitude” timing and pricing and to indicate interest in additional work if the first phase proves successful. C. Outsourcing Partner Requirements and Skills 1. This section describes what is expected of the outsourcing partner and what will contribute by Phase. 2. This section should include a general list of requirements for partnership. Use them to clarify an intent for a long-term partnership and how important these are to the partnership being a success: a) Successful experiences, with references, working with b) Willingness and ability to adapt to development and production processes as deemed appropriate by c) Acceptance of a -based presence d) Immediate ability of on-board skilled resources e) Immediate availability of appropriate development, integration, test, and maintenance facilities and resources including

appendixes

311

those required for f ) Certification through appropriate ISO and SEI-CMM bodies g) Willingness and ability to proceed on the projected schedule h) Completeness, accuracy, and openness of information related to the project(s) status i) Fluent, regular, and as-needed communications as soon as questions, problems, needs arise D. Contract Schedule and Terms 1. Repeat the phase schedule 2. Intent is a long-term relationship and the pricing should reflect it 3. Establish post-delivery maintenance expectations: a) Response times to problems that arise b) Rates quoted on a time and materials basis should be quoted on a person-week basis including customary work week of the location and any holiday and weekend work as needed including 24 x 7 coverage (if needed) and a Not-to-Exceed (NTE) component tied to negotiated, mutually acceptable performance criteria c) Rates quoted on a fixed-price basis should be quoted on the assumption of a payment on a regular monthly or quarterly basis tied to negotiated, mutually acceptable performance criteria II. Section 2: Requirements and Specifications A. Support Requirements 1. Support is negotiated during the contract negotiations; however, expectations should be set here. For example: a) 24-hour turn around time for any e-mail correspondence b) Weekly status and outlook call c) Weekly status and outlook report distributed via e-mail d) Monthly senior management status review and outlook including trend analysis e) Quarterly senior management review including dashboard analyses B. Documentation Requirements 1. Documentation requirements and expectations are set here; for example for a full end-to-end project:

312

chapter 7

consider the outsource

a) Phase “n” Project Overview and Architectural Specifications b) Phase “n” Design Overview and Design Specifications c) Phase “n” Development Plan d) Phase “n” Documents and Publications (Internal and External) Plan e) Phase “n” Quality Assurance and Test Plan f ) Phase “n” Release to <manufacturing, production, customer, etc.> Plan g) Phase “n” Acceptance Criteria (jointly negotiated with ) h) Phase “n” Maintenance, Service, and Support Plan i) Framework for Phase “n” Follow-On Plan (including all the above) j) Technology and Knowledge Transfer Plan C. Hardware Requirements 1. Who supplies what hardware to work on the project 2. Expectations should be set such that the potential partner must identify what hardware is required that must supply for development and for ongoing maintenance 3. Expectations of what hardware the potential partner is expected to supply on their own must also be set 4. For hardware supplied by the potential partner, clearly stipulating who pays for it and how it is paid for is required. D. Software Requirements 1. Same general stipulations for the hardware requirements 2. is expected to provide a list of known required software E. Project Management Requirements 1. Expectations has on the potential partner; for example: a) 24-hour turnaround time for any e-mail correspondence b) Weekly status and outlook call c) Weekly status and outlook report distributed via e-mail d) Monthly senior management status review and outlook including trend analysis e) Quarterly senior management review including dashboard analyses

appendixes

313

2. Set the expectation that unless via prior agreement, it is expected that project management billings will include these updates and will not exceed “n” hours per week billed to the project. III. Section 3: Qualifications A. Qualifications 1. Set the expectation that because you are planning a long-term relationship and mutual success that you have requirements for how the project is staffed; for example: a) Qualified, consistent, and stable non-rotating team is applied to projects b) Project members with a minimum of a 4-year technical degree from an accredited university c) Project members to have the appropriate skills noted earlier for each Phase during development and appropriate afterwards for subsequent maintenance, service, support, and enhancements. d) Program manager/Project manager must have skills and experience in managing projects of a similar nature to each of the phases. e) Experience must be verified via certification program and/or customer reference. 2. The expectation should be set that will be fielding a highly qualified, experienced, professional, and motivated team to work with their equivalent. IV. Section 4: Pricing and Evaluation A. Pricing and Payment Terms 1. Establish that all pricing and payments terms need to be in . 2. Reiterate that with a long-term relationship being desirable that pricing should be reflected in pricing that is aggressive. 3. Reiterate the “time and materials” and “fixed-price” quotes basis. 4. Define the basic planned payment terms based on measurable deliverable and milestone achievement; for example: a) The first 25% installment will be made at the time of official project start b) The second installment of 25% will be made following ’s acceptance of a negotiated, mutually accepted technical development checkpoint

314

chapter 7

consider the outsource

c) The third and final installments of 50% will be paid no later than 60 days after final acceptance by and turn-over of the completed work whichever is later. 5. Reiterate the post-turnover service and support expectations B. Evaluation Criteria 1. Define the evaluation criteria to be used on the RFP responses; for example: a) Using the evaluation criteria under “Analysis Criteria” in the RFI spreadsheet b) Experience and availability of experienced and skilled professionals in the areas defined as required c) Experience and availability of experienced and skilled personnel and project management resources d) Applicable references e) On-site visit validation and verification f ) Project and On-Going Cost Projections 2. Specify that from the RFP analyses two potential partners will be chosen with whom to negotiate to a final agreement and when the two will be notified. 3. Identify when the final negotiations must conclude and when the award will be made. 4. Reiterate the project start date. V. Section 5: General Information A. Deadlines 1. Reiterate the RFP deadlines from the earlier section. B. Proposal Contents 1. Reiterate the date by close of business the RFP response is due. 2. Reiterate the minimally acceptable information required for the response to be accepted; for example: 3. Corporate Information as listed in the RFI spreadsheet 4. Phase 1 Development Quotation a) Prices, costs, terms, and conditions b) Quantities of hardware and software and accessories required from c) Resource, Task, and Deliverables Timeline d) Incentives, and penalties proposal 5. Phase 1 On-Going Maintenance, Service & Support, Incremental Enhancements

appendixes

C.

D.

E.

F.

315

a) Prices, costs, terms, & conditions b) Quantity of hardware, software, and accessories required from c) Resource, Task, and Deliverables Timeline d) Incentives and penalties proposal 6. Phase 1 defined resources and credentials 7. Phase 2 Level of Effort Estimate and Timeline (non-binding) 8. Phase 3 Level of Effort Estimate and Timeline (non-binding) 9. Reiterate that the RFP response must be approved and authorized by the appropriate Corporate Executive of the potential partner. 10. Reiterate that all costs are to be in . Non-Disclosure Agreements 1. Reiterate that the subject and the work are and will continue to be bound by confidentiality agreements. Intellectual Property Rights 1. State the expectations about who owns intellectual property, architecture, designs, and product components, source code, and results developed as part of the agreement. 2. Defines the above terms. Publicity 1. Establish that all companies submitting responses to the RFP agree by doing so that the proposal nor any subsequent agreement or lack of ability to reach an agreement be publicized or be confirmed or denied publicly without the prior express written approval of . 2. This also includes using photographs, video recordings, or ‘s name without prior express written approval. Contact Information 1. Provide the RFP Coordinator’s name and contact information. 2. Reiterate the RFP questions date and the submission date.

7F. Site Visit Preparation Letter and Agenda Proposal Dear : We would like to arrange to meet with your team at the site where the work would be done in <potential partner representative’s city, country> beginning the morning of <proposed date>.

316

chapter 7

consider the outsource

We would like to achieve the following objectives during our visit: • Meet your key management team to establish a relationship with them. • View your facility and resources (systems, communication infrastructure, hardware, backup systems, etc.). • Meet people on your team (program managers, architects, developers, test engineers) who have experience in the type of projects we have identified through the RFI and RFP. • Provide you an opportunity to showcase your technical capabilities in relevant technologies and highlight successful projects of a similar nature. • Understand the cost basis for your RFP response. • Understand your human resources and training competencies and practices that help reduce attrition and building best-in-breed teams. • Understand your delivery model and quality management systems to assure timely delivery of projects while meeting the highest levels of quality. Please refer to the attached agenda and feel free to suggest any other points that you would like to address during our visit. We are planning for the visit to be 4–5 hours; however, if deemed appropriate we can dedicate an entire day. Let us know your preference. If you have recommendations on who to contact for hotel and transportation arrangements we would appreciate knowing. We look forward to hearing from you and to our visit. Best regards,

notes

317

sample agenda for site visit

Time

Agenda

0900

Pick up from hotel and proceed to

0930–0945

Introductions and Review of Visit Agenda

Lead

Partner Representative

Session 1 0945–1015

Presentation: Visit Objectives



1015–1045

Presentation: Corporate Overview

Senior Manager

1045–1130

Presentation: Practice

Practice Head

Session 2 1130–1200

Presentation: Human Resources Development and Training

HR Senior Manager

1200–1230

Presentation: Information Protection Policy

IP Head

Session 3 1230–1300

Presentation: Quality Processes and Best Practices

Quality Head

Session 4 1300–1400

Proceed for Lunch with Project Team

All

1400–1500

Presentation on <specific project related to

Development Mgr & Lead

1500–1515

Tea Break

1515–1630

Travel to Lab and Walk-through Lab Tour

Lab Head

1630–1700

Wrap-up and Next Steps

All

■ notes 1. http://m-w.com/cgibin/dictionary?book=Dictionary&va=outsourcing&x=15&y=16 2. Adapted from “The Perfect Pursuit of Platform—Trend 8: Outsourcing Will Get Bigger, But Not More Critical,” accessed at http://www.cioinsight.com/article2/ 0,1540,1909298,00.asp, December 15, 2005. 3. Adapted from “The Perfect Pursuit of Platform—Trend 8: Outsourcing Will Get Bigger, But Not More Critical,” accessed at http://www.cioinsight.com/article2/ 0,1540,1909298,00.asp, December 15, 2005.

318

chapter 7

consider the outsource

4. There is a notable reduction (five absolute percentage points) in help desk/ end-user support investments. 5. Adapted from “The Perfect Pursuit of Platform—Trend 8: Outsourcing Will Get Bigger, But Not More Critical,” accessed at http://www.cioinsight.com/article2/ 0,1540,1909298,00.asp, December 15, 2005. 6. Karl D. Schubert, The CIO Survival Guide:The Roles and Responsibilities of the Chief Information Officer (New York: John Wiley & Sons, Inc., 2004) 16–17, 218–220. 7. See note 5 above. 8. Gary Hamel, “The Why, What, and How of Management Innovation” Harvard Business Review 84 no. 2 (Feb 1 2006): 80. 9. Adapted from Djavanshir, G.R., “Surveying the Risks and Benefits of IT Outsourcing,” IT Professional 7, no. 6 (Nov–Dec, 2005): 33. 10. John Valente is the Senior Executive of Global Technical Architecture for Best Buy and is in the unique position to speak with some authority on this issue. He designed Best Buy’s outsourcing structure and then joined Accenture to lead the execution of the structure and plan he designed for their company. Formerly, John was a vice president of new technology development for Dell IT. In both positions, he reports/reported to the CIO. 11. Mark D. Minevich and Frank-Jürgen Richter, “The Global Outsourcing Report: Opportunities, Costs and Risks,” CIO Insight, December 15, 2005: 55–56. 12. See note 11 above, page 56. 13. Private e-mail correspondence from Dr. Risk Rashid, March 17, 2006. Used with permission. 14. Terri Morrison, Wayne A. Conaway, George A. Borden, Kiss, Bow, or Shake Hands, (Holbrook, MA: Bob Adams, Inc.,1995). 15. http://www.irc.caltech.edu/courses/Doing_Business_with_India.htm, accessed March 5, 2006. 16. http://www.ep.org/documents/DBinC_2005_mission.pdf, accessed March 5, 2006. 17. http://www.freshfields.com/publications/pdfs/2005/13524.pdf, accessed March 5, 2006. 18. http://www.buyusa.gov/slovenia/en/ccg2006.doc, accessed March 5, 2006. 19. Ken Krutsch, Vice President of Engineering at Xiotech Corp., refers to this as the “man in the yellow hat” approach to 24-hour development and QA/test. 20. Phone interview with Robert P. Weir, CIO for Northeastern University, February 2, 2006. 21. http://www.hoovers.com/sungard/—ID__14834-/free-co-factsheet.xhtml, viewed March 8, 2006. 22. See note 9 above, page 35.

notes

319

23. This is based on my own experience in initiating, managing, and terminating outsourcing agreements. 24. Stacey Hall and Jan Broqniez, Attracting Perfect Customers: The Power of Strategic Synchronicity (San Francisco: Berrett-Koehler Publishers, 2001). 25. See note 24 above, pages 18–19. 26. And, especially, my own personal experience. 27. Casey Powell, CEO of Xiotech and founder and former CEO of Sequent Computer defines the “right choice” as the choice you made once you had the facts. What makes it the “right choice” is that it is the one you made as opposed to the “best choice” which is an idealistically perfect choice—though rarely if ever attainable.

chapter

8

Managing for Returns on IT Investments by michael hugos and joe stenzel

In a free market economy driven by the competing interests of shareholders and a variety of stakeholders, executive leadership at all levels shares a common accountability: use available resources to achieve the best possible outcome. This book concludes with a discussion of resource decision making that ties together the ever-widening circles of IT influence from its strategic core. IT architecture, tactical agility, and strategic cost, performance, customer relationship, and outsourcing management each enable an organization to align, implement, and realize its strategic objectives. The art (and expectation) of executive leadership is to make decisions that unify and coordinate these many activities and grow the resources that support them. Unfortunately, conventional ROI calculations were not designed to capture the increasing complexity of the recent emergence and rapid evolution of strategically deployed information technology resources. At the same time, enterprises expect the CIO to make wise investments without understanding the scope of these investment responsibilities. This chapter has two objectives: (1) demonstrate the ways that executive leadership can use conventional ROI calculations to improve decision making for IT project proposals; and (2) explore new perspectives on IT “investments” and arrive at ways that the CIO can help other executives manage and maximize

321

322

chapter 8

managing for returns on it investments

more broad-ranging, elusive, vaporous organizational resources and achieve a return on intangibles. Part 1 discusses the IT ROI challenges faced by the CIO who seeks to create systems and link resources that enable execution of the company’s business strategy. These challenges include scope, risk, responsibility sharing, strategic precision, and local and enterprise-wide work implications in terms of new IT project proposals. Part 1 also addresses the essential elements that the CIO uses to see the ROI process through from start to finish. This includes: the joint development process between IT and Finance; a cost/potential benefit analysis; an IT ROI benefit audit; ways to weight tangible benefits; and the reapplication of people and resources freed up by the project. Part 2 explores the rapidly emerging importance of intangible IT resources from the marketplace to the boardroom. Building on intangible management best practices from IT, Human Resources, and previous chapters, this discussion addresses practical ways that executive teams define, identify, measure, valuate, and renew their intangible IT resources.

part 1 by michael hugos is this project worth doing? The ROI answers the question, “Is this project worth doing?” The process of calculating the ROI builds the consensus among business and technical people. The IT people who will build the system are responsible for estimating the costs. The business people who will use the system are responsible for estimating the benefits. With the help of the CFO, Finance people are responsible for setting the financial parameters such as company cost of capital or the discount rate to be used in evaluating the value of the project. These three groups in any enterprise must come together in a common process to decide whether a project or a new IT investment is worth doing. Everyone whose budget will be affected by the project should have an opportunity to review the costs and the benefits of the project.

the roi process It is better to use a simpler ROI calculation rather than a more complex one so that everyone involved can understand it. Because it is an estimate

define the specific costs and benefits

323

anyway, adding additional complexity to the process does not increase its accuracy and also reduces its value as a consensus-building tool. Once a plan has been constructed, the budget can be created. Project plans and budgets are just two sides of the same coin. Plans show the time, people, and material needed for the project, and budgets show the cost of the people and material over the time frames involved. Although, in many cases, the cost and benefits related to a project cannot be defined with absolute certainty, it is still a valuable exercise to get as accurate an estimate as possible. It is often hard to assign specific values to the benefits, but it must be done. When in doubt, understate the benefits. Just make sure that the benefit numbers are ones that people can understand and support. The sum of these benefit numbers is the value of the project, and it is very important to have agreement on the value of a project. The value of the project is the main reference point to keep in mind when evaluating the rest of the project. The value of the system determines how much can be spent to build the system. There are two choices when the costs to develop a system add up to more than the benefits that will be produced: Either find a less expensive way to produce those benefits or simply do not do the project. Businesses exist to make a profit and that is a discipline that all business people (including CIOs) must live with.

define the specific costs and benefits From a financial perspective, a system generates a stream of costs and benefits over the length of time in which it is built and used. As a rule, a system should pay for itself and return an appropriate profit within one to three years because after that time most systems usually need major enhancements or a major upgrade in the hardware and software that supports the system. CIOs who accept more than a three-year payback period are probably using the analysis to justify what is really an emotional decision. Beyond 36 months the world changes in ways that are very hard to predict, and estimates of costs and benefits that far out tend to be exercises in wishful thinking. The only category where a case can be made for using a payback period longer than three years is systems that make up the most

324

chapter 8

managing for returns on it investments

stable and basic transaction processing applications in a company. This includes systems such as accounting (accounts receivable, accounts payable, General Ledger), inventory control, and production scheduling. Most other types of systems from customer relation management (CRM) to business intelligence (BI) to e-commerce require significant upgrades and enhancements within three to five years because the applications they support are themselves changing quickly due to changes in technology and customer expectations. Identify specific benefits and estimate their dollar value. Measure system costs and benefits on a quarterly basis. Subtract costs from benefits to arrive at the quarterly cash flow generated by the system. Calculate the value of that cash flow using whatever method the financial decision makers prefer (net present value, internal rate of return). The higher the risk involved in building and operating the system, the higher the profit that the system should generate. Here are a few guidelines that help people develop their estimates of the costs and benefits for the system development project that they are evaluating: • Estimate costs high (e.g., computer system costs are calculated to cover highest estimated capacity requirements) • Create two estimates of possible benefits—a lowest expected level of benefits and a highest expected level of benefits • Calculate costs and benefits by specific line items for appropriate intervals of time (usually quarters but sometimes years) over a time frame equal to the period that the new system can operate before significant expenses to upgrade or replace the system occur (usually not greater than three years) System Costs In a system development project there are three types of costs. Hardware and software costs include the hardware, software, and communication network components that need to be purchased from vendors for the new system design. Development costs as estimated by the time and cost needed to achieve each project objective. Each task that is part of the work plan for an objective will

define the specific costs and benefits

325

require some number of people with certain skills for some period of time. Each task will also require certain technology and perhaps other expenses, such as travel, hotel rooms, and meals. Set a standard cost for each kind of person, and estimate the labor expenses for each kind of person for each step in the system development life cycle: the DEFINE, DESIGN, and BUILD steps described in Chapter 3. Operating costs have a number of components. Estimate labor expenses for the kinds of people that will be needed for ongoing operation and support of the new system. Estimate the line charges and usage fees for the communications network and technical architecture used by the system. Obtain yearly licensing and technical support costs from vendors of the hardware and software components used by the new system. System Benefits A realistic estimate of benefits is very important. Look at the tangible benefits and assign values over a period of time. Then look at other intangible benefits such as reputation and relationships with customers and suppliers. Look at employee productivity and leveraging their talents. Who are the stakeholders in the project, and what issues are important to them? What would happen if the project was not done? How important are the benefits of the project to the stakeholders? Four types of benefits are provided by a new system. Direct benefits are productivity increases and cost savings due to the capacity increases brought about by a new system. Define the new functions the system provides that the enterprise does not now possess. Estimate the productivity increases and labor savings that these new features provide. Incremental benefits are monetary benefits that may not be solely the result of the new system but are measurable and due in some significant degree to the capabilities of the new system. An incremental benefit may be an increased ability to attract and retain new customers and the extra revenue that generates. It may be the new system’s ability to help the enterprise avoid bad decisions or manage and plan for certain business expenses and the reduced costs that result. Cost avoidance benefits are savings related to the increased capacity provided by the new system and the company’s ability to grow the business without having to hire new staff. Intangible benefits are hard to quantify into

326

chapter 8

managing for returns on it investments

a money amount but should be identified and listed. These benefits include such things as maintenance of a competitive advantage through better intelligence and adaptability; superior service levels that solidify customer relationships; and leveraging the abilities of talented employees and increasing their job satisfaction. A sample of these calculations appears in Appendix 8.A. To be complete, the ROI analysis should be performed twice. The first time should show the net present value (NPV) of the project using the low end of the range of benefits estimated for the project, and the second time should use the high end of the estimated benefits. Ask the question, “Would this project still be worth doing if the costs were twice as high and/or the benefits only half as much?”

the portfolio of system investments As discussed in Chapter 2, enterprises should look at their investments in IT and application systems from the perspective of portfolio management. This requires that they first define several important characteristics of these investments. Namely, what are the life spans of these investments, what are the risks associated with each investment, and what are the potential returns? Based on these characteristics, IT investments should be placed in different categories depending on their risk and reward potential. Evaluate the riskiest systems using a higher cost of capital or discount rate, and demonstrate that they can deliver much higher benefits. The least risky systems can use a lower cost of capital and lower level of benefits. In the interests of keeping the ROI process simple, it helps to define three categories of systems investments: Basic Transaction Processing Systems; Adaptive Systems; and Linking Systems. Basic transaction processing systems are the foundation systems that record business operations on a day-to-day, hour-by-hour basis. These systems tend to have life spans of 5-10 years. They are systems such as: • Operations Monitoring & Control • Inventory Control • Production Scheduling, Delivery Scheduling • A/R, A/P, G/L, and related accounting applications

the portfolio of system investments

327

Adaptive systems track business and operating trends and help the company respond to its environment. These systems have life spans of around 3–6 years. Some adaptive systems are: • Sales support and CRM • Business intelligence, dashboards, scorecards • Office productivity • Customer service applications • Supply chain management • E-Commerce, product catalogs, customer order entry

Customer

Supplier

Customer

Web Sites & Portals

EDI & XML

Linking Systems (1–3 Year Life Cycle)

Supplier

E-Mail

Adaptive Systems (3–6 Year Life Cycle) Business Intelligence

Sales Support & CRM

Basic Transaction Systems (5–10 Year Life Cycle) • • •

Supply Chain Management

•

A/R, A/P, GL Operations Control Delivery Scheduling Inventory Control

Customer Service

EXHIBIT

8.1

Office Productivity

e-Commerce

Three Categories of IT Investments

328

chapter 8

managing for returns on it investments

Linking systems connect a company with its customers and suppliers. These systems change every 1–3 years. They include systems such as: • Web sites and portals • EDI/XML/Data transfer systems • E-mail, Blackberries, instant messaging Investments in basic transaction processing systems are less risky because they have a longer period over which to yield a return. Investments in linking systems are the riskiest because they have the shortest time to pay off. Yet linking systems can also yield some of the biggest rewards for an enterprise. See Exhibit 8.1 for an illustration of these three categories.

it systems investments Enterprises do not need to make investments in basic transaction processing systems every year. When new systems in this category are installed, all that is needed for the next several years is to simply operate them and finetune their performance. From one year to the next most IT investments will be in linking systems and adaptive systems. The linking systems projects are most likely enhancements to the Internet-based infrastructure that many enterprises now rely on to connect them with the markets they serve. In most cases, these projects are the work required to link an enterprise’s internal systems with those of customers and suppliers. In those cases there should be a good indication of the revenues to be gained or the expenses to be reduced. In all likelihood, once they are built for one customer or supplier, these enhancements serve to link up with many other customers and suppliers with only small changes. The adaptive systems investments most likely are enhancements to systems such as business intelligence and related data warehouse systems, upgrades to customer relationship management and supply chain management systems, and e-commerce systems. Enterprises are seeing a demand for more online reporting from customers, suppliers, and their own internal staff. In those cases they have some good ideas what it is worth to provide customers, suppliers, and their own people with more data. Use the life spans defined here to analyze system investments for these systems. Provide good estimates of the revenue increases or expense

define a project evaluation process

329

decreases they enable. Then, given the desired rate of return on system investments, one can just about calculate what should be spent on each project. This is where effective CIOs earn their keep. If a system cannot be built in a cost-effective manner, an enterprise either forgoes the business opportunity the system would enable or suffers a poor return on its investment. Enterprises that are not good at continuously designing and building new linking and adaptive systems in the information-based global economy fail just as surely as those enterprises that are not good at sales, marketing, or new product development. The key to getting the best return on these systems investments is to design and build new systems by combining the capabilities of existing systems with carefully selected new development. Look to use available technology platforms (Internet, client/server, and mainframe) for the things they do best and design new systems that effectively use these different technologies in concert to cost-effectively support new business activities. Think of the money invested in the three categories of systems as a portfolio with a balance of risk and expected returns appropriate to the needs of the enterprise. When a new IT project or group of projects is proposed, assess the impact on the existing portfolio of systems investments. What categories of systems are the proposed new projects in? What impact do they have on the overall risk and return structure of the IT portfolio?

define a project evaluation process Best practice CIOs define the steps in a formal Project Evaluation Process for people to use when evaluating project proposals. Six milestones in the evaluation process help ensure a deliberate, carefully reasoned decisions based on ROI determinations. (1) As projects go through the definition phase, identify a decision point where the conceptual design and the ROI are presented to the IT governance or steering committee. (2) The Finance department should make an ROI spreadsheet available to project teams and assign the appropriate discount rate. The discount rate should not be the same for all projects. The higher the degree of risk and complexity of the system to be built, the higher the discount rate should be set. (3) Make the ROI one of the deliverables at the end of the DEFINE step in any

330

chapter 8

managing for returns on it investments

project, as described in Chapter 3. (4) ROI calculations should be a consensus-building exercise. If there is no consensus on the ROI there is no point in continuing with the project. (5) If there is consensus and the ROI shows that the project produces a low NPV then there is no point in continuing with the project. (6) Only projects that have a consensus on costs and benefits and show a high NPV get to continue on into the DESIGN phase.

part 2 by joe stenzel return on intangibles: measuring and managing it capabilities Chapters 4, 5, and 6 demonstrate that accounting practices now go far beyond the balance sheet and income statement in IT best practice organizations. Strategic cost management, the Balanced Scorecard, and customer value management emphasize the ways that the leading performance indicators in the business process, customer, and learning perspectives create the monetary value eventually tallied from lagging information reported in the Financial perspective, balance sheet, and income statement. As discussed in Part 1 of this chapter, ROI calculation is a consensus-building process that depends on informed estimates of costs and benefits—the more tangible and measurable the better when it comes to investment decisions. Best IT investment practices depend on best cost and performance management practices. Good measurements become the information for good decisions. One of the CIO’s greatest challenges is that some of the most important returns on IT investment are intangible, hard to measure, and therefore hard to manage. The best practice CIO learns to first identify, understand, and deliberately manage IT intangibles before expecting them to carry any significant weight in ROI calculations for new IT project proposals. In many ways, the IT professional is more comfortable with intangibles than anyone else in the enterprise (with one exception). By definition, truly tangible items can by seen, heard, smelled, tasted, or touched, but the world of IT products and services is by nature intangible and representational as it allows people to share their thoughts with each other. The computer seems concrete and tangible; the software that instructs it, less so.

measuring and managing it capabilities

331

Interestingly, as a species with a highly evolved visual cortex, we believe that the items we see on the computer screen are the most tangible part of the system when in fact we are only looking at conventionally accepted symbols and representations of human thoughts and concepts—the penultimate intangible. This tendency to make the abstract concrete through systematic representation is actually good news for the tangibly dependent and the intangibly impaired. Someone will eventually find a way to make today’s intangibles more palpable and manageable, and that someone will probably hail from either IT or HR (the one exception). Anyone who has ever become frustrated with intangibles might spend a little time measuring and managing the ultimate intangible, employee behavior. Human behavior and the systems that enable human communication—the most difficult things to measure matter most of all. Human Resources professionals have become comfortable and very gifted with measuring and managing intangibles. This book’s final section borrows some ideas from these gifted individuals and applies those ideas to the many intangible investment and management challenges faced by the CIO and other information professionals as outlined in the previous chapters. This book has demonstrated how heavily CIO best practices focus on the measures and management of IT performance and how many of the returns on IT investments remain intangible. Part 2 of this chapter reviews the intangibles discussed in this book and presents ways of making IT productivity and learning more tangible and manageable by making them more measurable with a more concrete place in the ROI calculations. Most enterprises and IT organizations do not measure intangibles because intangibles are hard to measure. Part 1 of this chapter began with the question, “Is this project worth doing?” This section begins with a similar question: “Is there any real value or payoff in measuring and managing IT intangibles?” From 1960 through 1990, 75–90 percent of a company’s market value as determined by the product of stock price x shares outstanding could be predicted based on financial performance. After 1990, in both up and down markets, only 50 percent of a company’s market value can be directly tied to present earnings.1 The financial community attributes the “missing” value to intangibles. Customers of all kinds increasingly appreciate the

332

chapter 8

managing for returns on it investments

value of intangibles. Customers get to enjoy intangibles even when they cannot articulate them; CIOs need to learn how to measure and manage them to allow the IT organization to more successfully enable enterprise value. The next section presents a framework for measuring and managing intangible IT assets that enable enterprise strategy and thereby carry significant weight in the ROI calculation for new IT proposals.

a framework for measuring and managing it intangibles As discussed in Chapters 1 and 2, strategy and IT architecture establish the platform from which the IT organization accomplishes all its work. Strategies and architectures give people throughout the enterprise a conceptually tangible framework for understanding how their individual activities contribute to the achievement of common goals. To help enterprise leadership understand ways to measure, manage, and achieve a return on intangible investments and resources, HR researchers Dave Ulrich and Norm Smallwood have developed an Architecture for Intangibles.2 Their architecture builds progressively from basic leadership competencies up through concepts of increasing complexity (see Exhibit 8.2). Each level of this architecture carries a unique set of leadership responsibilities that build on the success of previous levels. The CIO who succeeds building level 1 establishes and defends the IT organization’s reputation in terms of its ability to deliver products and services as promised to internal and external stakeholders. Having established trust and the authority that accompanies trustworthy behavior and performance by the IT organization, the CIO works to define and communicate a compelling vision of the future with a growth strategy in terms of customer intimacy, system and service innovation, and expanded services at level 2 of this architecture. Building level 3 upon the trust, authority, and vision of levels 1 and 2, the CIO then supplies the support that the IT organization needs to build its core competencies and the intangible value those core competencies in turn pass along to the enterprise. Then and only then can the CIO work to further develop the IT organization’s capabilities and create enduring value for the entire enterprise. Ulrich and Smallwood make this architecture work because of the measures they choose to capture intangible value in the IT organization:

a framework for measuring and managing it intangibles

333

Building Value through IT Organization Capabilities

Aligning Technical Competencies

Compelling Strategy

Keeping Promises EXHIBIT

8.2

Architecture for Intangibles

These capabilities—the collective skills, abilities, and expertise of an organization—They represent the ways that people and resources are brought together to accomplish work. They form the identity and personality of the organization by defining what it is good at doing and, in the end, what it is.3

Identifying Intangibles Worth Managing The CIO’s first step when designing an architecture for measuring and managing IT intangibles is to select measures consistent with enterprise strategy. Fortunately, Ulrich and Smallwood have already established a starter set from researching well-managed companies that usually surpass

334

chapter 8

managing for returns on it investments

their competitors in several measures and remain at least on par with industry performance for the others:4 • Talent: Attract, motivate, and retain competent and committed people. • Speed: Make important changes rapidly. • Shared Mind-Set and Coherent Brand Identity: Ensure that employees and customers have positive and consistent images of and experiences with our organization. • Accountability: Obtain high performance from employees. • Collaboration: Work across boundaries to ensure both efficiency and leverage. • Learning: Generate and generalize ideas with impact. • Leadership: Embed leaders throughout the organization. • Customer Connectivity: Build enduring relationships of trust with targeted customers. • Strategic Unity: Articulate and share a strategic point of view. • Innovation: Perform well with new projects in terms of both content and process. • Efficiency: Manage costs. These measures of capability reflect the ways that intangible value surfaces from within the IT organization as it delivers on the competencies and abilities of its individuals. The art of designing a strategically aligned architecture of IT organization intangibles lies in selecting and customizing the measures that enable the strategic objectives of the enterprise by building and leveraging IT capabilities. The preceding chapters have already discussed ways the CIO can customize these measures of capability to fit the demands placed on the IT organization as it works to enable enterprise strategy. With its strategic focus, Chapter 1 describes concrete ways that CIOs can achieve accountability, collaboration, leadership, and strategic unity. Chapter 2 addresses the many ways IT architecture enables the work of IT governance, portfolio management, and building the IT organization so that the CIO can manage talent, shared mind-set and coherent brand identity, collaboration, leadership, and strategic unity. The third chapter’s focus on tactical agility shows how CIOs build speed, shared mind-set, accountability, collaboration,

a framework for measuring and managing it intangibles

335

learning, leadership, customer connectivity, strategic unity, innovation, and efficiency. Best practices demonstrate that CIOs have the tools they need to achieve more value from their intangible resources in the IT organization, but that value will not materialize or be sustainable unless the IT organization’s capabilities are continuously measured and deliberately managed. Begin this first step for designing an architecture for IT organization intangibles practically. Sit down with your leadership team, review the strategic plans of your enterprise and your IT organization in terms of these eleven capability measures, and select three critical measures. These three measures then need to be (1) ranked in terms of strategic importance, (2) customized to fit your organization’s specific strategic accountabilities, and (3) assessed according to how well they are currently performed. Next, review the remaining eight measures in the same manner. This exercise not only accomplishes the first step on the path to managing intangible IT value, but it immediately begins to build a sense of accountability, collaboration, learning, leadership, customer connectivity, and strategic unity within the IT organization. Choosing the Scope of Your Intangible Architecture Intangible capabilities focus on people, and the business of the IT organization is as much (or more) about services as it is about products. Like most other organizational functions, the IT organization is developing more and more specialized roles and services, each with its own distinct set of subfunctional capabilities. The CIO’s first scope-related decision is a matter of what gets examined, and it makes sense to gain experience with managing intangible value by measuring the capabilities of a few limited sections or departments within the IT organization. Start by working only with those sections that contribute most to your critical capabilities as determined by your strategy. Scope decisions also encompass information sources. Architectures can be rendered from a number of perspectives in a variety of dimensions. How complete does your information about the capabilities of your IT organization need to be? If that information comes from your experience alone, it might best be represented by a single dot; if you rely on only one other person for your capabilities information, your perspective is a onedimensional straight line.

336

chapter 8

managing for returns on it investments

To achieve a two-dimensional perspective, the CIO needs to involve several sources of information. The exercise described in the previous section with the leadership team comes closer to a 90-degree view of the IT organization’s capabilities. Is that enough? A true 360-degree view would involve input from representatives at all levels and all departments of the IT organization. Is that enough? After all, a 360-degree view is still constrained to two dimensions. A full, 720-degree view requires information input from sources outside the IT organization. How much is too much? The scope of information input to support an architecture of IT intangibles depends on the capabilities chosen as critical measures. IT organizations that select shared mindset and coherent brand identity, collaboration, and customer connectivity require significant outside information. On the other hand, organizations that choose to measure and manage talent, speed, accountability, learning, leadership, strategic unity, innovation, and efficiency might not need such broad perspectives. As with the selection of capability measures, customize measurement information sources to fit your intangible management intentions—with one caution. Ulrich and Smallwood emphasize that best practices organizations manage all eleven capability measures at least on par with industry competitors. Gathering IT Capability Performance Information In the third step to design an architecture for measuring and managing IT organization intangibles, the CIO conducts a capabilities audit using the measures and scope parameters established in the first two steps. A capabilities audit is an information survey that can be administered individually online, in small groups, or by any means that captures an assessment of how well the IT organization currently performs on its capabilities. Ulrich and Smallwood recommend a simple format that guides the respondent quickly through that data collection exercise.5 The first column lists the eleven essential organizational capabilities along with any additional capabilities the CIO wishes to add to customize the architecture according to strategic imperatives. The second column presents one or two questions that encapsulate what the IT organization needs to know about its current performance. These questions should be concise, directive, and tailored to the respondent. For example, the question that

a framework for measuring and managing it intangibles

337

accompanies Customer Connectivity on an audit survey to be completed by a member of the IT organization might read, “How well do we build long-lasting relationships based on trust with our internal and external customers?” For CIOs that choose to expand the audit survey beyond the IT organization, the Customer Connectivity question might read, “How well does the work of the IT organization staff help build long-lasting, trustworthy relationships based on your current experience?” Column three asks the respondent to assess the IT organization’s overall performance for each of the listed capabilities. Respondents reply using a simple 1–5 or 0–10 scale, where 0 is worst and 10 is best. In column 4, respondents numerically rank each IT organization capability in terms of need for improvement, where 1 indicates the capability with the highest priority. Open space in the fifth column gives the respondent an opportunity to add comments. Pool the Responses and Look for Capability Performance Gaps The capabilities audit survey identifies all the areas where respondents inside and outside the IT organization sense or experience performance gaps, but the CIO should not give equal weight and attention to all capability deficiencies. First, review the audit survey summary for performance on the three key capabilities identified during the selection process in step one. Then as performance patterns emerge for the three key capabilities, look for linkages to other related capabilities. For example, if Strategic Unity is one of your key capabilities, how well do you perform in Collaboration and Leadership capabilities? Similarly, do your Speed, Accountability, and Efficiency scores reveal a common pattern? Before moving to an action plan, scan the non-priority capabilities for any surprises. This is the time when the CIO and the IT organization’s leadership team pause to take stock of their original capabilities priorities in reference to enterprise strategy. Do the responses suggest a “missing” capability— one that was not originally considered but that has become apparent in the patterns of the responses? Capability performance patterns that call for immediate action come in three forms: (1) key capabilities that significantly under-perform, (2) poor performing non-priority capabilities that undermine the performance of key capabilities, and (3) significant differences in

338

chapter 8

managing for returns on it investments

the performance perceptions from respondents inside and outside the IT organization. Complete this step by formulating a short list of IT organization capabilities that each require an action plan for deliberate, iterative measurement and management to deliver strategic value, but select those capabilities that will have the most impact and will be the easiest to improve on the first cycle of this ongoing value management process. Take your time with this step in the design of your intangible architecture and invite an open atmosphere of input from representatives throughout the IT organization. This is a perfect opportunity for the CIO to show the IT organization how to keep promises, manage trade-offs as it develops a compelling strategy, align its technical competencies, and build strategic value by improving the capabilities of the organization and its people. Capabilities Improvement Action Planning Action plans address gaps in the IT organization strategic capabilities that appear in step three. Structure the overall action plan in three parts: (1) design a chronological agenda of the steps that the IT organization will take to address capabilities performance gaps, (2) establish a set of measures for each capability in the action plan, and (3) assign action plan leadership accountabilities. Whether the plan includes technology investments, training and education, or functional reorganization, establish steps or milestones with deadlines for each element of the action plan. Ulrich and Smallwood recommend a 90-day time frame for the execution of most plans after formulation.6 At this point, the process of building an architecture for measuring and managing IT organization intangibles has only measured employee and customer perceptions. Delivering ongoing strategic value depends on measuring how well the IT organization responds to the CIO’s investments made in the first part of the action plan. How well have the investments in technology, training, and functional reorganization paid off ? Has the IT leadership team chosen the right cause-and-effect relationships to represent its measurement and management thinking? Where does IT need to direct its next investments for measuring and managing IT capabilities and their intangible strategic value? Performance measurements answer all these questions and make the management of intangible value an iterative, sustainable

factoring intangibles into the roi equation

339

process. One of these ongoing measures is a regularly updated and repeated capabilities audit—measures that always work to add substance to the internal and external information detail as that detail becomes appropriate to the increasing maturity of the IT organization. Depending on the complexity and scope of the action plan, some IT staff member or team must be made accountable for each individual element of the plan with oversight from the CIO. CIO involvement is more than just a matter of direct executive participation. The rest of the IT organization has a chance to witness first-hand leadership promoting strategic unity, collaborative learning, innovation, efficiency, and accountability. Modeling capabilities is the best way for the CIO to tangibly demonstrate the architecture for intangibles.

factoring intangibles into the roi equation Quantifying intangible values (costs/revenue; resource outflows/inflows) for IT projects can be accomplished phase-by-phase in a similar fashion to cost/benefit analysis for project tangibles like hardware/software or database setup and maintenance. However, a phase-by-phase ROI of intangibles is probably too costly for the limited interim decision-making value available from phase-based investment information. Monitoring the tangible costs phase-by-phase is almost always sufficient to ascertain whether the project is on target because, for the most part, intangible costs and benefits become clear only after implementation. However, before launching the first phase of an IT project, the CIO and executive team can identify the major intangible risks and benefits associated with the project. The risk/benefit identification process serves two purposes: (1) Intangible elements guide IT staff at all phases of the project, but especially in the design phase; and (2) The CIO and executive team can develop measures for intangible project risks for use as the IT organization’s customers begin to work with the new system. How does the CIO who recognizes the strategic value of IT intangibles give appropriate weight to these elements in the ROI calculation for IT proposals? Enterprise leadership generally misses two critical factors when identifying and assessing key intangibles. (1) What factors do we expect to change for the better such as customer response time improvements from a

340

chapter 8

managing for returns on it investments

CRM implementation? (2) What might go terribly wrong and subsequently impact both tangible investment outcomes in terms of both the total cost of implementation and intangible resource impacts, such as irritable customer service agents who are frustrated with the latest implementation leading to insulted customers and lost sales? Best practice CIOs and their executive peers learn to apply the same risk/benefit rigor to the management of intangibles that they use for the management of tangible resources. Although intangible results are not measurable until after the actual implementation, an awareness of intangible benefits and risks plays an important guiding role throughout the project. Intangible values guide decision making for the tangible measurement categories before and during project implementation so that the enterprise can achieve a greater total ROI. The detailed schedule of tangible ROI benefits in Exhibit 8.1 shows three categories: (1) direct benefits such as time saved on proposals, (2) incremental benefits such as winning more proposals, and (3) cost-avoidance benefits such as avoiding the need to hire new staff as the business grows. On closer inspection, these categories actually serve as performance measures that guide decision makers in assessing the success of the IT investment. In a very real way, these performance measures function as the checks and balances on the project’s total tangible ROI calculation itself. These tangible measures of total ROI keep the project implementation assessment honest. Examining and Weighting Intangibles As with all performance management practices, the more attention enterprise leadership gives to measuring intangible performance elements, the more tangible they become (see Exhibit 8.3). For example, maintaining or growing market share has long been a matter of perspective in terms of who does the counting. Competitive pricing information once seemed out of reach. Formerly intangible, these measurements, including market share and price advantage, have recently matured into more actionable customer preference information gathering and pricing strategies based on multiple variables such as time to market, product maturity curve, and time in market prior to entry by competitors. If the executive team expects the IT project to impact measures such as these, measurement selection and monitoring, as well as the related decision

factoring intangibles into the roi equation

Potential Costs

Strengths we don’t want to lose 1. Field Service Customer Ratings Measurable Risk: Extra incremental time spent entering data into new system impairs customer service 2. Timely and Accurate Proposals Measurable Risk: Added complexity of new application leads to calculation errors

Current Performance

4.4/5

341

Goal

Maintain 4.4

On Time: 98% Maintain at 98% Accuracy: 91% Increase to 95%

Benefits

Anticipated changes for the better

Data Input

1. Faster Customer Information Processing Measurable Cause: Speech recognition software on field representative laptops

Average time per customer

2. Extended Time for Price-point Advantage Measurable Cause: Improved field service enabled by IT innovation adds value to the product

EXHIBIT

8.3

Advantage time 11 months before and 2 months after implementation

Examining IT Project Intangibles

making on IT project status becomes highly valuable operational information. The measures selected reflect enterprise leadership insights— they reveal the business assumptions behind the measures. For example, “We chose to measure customer ratings for our field reps because we believe that our field reps are our most important customer interface listening to our customers when things go wrong, and routine maintenance causes down time for the customer. Therefore, any new IT project or system must not interfere or deteriorate our field rep services in the eyes of our customers.” Executives must labor through measurement selection, logic, description, and goals to identify both risks (strengths we don’t want to lose) and benefits (changes for the better). Note the logic in Exhibit 8.3. Executive leadership identifies strengths in terms of cause-and-effect relationships to the risks associated with potential failures and interferences that might result from the new IT project implementation. Leadership then highlights cause-and-effect relationships between anticipated future benefits with direct reference to changes enabled by the IT project. The greatest challenge of such mature approaches is that baseline measurements have not yet been calculated, examined, and used in the

342

chapter 8

managing for returns on it investments

deliberate manner imposed by an architecture for IT intangibles. A baseline of data and experience with intangible performance management allows intangible value to carry more weight in the ROI calculation. A related challenge is assurance that the decision makers are facile with causeand-effect thinking on an operational level. Strategy mapping is an example of this kind of thinking. Finally, responsibility for manager impact of the new IT project must be shouldered by appropriate people at whatever level they may be in the enterprise hierarchy. Obviously, this means that just about everyone in the enterprise needs to be able to think more tangibly about intangibles. Naturally, an IT project must be of sufficient magnitude to warrant all this work in the intangible arena. If it isn’t, or if the implementation isn’t expected to impact operations or customers (e.g., a tax system), then follow the advice in the first part of this chapter: the simpler the better. Because many IT systems have an ENL of about three years, it is prudent to assure that new projects will not damage or destroy enterprise strengths built over decades. IT leadership is a practice in managing intangibles, and strategic IT leadership explicitly links IT investments with strategic objectives, teasing out the concrete process and measurable result elements of enterprise strategic objectives and measuring them before, during, and after any IT project implementation. Existing accounting ROI methods (DCF, payback, IRR) have been translated from ROI on fixed assets (e.g., new machines) directly to IT and its many intangible assets, and the use of accounting ROI methods is inadequate to support executive decision making. Although cost may always be one of the enterprise’s most important performance measures, cost information always lags leading performance indicators. The only way that the CIO can effectively judge and represent the total ROI for new IT projects is to build a concrete set of reproducible, manageable performance measurements of the IT organization’s intangible capabilities. In time, enterprise decision makers will learn the monetary value of documented IT organization talent, speed, shared mind-set, accountability, collaboration, learning, leadership, customer connectivity, strategic unity, innovation, and other intangible assets, and they will invest in value-enabling IT projects supported by these assets.

item pricing system—total estimated costs & benefits

343

appendix 8A. Sample ROI Calculation

item pricing system—total estimated costs & benefits Project Description Build system to assist staff of account development group to more quickly create contract proposals and explore impact of different product cost and pricing structures. Monitor status of existing contracts and provide notice before cost supports expire. project cost & benefits (dollars in thousands)

Qtr 1 Hardware & Software Development Costs Operating Costs Total Costs Direct Benefits Incremental Benefits Cost Avoidance Benefits Total Benefits Net Benefits Cumulative Benefits Discount Rate Net Present Value

(7.0) (68.5) 0.0 (75.5) 0.0 0.0 0.0 0.0 ($75.5) ($75.5) 5% 115.2

Qtr 2

(1.2) (1.2) 8.4 30.0 18.2 56.6

Qtr 3

(1.2) (1.2) 8.4 30.0 18.2 56.6

Qtr 4

(1.2) (1.2) 8.4 30.0 18.2 56.6

Qtr 5

Totals

(1.2) (1.2)

(7.0) (68.5) (4.8) (80.3)

8.4 30.0 18.2 56.6

33.6 120.0 72.8 226.4

$55.4 $55.4 $55.4 $55.4 $146.1 ($20.1) $35.3 $90.7 $146.1 (5% per Qtr. = 20% Annual Discount Rate)

Note: The riskier the project the higher the NPV should be to cover the risk of building and operating the system.

344

chapter 8

managing for returns on it investments

detailed schedule of costs cost of hardware & software (dollars in thousands)

Item

Description

Cost

Application Server

Server to run the system—allocate 1/3 of server cost

3.0

Personal Computers

PCs for use by staff—allocate 1/3 of cost

3.0

Programming language

Allocated cost of programming language and tools

0.5

SQL Server database

Allocated cost of SQL Server and tools

0.5 $7.0

Total

cost of development (dollars in thousands)

Task

Description

Cost

Define Phase

5 days at average cost of $900 per day

Design Phase

15 days at average cost of $900 per day

13.5

Build Phase—Coding

30 days at average cost of $900 per day

27.0

Build Phase—Test & Train

30 days at average cost of $650 per day

19.5

5 days at average cost of $800 per day

4.0

Build Phase—Roll Out

4.5

$68.5

Total

cost of operation (dollars in thousands)

Activity

Description

Cost

Qtr 1 Qtr 2

Incremental costs of operating the system

1.2

Qtr 3

Incremental costs of operating the system

1.2

Qtr 4

Incremental costs of operating the system

1.2

Qtr 5

Incremental costs of operating the system

1.2

Total

$4.8

detailed schedule of benefits

345

detailed schedule of benefits DIRECT BENEFITS (revenue and cost savings due to productivity improvements) Direct Benefit 1 Direct Benefit 2

Save staff time on proposal creation: 10 proposals per Qtr.; 20 Hrs. per proposal; $35/Hr. Do 2 additional proposals per Qtr.; 20 Hrs/proposal; $35/Hr.

value of productivity improvement (dollars in thousands)

Qtr 1

Qtr 2

Qtr 3

Qtr 4

Qtr 5

Save time on proposals

7.0

7.0

7.0

7.0

Do 2 additional proposals

1.4

1.4

1.4

1.4

$8.4

$8.4

$8.4

$8.4

Total Direct Benefit

$0.0

INCREMENTAL BENEFITS (benefits due in part to new system e.g., attract new customers, make better decisions, etc.) Incremental Benefit 1

Win more proposals due to better pricing decisions: $30,000 per Qtr in additional revenue —

Incremental Benefit 2

value of incremental benefit (dollars in thousands)

Qtr 1

Qtr 2

Qtr 3

Qtr 4

Qtr 5

Win more proposals

30.0

30.0

30.0

30.0

Incremental Benefit 2

—

—

—

—

$30.0

$30.0

$30.0

$30.0

Total Incr Benefit

$0.0

346

chapter 8

managing for returns on it investments

COST AVOIDANCE BENEFITS (savings related to growing business without needing to add new staff or incurring other expenses) Cost Avoidance 1 Cost Avoidance 2

Avoid hiring more staff as business grows: half a person per year; $35/Hr. —

value of cost avoidance (dollars in thousands)

Cost Avoidance 1 Cost Avoidance 2 Total CA Benefit

Qtr 1

Qtr 2

Qtr 3

Qtr 4

Qtr 5

$0.0

18.2 — $18.2

18.2 — $18.2

18.2 — $18.2

18.2 — $18.2

INTANGIBLE BENEFITS (benefits that are hard to quantify in dollar amounts but which should be identified and listed) Maintain Competitive Advantages

• Item Pricing system should be a competitive benefit for next 2 yrs. • After that, it will simply become a necessary tool to do business Provide Superior Service Levels

• Provide customers and prospects with timely and accurate proposals Increase Job Satisfaction

• Release staff from tedious and time-consuming pricing calculations • Allow staff to focus on more valuable and interesting work ■ notes 1. Lev, B. (2001) Intangibles: Management, measuring, and reporting. Washington, DC: Brookings Institute. 2. Dave Ulrich and Norm Smallwood, “HR’s New ROI: Return on Intangibles”, Human Resource Management, Summer 2005, 138-139. 3. Dave Ulrich and Norm Smallwood, “Capitalizing on Capabilities”, Harvard Business Review, June 2004, 2. 4. See note 3 above, pages 3-5. 5. See note 3 above, page 6. 6. See note 3 above, page 9.

Index A Activity-based cost and management (ABC/M), 156–182: activity-based cost accounting systems and, 158, 270–274 capacity and, 175–182 cost driver analysis, 158 customizing financial views on the enterprise, 168 decision information and, 164–174 defined, 156 deployment for IT Finance, 158–164 service level agreements and, 165 Agility: case studies, 132–136 core techniques, 103–112: data modeling, 106

joint application design, 104 object-oriented designing and programming, 108–111 system prototyping, 107 system test and roll out, 111 Define-Design-Build process, 99–103: Define Phase framework, 113–121 outputs, 118 Design Phase workflow and technical system, 121–127: creating project plan and budget, 123–124 deliverables, 125 349

350

index

Agility (Continued): Build Phase of system construction and roll out, 127–132: deliverables, 131 defined, 84 process loops, 85–88: monitoring and deciding, 88–92 improving existing processes, 92–96 creating new processes, 96–97 system builder, 122 system dynamics, 98 Architecture application, 53 business, 52 enterprise. See Enterprise architecture information, 53 intangibles, 332 technology, 52

B Balanced Scorecard case study, 214–221 intangible assets and, 191–194 IT Balanced Scorecard: building, 204–213:

development phase, 207–213 planning phase, 206 IT Finance and, 144–147: two-pronged approach, 144 IT performance scorecards, 145–147 measurement perspectives, 4, 199–204 strategy and, 194–198 strategy mapping and, 208–210 Best Buy, 225 Boyd Cycle, 88–92 Business intelligence: Activity-based costing and management and, 164 CIO responsibilities, 227 performance management and, 267–270 tools and software technologies, 260 Business-to-customer pressures, 228–230

C Capability audit, 336 Capacity, 175–182

index

Chapter executive summaries, xii–xvii Chief Information Officer, ix: business intelligence and, 227 customer relationship management role, 267–270 difficulties accelerating IT development, 143 responsibilities, 1 Chief Marketing Officer, 267–270 Chief Technology Officer, xvii CIO. See Chief Information Officer CIO Survival Guide, xxi CLV. See Customer lifetime value CRM. See Customer relationship management CVM. See Customer value management Cokins, Gary, xix Customer lifetime value (CLV), 249–260: activity-based costing and, 265–257

351

calculation: assumptions, 252, 255 customer equity, 257 Customer value management (CMV) and, 256–260 discounted cash flow and, 256 equation, 258 defined, 249 revenue and cost elements, 252 Customer relationship management (CRM): customers rather than products, 238 foundation, 23 loyalty, 260–265 market delivery systems, 238 marketing performance metrics, 231 metrics: lifetime value, 249–260 profitability and value, 246–249 profitability drivers, 234 segmentation, 234–237 shareholder value considerations, 260–267, 270

352

index

Customer value management (CVM), 256–260

D Data modeling, 106 Define-Design-Build process, 99–103: Define Phase framework, 113–121: outputs, 118 Design Phase workflow and technical system, 121–127: creating project plan and budget, 123 deliverables, 125 Build Phase of system construction and roll out, 127–132: deliverables, 131 DMAIC process, 5 steps, 92–96

E e-business systems infrastructure, 118 Economic customer value, 242–249: cost to serve issues, 243

customer metrics: lifetime value: 249–260 profitability and value, 246–249 customers versus cost reduction focus, 228 profitable sales volume, 244 Enterprise architecture, 48–63: case study, 73–79 components, 51–54 defined, 49 governance and portfolio management and, 63–70 IT organization development, 70 management frameworks, 5 practices checklist, 79 process integration, 68 structural organization, 54–57 toolkit, 67 value creation, 58–63

F Finance: alternative strategic implementation tools, 156

index

roles, 152–156 service level agreements, 151: costs, 166–174 legacy, 165 Flemming, William, xix

G Golden State University, 73–79 Governance: defined, 65 link to enterprise architecture, 63–70 SAS steps to IT governance, 141

353

measuring and managing, 232–242: action planning, 338 architecture for intangibles, 332 factoring intangibles into the ROI equation, 339–342 selecting intangibles for measurement, 333–335 capability audit, 336 IT. See Information Technology IT Finance. See Finance

J Joint application design, 104 H Hill, Anthony, xx Hugos, Michael, xx

I Information technology: Architecture-centric, 59 Organizational development, 70 Intangible assets: Balanced Scorecard and, 191–194 market valuation, 331

N Niven, Paul, xxi

O Object-oriented design and programming, 108 Outsourcee, 276 Outsourcer, 276 Outsourcing: deciding what to outsource, 290

354

index

Outsourcing (Continued): defined, 275 managing the outsourcing relationship, 302 methodology, 292–302 contract negotiation, 301 rationale and benefits, 292 request for information, 296–298 request for proposal, 298–300 site visit, 300 survey potential partners, 295 steps, 293 timeline, 294 reasons for, 279–290: access to key skills, 285 cost savings, 280–285 business continuity, 290 productivity, 287 risks, 291 sample communication documents, 306–320 spending patterns, 277 strategic operations and applications, 278

P Performance scorecards for executives, 145–147

Portfolio management: customer relationship, 232–242: customer segmentation, 234–237 customers rather than products, 238 foundation, 233 market delivery systems, 238 profitability drivers, 234 enterprise architecture, 63–70 ROI on systems, 326–328 Premises of CIO Best Practices, x–xi Process mapping, 105 Project development: tactical principles, 20–23 Project evaluation checklist, 36–41 Project office, 129

R Return on investment (ROI): categories of IT investments, 327 defining costs and benefits, 323–326 determining project merit, 322–330, 343–346 evaluation process, 329

index

measuring and managing intangibles and, 232–242: action planning, 338 architecture for intangibles, 332 factoring intangibles into the ROI equation, 339–342 selecting intangibles for measurement, 333–335 capability audit, 336 portfolio management, 326–328 process selection, 322 Sales and Marketing, 227, 231 sample ROI calculation, 343–346 Selecting system investments, 328 Risk, 31–33 ROI. See Return on investment

S Sales profitability, 226 SAS IT governance maturity model, 141: bottom-up view, 148 top-down view, 150

355

Schubert, Karl, xxi Service costs, 166–174 Six-Sigma, 92 Smallwood, Norman, 332 Strategic performance management. See Balanced Scorecard Strategy: Balanced Scorecard and, 194–198 barriers, 194–197 communicating, 24–33 customer value and, 226 defined, 4–6 execution, 17–20 formulation in high change environments, 7–11 framework for thinking, 6, 8 guidelines for designing IT systems, 11–17 realization funnel, 48 relationship of IT strategy to enterprise strategy, 3–7, 43–46 revenue and profit opportunities, 232–233 supply chain systems development, 18 timelines, 23

356

index

Strategy Mapping: Balanced Scorecard and, 208–210 IT Finance, 148–152 Stratton, Alan, xxi Systems: design and roll out, 129–130 development lifecycle (SDLC), 56 opportunities, 5 prototyping, 107 test and roll out, 111–112

T Tactics: defined, 7 principles for running projects, 20–23 Time-boxing, 101

U Ulrich, David, 332