How To Succeed In The Enterprise Software Market

How to Succeed in the Enterprise Software Market Craig Le Clair ADP Brokerage Services, USA CYBERTECH PUBLISHING Hersh...

Author: Craig Le Clair

119 downloads 1394 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

How to Succeed in the Enterprise Software Market Craig Le Clair ADP Brokerage Services, USA

CYBERTECH PUBLISHING Hershey • London • Melbourne • Singapore

Acquisitions Editor: Development Editor: Senior Managing Editor: Managing Editor: Copy Editor: Typesetter: Cover Design: Printed at:

Renée Davies Kristin Roth Amanda Appicello Jennifer Neidig Dawne Brooks Cindy Consonery Lisa Tosheff Yurchak Printing Inc.

Published in the United States of America by CyberTech Publishing (an imprint of Idea Group Inc.) 701 E. Chocolate Avenue Hershey PA 17033 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: [email protected] Web site: http://www.cybertech-pub.com and in the United Kingdom by CyberTech Publishing (an imprint of Idea Group Inc.) 3 Henrietta Street Covent Garden London WC2E 8LU Tel: 44 20 7240 0856 Fax: 44 20 7379 3313 Web site: http://www.eurospan.co.uk Copyright © 2005 by Idea Group Inc. All rights reserved. No part of this book may be reproduced, stored or distributed in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Product or company names used in this book are for identification purposes only. Inclusion of the names of the products or companies does not indicate a claim of ownership by IGI of the trademark or registered trademark. Library of Congress Cataloging-in-Publication Data Le Clair, Craig, 1953How to succeed in the enterprise software market / Craig Le Clair. p. cm. Summary: "This book provides a clear and simple framework to help software companies understand enterprise-level information systems, and help them build software products compatible with organizations, humans, and complex customer environments"--Provided by publisher. Includes bibliographical references and index. ISBN 1-59140-805-9 (h/c) -- ISBN 1-59140-600-5 (s/c) -- ISBN 1-59140-601-3 (ebook) 1. Business--Computer programs. 2. Computer software industry. 3. Computer software--Development. I. Title. HF5548.2.L35 2005 005'.068--dc22 2004029851 British Cataloguing in Publication Data A Cataloguing in Publication record for this book is available from the British Library. All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher.

Dedication I dedicate this book to my wife and partner, Zaurie, who suffered through my many days of distraction.

How to Succeed in the Enterprise Software Market Table of Contents Part I: The Discipline of Success Preface .......................................................................................................... ix Acknowledgments ...................................................................................... xi Chapter I. An Implementation View of Value ........................................ 1 Why is Enterprise Software Different? ......................................... 3 A System to Factor in the Customer ............................................... 4 The Customer-Focused View .......................................................... 4 The Software Development Process .............................................. 8 Not Your Typical Case Studies ....................................................... 8 A Cause for Optimism ...................................................................... 9 Chapter II. Behavioral Change ............................................................... 10 A Socio-Technical Perspective is Needed for Enterprise Systems ............................................................................................ 12 How to Better Understand Behavioral Change for Your Product ...................................................................................... 13 A: Understand the Interdependence of System Components .... 14 B: Understand User’s Behavior ................................................... 15 C: Capture the Attitudes and Beliefs of Key Stakeholders ....... 20 D: Determine the Value/Behavioral Change Tradeoff .............. 25 Case Studies ............................................................................. 28 Behavioral Change in a New Account Processing Application ................................................................................ 29 ObjectStore and Behavioral Change .......................................... 31 Behavioral Change (Electronic Billing Presentment) ................ 34 A Case of Attitude .......................................................................... 35 Chapter III. Assimilation ......................................................................... 40 Enterprise Software’s Dilemma .................................................... 41 Diffusion of Innovation (DOI) Theory ........................................ 42

The Dimensions of Assimilation .................................................... 43 A: Replace the Complete Business Process ................................ 46 B: Technology Leverage ............................................................... 48 C: Bridging to the Old System ...................................................... 49 D: Appearance of a Significant Industry Value Gap ................ 50 Case Studies in Assimilation ......................................................... 51 Social Networking Corporation ................................................... 51 NewRiver, Inc. ................................................................................ 55 Build Intellectual Property Protection Around Your Assimilation Strategy ................................................................ 57 Appendix A ..................................................................................... 63 Chapter IV. Implementation Difficulty .................................................. 65 Infrastructure Burnout .................................................................. 66 The Integration Gap ...................................................................... 70 Implementation Help ...................................................................... 71 A: Managing the Service to License Ration ............................... 72 B: Develop a Product Adaptation Strategy, Vertical Applications and a “Best Practice” Approach ..................... 75 C: Monitor Your Sales Cycle ........................................................ 77 D: Keep the Solution Focused ..................................................... 79 E: Understand the Interdependence of Your Software with the Customer’s Systems .................................................... 80 F: Provide a “Process” View of Training with “Change Management” Support ............................................................ 82 Case Studies ................................................................................... 83 Electronic Bill Presentment and Payment ................................... 84 OpenPages ..................................................................................... 85 Web Services .................................................................................. 89 Summary ......................................................................................... 93 Appendix A ..................................................................................... 97 Chapter V. Customer Core Competency .............................................. 98 Competing with Your Customers .................................................. 99 Flying Too Close to the Sun ....................................................... 100 Controlling Intellectual Property ............................................... 101 Chapter VI. The Customer-Focused Business Case ........................ 106 Productivity Trends ..................................................................... 106 Business Case Challenges .......................................................... 108 A: A History of Unrealized Cost Savings .................................. 109 B: The Customer’s Unique Perspective ..................................... 111 C: Behaviorally-Dependent Business Cases ............................. 114 Building the Business Case ......................................................... 117

A: Build the Business Process Model ........................................ 117 B: Identify Strategic Goals Using Performance and Risk Management Models ..................................................... 118 C: Apply Performance Metrics ................................................... 120 D: Apply Business Case Financials ........................................... 122 E: Monitor and Improve ............................................................. 123 Summary ....................................................................................... 123 Appendix A ................................................................................... 126 Appendix B ................................................................................... 127 Chapter VII. Assessing Your Effect on the Customer ..................... 129 Plotting Customer-Focus Variables ........................................... 129 The Product Assessment Grid ..................................................... 132 Using the Model to Improve ....................................................... 134 Mapping of Technology Markets .............................................. 134 Appendix A ................................................................................... 137

Part II: A Customer-Focused Approach to Value Discovery in Developing Markets Chapter VIII. Product Development Background ............................ 141 The Difficult Task of Creating New Products .......................... 141 Software Development Background .......................................... 147 The State of Software Development in Enterprise Software ... 149 Why Are “One-Offs” So Bad? ................................................... 152 Appendix A ................................................................................... 155 Chapter IX. A Customer-Focused Value Discovery Process .......... 161 The Discovery Framework ......................................................... 162 A: Concept Stage (Rapid Market Assessment) ......................... 163 B: Research (Value Gap Discovery) .......................................... 164 C: Initial Development (Legitimate Use of “Vaporware”) ...... 168 D: Assessment and Validation (Tying Balanced Scorecard to the Customer-Focus Variables) ........................................ 171 Case Studies ................................................................................. 173 Summary ....................................................................................... 181 Appendix A ................................................................................... 183 Chapter X. Strategic Assessment ......................................................... 186 The Vision Thing .......................................................................... 187 Strategic Assessment .................................................................... 189 Description of the Assessment Model ........................................ 189

Distinguishing Between Value Drivers and the Value Proposition ............................................................................. 190 Determining Revenue Potential: The Difficulty of Market Assessment .............................................................................. 192 Using the Assessment Model ...................................................... 195 Case Study .................................................................................... 195 Summary ....................................................................................... 200

Part III: Management Issues in Value Discovery Chapter XI. Organizational Issues of Emerging Companies ........... 203 What is an Emerging Initiative? ................................................. 204 Relationship of Marketing, Sales, and Engineering ............... 208 CobiT and the Increasing Governance of IT ........................... 213 Chapter XII. Creating Value Through Alliances ............................... 216 To Partner of Not? ...................................................................... 217 Alliance Paths for the Emerging Company ............................... 217 Avoiding Conflict ......................................................................... 220 Determining the Target Partners ............................................... 222 Drawing Alliance Maps: Telecommunications ......................... 223 Drawing Alliance Maps: Financial Services ............................ 225 Alliance Execution Issues ........................................................... 226 Summary ....................................................................................... 230 Chapter XIII. Value Creation Using Offshore Resources ............... 232 Getting Product Out the Door ........................................................... Use of Business Process Technology with Offshore Resources ...................................................................................... 233 It’s Not Just Cheap Labor Anymore .......................................... 234 The Time Zone Advantage ........................................................... 234 Offshore Issues ............................................................................ 235 A: Language and Culture ........................................................... 235 B: Control of Intellectual Property ............................................ 235 C: Security of Sensitive Data ..................................................... 236 D: Lack of Process in Offshoring ............................................. 237 E: Bias Toward Substitution of Labor for Technology ........... 238 F: Use of Propietary versus Off-the-Shelf Technologies ........ 238 An Offshore Development Approach ......................................... 239 Summary ....................................................................................... 243

viii

Chapter XIV. Company Valuation and Financing ............................... 246 On a Short Leash ......................................................................... 247 Investment Banking ..................................................................... 248 New Market Creation .................................................................. 249 A Model to Position the Company ............................................. 251 Summary ....................................................................................... 255 Issues from the Boardroom ......................................................... 253 Appendix A ................................................................................... 258 Glossary ..................................................................................................... 260 About the Author .................................................................................... 264 Index ....................................................................................................... 265

ix

Preface

Introduction My introduction to technology came in 1984 at the Mitre Corporation where I was allowed to experiment with one of the first version of the SUN workstation. Later it would be called the “first networked computer” and I was part of an early team building software protocols and device drivers to make it work. Along with several members of my team, I went to BBN Communications. BBN designed and built the foundation of the Internet, providing innovations such as sending the first e-mail and developing the first Internet router. During my tenure there, from 1984 to 1990 the Internet expanded from 1000 connected computers to 100,000, well on its way to reaching the 100 million computers connected today. During that time, BBN struggled to move the Internet out of the research environment to corporate America. From there I went to several emerging software companies focused on document management, content management and business process automation. These businesses experienced the high growth and roller-coaster reality of the high technology world. In these pursuits, I always tried to make customers happy. It was good business and made the job more fun, but this did not always happen. In many cases, the vision of what the technology could do was not realized. Customer projects always seemed to have technology and people problems. The people who understood each of these were rarely in the same room, and when they were, spoke different languages. There was no question that when a technology company asks a customer to buy something, they were asking them to change a lot. It became clear that the

x

enterprise software industry required a perspective and set of tools that understood how the customer is changed, and build products that dealt with that change better. What seemed to be missing was a clear and simple framework to help understand the customer experience, one that helped to build software products compatible with organizations and humans. In the industry, we had a failure to communicate. On the one hand, we had the hard science approach to building systems that developed from standard engineering practice. This “hard science” culture did not incorporate people and organizations into their methodologies. On the other hand, we had soft science approaches with roots in social psychology, anthropology, general systems theory and socio-technical systems. These lacked sufficient engineering structure to build complex systems. People trained in these important disciplines seldom played a critical role in developing new products. The gap between these two camps has existed and been debated for some time. But despite this debate and the extensive work in academia, a compelling case had yet to be made to practitioners in the technology business. These professionals make the critical product and business decisions, and yet do not have practical frameworks to merge the strength of the two perspectives. The good research work available was having little effect on the practice in the industry. Let me be clear on my background. Although I spent some time in academia and had the pleasure to teach for a few years, I am at the core a practitioner. My work life has been spent more worried about schedules, budgets and revenue goals then about social-technical systems or the appropriate software development model. The arguments made throughout this book draw from practical experience and the extensive research available on the topics covered here. My apologies up front for what may be viewed as a “light” treatment of some of this research work. The primary goal was to make this work as useable as possible. We are all biased by our experience, whether it is academic or corporate, and I will admit to my failings in this area. I’ve always enjoyed working with bright technical and business teams, figuring out new technology for new markets. This book is the tool kit for creating successful software applications that I’d always wished for. I hope some of these experiences prove valuable to others.

xi

Acknowledgments There are many who have contributed to this book, but I’d most like to thank those that gave me encouragement in the early days of the effort. They took their valuable time and struggled through early drafts of this work. These include Steve Krensky, author of more than 70 books, who provided support and insight; Peter Morgan of OpenPages, whose out-ofthe-box thinking was of great help; and Dan Gregory, whose experience in the publishing world was helpful. Also, I’d like to thank the team at the Idea Group, who combined a strong process with a desire to enhance knowledge in the industry.

Part I The Discipline of Success

An Implementation View of Value 1

Chapter I

An Implementation View of Value

“The most powerful weapon on earth is the human soul on fire.” Marshall Foch

Enterprise-level information systems are the information technologies (IT) that firms use to support their core business processes, such as sales, finance and operations. Well-known examples of these include enterprise resource planning (ERP), customer relationship management (CRM), business intelligence (BI) and supply chain management (SCM). There are also thousands of more specialized applications. The IT industry has grown to $800 billion and can be divided into the segments shown in Figure 1.1 (Gerstner, 2002). Enterprise software is in the middle of Figure 1.1 and is the focus of this book. The bottom of the figure is hardware where billions of dollars are invested in equipment required to implement the enterprise software. The top is services, which includes maintenance of the hardware and software as well as implementation and advice services. The firms that implement these systems to support their business process, almost inevitably, face a difficult implementation. Enterprise-level information technologies are often purchased in the form of software packages that are Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

2 Le Clair

Figure 1.1. The $800 billion IT industry Consulting Systems Integration Business Process Outsourcing Enterprise Resource Planning

Content and Document Management

Supply Chain Management

Customer Relationship Management

Specialized Applications

Database Management Systems

Collaboration and Knowledge Management Applications/Transactions Servers Security Software

Application Development Tools Network and Systems Management Business Intelligence

Networking Storage

Workstation & Servers Displays

Services

Enterprise Software

Hardware

created to support the requirements of a wide variety of firms, and may not perfectly address specific business needs or fit into the organization they hope to serve. As a result, firms must adapt their organizations and internal technology to fit the solution. These changes introduce potentially serious problems and have resulted in a high failure rate for enterprise software projects. Overcoming these problems requires a socio-technical perspective that implements systems from an organizational and human perspective. At this point, software companies are too concerned with how different they are from each other, and not enough with how different the customer is after their technology is installed. That difference, the effect on customer, is the wild card. It can make a software company successful or not and it is what this book is about. This book reviews the leading research on how technology affects humans and organizations, how technology is adopted, and the best practices in system development. The goal is to combine this with “best practices” from the industry to address several patterns in the software industry, including: •

•

We struggle to design solutions that work for people and their organizations. As a result, there is a low level of technology adoption that hurts many promising solutions. Our customers have difficultly installing our products and realizing their true value. We do not easily fit into their infrastructure and we tend to underestimate their challenge.

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


•

• •

We approach customers with an attitude of disruption. We think in terms of disruptive products rather ones that assimilate into the customer environment. We ignore the strategic objectives of the firms we sell to and we do not take them into account when developing our business cases. Our product development methods such as the systems development and life cycle (SDLC) model do not capture the entrepreneurial process of finding and exploiting customer value. As a result, software companies until late in their maturity do not use complete system development methodologies.

Why is Enterprise Software Different? Why is the enterprise software business different enough from others to require an implementation view of value? The difference is that most businesses produce tangible products. Your new car weighs several tons and you can feel and smell the new seats. It has new features and is probably faster than what you traded in. It will also be more reliable. These add up to tangible value. There is also very little change in behavior required to use the new car. The steering wheel is in the same place as your previous one. The radio and controls will be a little different but within a week you probably have these mastered. Further, there is no implementation event. You pick it up and it just works. In a perfect world, software would be designed in the same way, with products that are not dependent on changes in the customer’s technical, human, organizational, economic and strategic balance. Unfortunatly, when a software company asks a customer to buy something, they are asking that organization to change for the following reasons: •

•

Acceptance by the user, unlike more tangible products, determines the success of an enterprise software product. A software product is successful only when users and their managers adopt the technology. Secondly, unlike most products, installing enterprise software is a big deal. Customers commit time and resources and projects often fail. The


4 Le Clair

•

•

value of the software product is affected by the degree of implementation struggle involved. Thirdly, the software at its core is a form of innovation, which follows a complex process of assimilation. A good software product nestles into the customer environment and gradually overtakes competing solutions. This process requires understanding the complete business process, and building bridges to the existing systems. Fourthly, enterprise software supports intangible and strategic goals of the companies they serve. It blends the supplier’s intellectual property with the customers and requires new ways to understand and explain the value created.

A System to Factor in the Customer Part One of this book describes five customer-focused categories required to be successful. An overall assessment model for enterprise software follows these. The five categories of customer change are supported with research from a variety of disciplines. Part Two proposes a framework to factor in the five customer-focused areas. It includes a full product management model tailored to finding new products in new markets. The model draws on SDLC and object-oriented design approaches. A strategic assessment approach is described to help select the right software projects for the company to pursue. Part Three describes important management issues in the software business. These include the precarious task of forming industry alliances to help the assimilation process, how to leverage offshore software development, and the role of financing on the emerging software company.

The Customer-Focused View To compare the benefits of a product with the amount of change and accompanying pain, we developed “five customer-focused views” to understand the amount of customer change to ensure a compelling value ratio is



provided. A quick overview is provided. The following chapters provide a detailed view of each.

Behavioral Change Software companies use the latest and greatest technology and believe completely in their new solution. They assume the behavior of the business or consumer will adjust to use it and this continues to be a dangerous assumption In speaking with many customers, it is just not possible to deploy a new technology without affecting the receiving organization and the humans that will use it. Yet the software industry seems to not realize this and does not invest the time to understand what the customer’s behavior is before a system is installed. The best practices from human factors, HCI and other disciplines are not used to determine and minimize the amount of behavioral change. Even though the potential customer’s attitude is often more important than the product’s usability, these are largely ignored. These omissions weaken the value of many software companies. Behavioral change obstacles have destroyed some of our most promising software products. ObjectStore, for example, was the first successful objectoriented database provider and pioneered several innovations important to the advancement of that technology. But they were forced from the mainstream database market. Despite technical superiority, customers were not willing to absorb the behavioral change required for their product. The hurdles for behavioral change required by the customer can be explicitly considered. A simple process based on a practical socio-technical understanding of the customer is proposed to help. These will help avoid a major Achilles heel to the software company’s value.

Implementation For a software company to be successful, customers must be able to install their solution within a reasonable time and without too much effort. Unfortunately, for many products over the past several years, this has not been the case. The larger enterprise systems such as CRM and ERP have received the most attention, but implementation issues have consumed customers for hundreds of software products.


6 Le Clair

A new implementation perspective can emerge from lessons learned during this period. One that monitors the “service-to-license” ratio, that reduces the number of departments for an installation, uses a best-practice approach to minimize “process-technology” gaps. And one that takes a process view of training. The good news is that the door will be opened even wider for third-party solutions provided by focused companies, as long as they are standards based. Companies like OpenPages are winning the battle for the red-hot compliance market created by Sarbanes Oxley legislation. The company is beating the major enterprise software platforms with focus, standards and short, painless installation.

Assimilation Today we approach customers with an attitude of disruption. Even though the idea of a disruptive technology was first introduced in the context of a market, we have carried it over to the customer. We are encouraged to instantly obsolete the current process and unequivocally vanquish the customer’s legacy system. This will work for latest storage technology and data communications hardware since these exist layers below human beings. But disruption does not work as well for today’s software solutions and complex customer environments. By contrast, assimilation is gradual change to something different and is a more appropriate concept for enterprise software. A model for assimilation is proposed, based on research on how new innovations spread, and practical examples from the industry. The model includes characteristics important for enterprise software to be accepted by a customer and the industry. Several firms are examined that were able to assimilate into the behavioral, technical, and strategic environments of their customers based on these characteristics.

Customer Core Competency Corporations that need technology must make a difficult decision. They can solve the problem themselves or purchase an outside product or service. Their core capabilities influence this decision and affect the value of the supplier’s product. When implementing enterprise software we need to look at how our core competency lines up with the customer. It is another example of understanding Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


the affect of our solution. Although here it affects the strategy of the customer. Of little concern for providing an e-commerce service to a consumer, this understanding becomes important when providing a technology-based solution to another business. The more sophisticated the customer the more important it is. This is because the customer is doing more than just buying an outside product or service. They may be limiting their own ability to develop expertise and capability in that area. They are handing intellectual property to the software company, who will own the software and all enhancements. And the software company will sell it to the rest of the industry including the customer’s worst competitor.

The Business Case When enterprise software is installed, it changes the economics of the customer. But we are not very good at understanding how. Often we leave money on the table, yet sometimes we do not make the sale because we do not prove the worth of our solution. Why is this and how can we improve? For starters, we need to understand the historical returns of technology. We need to look at our solution from the eyes of the customer that has lived through this history. Secondly, return on investment (ROI) for enterprise software is becoming a function of intangibles. Intangible returns that result from having more capable staff, a more robust infrastructure for product innovation, or returns from databases used for competitive and customer information. The purely financials measures we use today do not measure progress for these intangibles well and we need something different. The software supplier’s business case today lacks a firm grounding in the customer’s strategic goals that can then be aligned with performance-metrics, and ultimately cost savings. It is another example of our not understanding the effect of our technology on the customer. Emerging strategic frameworks like The Balanced Score Card can be used to make the software supplier’s business case more concrete (Kaplan & Norton, 1992). With these approaches, we augment the purely financial ROI view with a more strategic one and look beyond traditional financial metrics to understand the customer’s ROI. In short, a framework is provided to account for intangible returns, where much of the value of enterprise software will be in the future.


8 Le Clair

The Software Development Process There are a variety of development processes used throughout the industry. We first review the methods used in the industry for the difficult task of building software-based systems. These approaches provide managerial control and over time have introduced methods to deal with the risk of changing requirements, but they do not explicitly factor in the customer’s human, organizational and technical environment, that is, they do not include the socio-technical perspective required to implement successful systems. Furthermore, many software companies, particularly those in the early growth stages, are not using strong development practices to introduce new products until very late in their path to maturity. The result has been a large number of “one-off” solutions that do not scale with customer needs or the software companies business goals. The goal of the proposed framework is to more explicitly factor in important customer concerns, shorten the one-off stage, and provide a method that recognizes the flexibility required for discovering new products in new markets.

Not Your Typical Case Studies The case study companies are from the enterprise software and services market. We look mainly at emerging companies to identify patterns. Available research was also used to look in the rear-view mirror at mature companies and draw conclusions about why they succeeded. Much can be learned from Dell Computers, Microsoft and HP that made great decisions along the way. We also review implementations from the customer’s perspective, with examples from the credit card, brokerage and telecommunications industries. But we look mainly at emerging software companies to develop and refine the thoughts in this book. Mostly these companies have not yet reached their full vision. They are confronting the human resistance to the new, the difficulty of installing new technology amidst legacy systems and the battle with conflicting core competencies. All companies in the enterprise software market who try to succeed encounter these obstacles. The companies reviewed here are finding ways to overcome these obstacles and we can learn from them.



A Cause for Optimism The late 1990s was the peak for strategic technology investment where bits and bytes were pushed ahead of any objective metric of value to the customer. There is a prevailing view that many technologies have become commodities, investment in enterprise software has all but stopped, and that the next wave of high-tech positions will be in India. This book takes an optimistic view that we are entering an era where business will invest billions of dollars solving real problems and for the first time the infrastructure exists for this to happen. We merely shift the emphasis from raw technology, to business solutions that fit into the ecology of the organization. The fundamentals described here will hopefully help us prepare for the bright future ahead.

References Gerstner, L. (2002). Who says elephants can’t dance? New York: Harper Business. Kaplan, R., & Norton, D. (1992). The balanced scorecard – Measures that drive performance. Harvard Business Review, (January / February), 7179.


10 Le Clair

Chapter II

Behavioral Change

“One of the greatest pains to human nature is the pain of a new idea. It makes you think that after all, your favorite notions may be wrong, your firmest beliefs ill-founded... Naturally, therefore, common men hate a new idea, and are disposed more or less to ill-treat the original man who brings it.” -Walter Bagehot, Physics and Politics It is just not possible to deploy a new technology without affecting the behavior of the owners and users. Yet our product design, installation and sales approach do not fully address behavioral issues. This omission weakens the value and the business models of many emerging companies. The study of behavioral change related to information technology is far from new. Academic work has focused on individual and organizational issues of technology for some time. Yet this work has yet to affect the mainstream technology business. It has not made the case that it is good business to think and act in these terms. For the most part, the people making decisions on how to build enterprise products do not have sufficient perspective on the human side. Figure 2.1 is a simplified view of the vast amount of theoretical and practical work that has evolved (Mayon-White, 1993). This chart emphasizes the void


Behavioral Change 11

Figure 2.1. This shows an industry implementation gap between the “hard science” and “soft science” approaches. This gap has been closing over the years, but the software industry is still not where it needs to be. RAND (Military Systems)

Hard Systems

Waterfal

Spiral

SDLC

Systems Engineering

Object-Oriented Design Object-Oriented Development

RAD JAD

CUSTOMER-FOCUSED IMPLEMENTATIONS

INDUSTRY IMPLEMENTATION GAP Human Computer Interface (HCI)

Human Factors Social Psychology

Soft Systems

XEROX PARC Socio-Technical Systems Anthropology Theory of Reasoned Action

Management Theory

Cybernetics

1950s and earlier

Systems Theory

Diffusion of Innovation (DOI) Technology Adoption Model Business Process Re-engineering TQM

2000

Post Technology Period

that exists between two development philosophies needed to build successful enterprise systems. The hard science approach developed from standard engineering practice and focused on optimum ways to decompose complex problems. These were rooted in government-funded research that helped build complex systems. These efforts over time evolved into specific methods for software development such as Systems Development Life Cycle (SDLC). The hard science approach did not incorporate people and organizations into their methodologies. Soft science approaches had roots in social psychology, anthropology and early management theory. As shown in Figure 2.1, one branch led to tactical disciplines that focused on improving the interactions of humans with computers, such as the study of human factors and human computer interface (HCI) design. Another branch took a broader view and studied how innovations spread, and how systems could be designed from both a human and a technical perspective. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

12 Le Clair

These included socio-technical systems, which led ultimately to business process re-engineering (BPR). In addition, early work in cybernetics led to general systems theory (GST) and focused on the interdependence of system parts and the importance of feedback processes. These soft approaches lacked sufficient structure to build complex technical systems. In addition, the skill sets of soft sciences professionals could not have been more different than those in the hard sciences. The gap of Figure 2.1 resulted and today remains a large obstacle to implementing successful enterprise systems. Of the research work shown in Figure 2.1, the most practical perspective for enterprise software is socio-technical systems. As a result, the chapter on behavioral change is started by briefly describing this perspective.

A Socio-Technical Perspective is Needed for Enterprise Systems As shown in Figure 2.1, researchers have acknowledged for some time that organizational and social factors influence organizational outcomes. One of the most important studies took place in 1951. During that year two researchers, Trist and Bamforth published an analysis of the National Coal Boards attempt to introduce Longwall mining to UK coalmines (Trist & Bamforth, 1951). They concluded that the viability of an innovation could only be understood when social, psychological, environmental and technological systems are assessed as a whole. They searched for reasons why the new Longwall technology failed to deliver the hoped for productivity. Before introduction of the Longwall method, people worked in face-to-face groups to mine coal. Their tasks were multiple, and choice of who to work with was critical. Strong friendships and loyalties were made among the miners. In the words of Trist and Bamforth, “The small group, capable of responsible autonomy, and able to vary its work pace in correspondence with changing conditions, would appear to be the type of social structure ideally adapted to the underground situation.” The new mechanized Longwall method brought an entirely different social structure. With Longwall mining a block of coal, generally 700 feet wide and



often more than a mile long, was extracted using an auger-like machine. The new method led to more specialized tasks and spread activity over multiple shifts. The miner in this case was committed to his specialized task, entered into a small number of social relations, and had a diminished sense of loyalty or responsibility outside his particular task group. The major conclusion of the study was that failure resulted from the social shortcomings in the Longwall method, not the technology. The study pointed to the importance of group relations in using technology and was the first example of a combined human and technical view of an activity. It spoke for the first time of the importance of optimizing both technology and people. The basic concept of socio-technology theory is that technical and social factors are interdependent. The attempt here is to extend this concept of interdependence to develop a practical framework to combine “hard” structural factors with “soft” human factors, that is, make this interdependency a fundamental aspect of system design. With such a framework, solutions can be devised with an understanding of the critical interdependencies, and with the perspective that how technology is implemented is as important as the strength of the innovation.

How to Better Understand Behavioral Change for Your Product Understanding begins with a four-part process to explicitly consider the human effects of new enterprise software and is followed by case studies that highlight important aspects. With better understanding, focus and some simple tools, we can hopefully improve the customer experience and avoid problems faced by enterprise software companies. The process is as follows: A. B. C. D.

Understand the interdependence of system components Capture the users full behavior for each part Capture the attitudes of key stakeholder Determine the value-behavioral change tradeoff for each system component


14 Le Clair

A: Understand the Interdependence of System Components Customer systems are made up of many interdependent human and technical parts. These parts grow and adapt over time and become unique to the customer. System scientists who practice General Systems Theory (GST) have long recognized the importance of interdependence to understand complex, adaptive, and self-regulating systems. GST developed in contrast to approaches that reduced a system to elementary parts and varied one element at a time to understand behavior. Those approaches worked well for systems with weak interactions among components, but failed for highly complex systems. GST attempts to view a system in its totality and view the affects of different actions collectively. Many of the concepts from GST came from cybernetics, which studied communication and control of highly complex systems. Recent research has extended GST’s focus on interdependence to information systems and compares them to ecosystems. This comparison highlights the fragile, interdependent, and constantly changing nature of social groups interacting with technology. They stress that information systems evolve and interact in a dynamic manner. According to Information Ecology, “Adaptation is the rule of the game rather than optimal existence,” (Davenport & Prusak, 1997). These views of interconnectedness and adaptation are an important perspective for those in the enterprise software business. If one had to pick a reason for large system failures, it is the inability to see the customer environment in this interconnected way. There is no such thing as an isolated customer system and yet we approach them in exactly this way.

Understanding the Parts of the Customer’s System Customer systems comprise layers upon layers of tangled interfaces, data structures and human processes. The people that manage and work with these systems are connected to them on a professional and personal basis and form a fragile ecology. Application software, middleware and hardware systems are the simple parts of the system. Complexity stems more from the many home grown, human and informal processes that surround these. Much like layers of software, the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


human and technical components of a system are more layered than meet the eye. The nuances of introducing the new solution into the organizational ecology must be understood, the question is how best to do this? The simple behavioral change map in Figure 2.2 will help the software company see how their product affects the customer’s “ecology”. It takes a GST view and identifies the interdependent system areas that will experience human and organizational change as a result of the new system. Figure 2.2 is a simple chart, yet it is surprising how many software companies do not understand the departments affected by their solution. The most basic product will affect the operational, technology, management, maintenance and business unit layers. As shown, the tasks, skills, roles and careers will be altered in some way. In addition, the relations between each department will be effected.

B: Understand User’s Behavior Once the areas that will be changed are identified, we can determine current behavior of the users in each department. Behavior should be broadly defined as the complete set of activities. It is the full behavior path and includes tasks on the computer (online) and the human tasks off the computer (off-line). A broad lens can be used to capture a socio-technical and GST view of the environment. This allows us to develop a “behavior-centric” rather than a “product-centric” view. For example, many new enterprise software products offer better functions and use, but only for the online experience when using their product. They may simplify the tasks the user performs on their system but may not simplify their work overall because they ignore the broader human and organizational aspects of their environment. For example, ease of use and more features for the online part of the system alone often do not address the complete behavior path for the user and this results in missing key barriers to success such as the following (Dalbar Inc., 2002): • •

Small steps necessary to take advantage of the solution Unintended tasks attached to the solution that makes it unattractive


16 Le Clair

Figure 2.2. Behavior change map

Tasks

Secondary Business Unit

Operations Group Functioning

Primary Business Unit

Information Technology Roles Roles

• • •

Relations Between Departments

Careers

Management

Skills Skills

Features the customer must add to meet their needs with the new solution Organizational obstacles to the product’s success Other changes in behavior required with the new product that may slow adoption

The following sections describe several leading disciplines devoted to understanding current behavior and designing systems that work for humans. These are the perspectives that will help close the implementation gap of Figure 2.1. Each offers a complete framework to help understand the human effects of new technology. The software company can review these and select those parts most suited to their application. Each has made contributions to help create computer systems that are usable.

Human Computer Interaction (HCI) HCI is a large and growing field of study. It started in the late 1970s and 1980s with the goal of building systems that are more user than software development centered. The core ideas were developed at Xerox Palo Alto Research Center (PARC) and were used at Apple to enhance the initial graphical user interface. For example, early HCI research at Xerox (PARC) determined the best speed for the movement of the mouse by comparing the mouse’s movement with human processing speed. This was one of the first efforts to test technical and human cognitive abilities with the goal of creating a more user-responsive system. HCI draws on three important disciplines (Head, 1999):



•

•

•

Cognitive Science – a branch of psychology that studies how human behaviors of perception, attention, learning and memory affect information processing. Social Psychology – the scientific study of how humans behave as groups in social and work settings? HCI uses social psychology to understand how group issues such as organizational structures, power and authority affect human-computer interaction. Human factors – match the physical characteristics of systems with the users capabilities. Traditionally, human factors have been concerned with design practicalities of safety and efficiency, but now contribute to computer usability.

HCI continues to evolve and is now drawing from other disciplines such as linguistics, sociology, and graphic design (Special Interest Group on Computer-Human Interaction, 2004, About SIGCHI). Today in the enterprise software market an HCI view is essential due to its complete focus on the everyday user and how to make technology workable. It recognizes that software products are dependent not only on what they can do for the user, but how functionality is delivered. From the commercial perspective, strong navigation and usability will sell the product. Given the amount of money at stake and the clear need for usable products, why is there not an HCI resource on every development team?

Ethnography As an industry, we do not spend enough time in the user’s environment understanding what they do. We are very quick to make very important assumptions that are not backed up with facts. Fortunately, sociologists and social anthropologists have developed methods that can help us capture important behavior when formulating system requirements. Their process is called ethnography, whereby considerable time is spent in the working environment. The daily work is observed and detailed notes made of the actual tasks the user performs. The value of a detailed understanding of user behavior was demonstrated in 1983 in a study of office automation. The study found actual work practices were far more complex than that assumed by the suppliers of office automation systems. The


18 Le Clair

difference between the assumed and actual work was the reason these systems initially had no significant effect on productivity (Kaarwoski & Salverdy, 1994). One value of ethnography is that it does not depend on people to explain what they do. Their work is often so automatic that they find it difficult to explain it to others. Often their view is too narrow and does not fully understand how their work relates to others. Seeing what they do is better than hearing about it. Ethnography will help us understand the full behavior path of the user. While a full ethnographic study may take months, for system design significant insight can be gained in a matter of weeks. An analyst from the software company can live on the customer’s site for a week and get to know the target user’s current behavior and obtain this broader view of their environment. It is money well spent.

Human Factors Approaches Human factors analysis arose out of the study of accidents in the aviation industry. The majority of accidents, it turns out, do not result from technological faults or a lack of technical skill. Studies found that the factors leading to the disaster lay within the area termed “human factors”, that is, the interaction of the human being with the technology. Human factors approaches can be applied to enterprise software. For example, a systems integration firm designed a workflow system for a state government agency using human factors and the approach worked well (Ormsby, 2004). Two users were placed in a room with a prototype of the new application. Two people provided more insight and were preferred because they spoke to each other when confused. Each was asked to work as normal while from the adjoining room the session was video taped. Later, the system design firm sat in a conference room and analyzed the human interaction with the system. It would tell you things you could never get from interview, such as the best way to enter a social security number. When entering the number, was it better to have the spaces come in automatically? Or was it better to have the user put the spaces in because this is the way they handled it for other tasks. According to the firm, it was difficult to set this test up. The people they wanted for the human factors test were $9 an hour administrators. The client was in North Carolina and they did not understand why the integration firm wanted



them to spend the $500 plane ticket to ship two of their workers up for study. One of the individuals had never flown before and was not anxious to start. The managers were upset because they wanted to come on the trip and be interviewed. Well, the firm wanted the workers not the managers.

Learning from Best Practice The fields of study described above can help the designers and marketers of new software products devise creative and appropriate techniques to get to the human and organization problems that new products encounter. We can also learn by looking closely at why some applications just seem to work. The Web is only one click away and can show us thousands of applications. Here are two simple examples.

Virtual Dressing Rooms As described, off-line behavior is the non-computer part of the relevant task and is important for product design. It is taking a “process view” as opposed to a “product view”. Without a firm grasp of off-line behavior, it is hard to design products to minimize behavioral change. With the process view, often the best product design is one that incorporates much of the old behavior in the new system. This makes the user comfortable and increases adoption. We can learn a lesson from online retailers. They have been creative incorporating the full shopping process in the online experience, that is, mimicking the shopper’s behavior. For example, they studied how people act in clothing store and found that customers almost always tried items on. So they tried to offer this experience online by providing a virtual dressing room. With a few questions and clicks the model begins to look like you. It is created based on your height, weight, and size. You can see what the article of clothing looks like and change colors with a simple click. Best of all, there is no waiting to get in the dressing room and no demeaning security checks. To know existing behavior is to know your customer. Your products can then be designed to meet their needs and help adoption.


20 Le Clair

Mimic “Off-Line” Behavior As in the shopping example above, product design can reduce behavioral change by understanding the complete process both online and off-line. A good example of understanding the complete behavior path can be found on the Amazon.com retail e-commerce site. Amazon was the first to provide excerpts from books online. They understood how consumers behaved when buying a book. The browser in the store will pick up the book and open the cover and glance through the table of contents. They will stand in front of the bookshelf and read a few sections of a chapter. Amazon provided this experience online. A user could click on the cover and were provided links to sections. And they did not stop there. Amazon provided book reviews to improve the experience. They captured past online behavior and understood what the consumer purchased before. With this information they could make recommendations. You may have purchased The Perfect Storm before so you may like Into Thin Air. This is a good example of behavior-centric design” and mimicking the off-line behavior.

C: Capture the Attitudes and Beliefs of Key Stakeholders According to Michael Hammer, father of Business Process Re-engineering (BPR), 50% to 70% of the efforts to replace corporate hierarchies with “process teams” have been unsuccessful. The main reason, according to Hammer, is the failure to address the human side of the equation. Likewise, most failed technology projects and hence failed vendor solutions can be traced to poor navigation of the key elements of behavioral change. The design principles of the BPR movement are similar to those found in sociotechnical systems. However, BPR was focused on speeding up a work process through organizational change, whereas socio-technical systems are based on the belief that systems can be improved if the interdependence of people and technology is explicitly recognized and planned for. BPR’s goal was more bottom line, hard-edged and had the goal of a faster work process and taking costs out of the system. At one point, Michael Hammer referred to BPR1 as Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


basically taking an axe and a machine gun to your existing organization (Strassmann, 1994). Often BPR met initial business goals but produced new and difficult human and organizational problems, which mitigated the speed and cost savings over time. The continuing relevance of socio-technical theory is in some sense demonstrated by the failings of BPR. Socio-technical theory incorporates strong values and regards people as more than simply instrumental. Whatever BPR’s fate, a major contribution is the need to design technology and organizations together.

Understanding User Attitudes Success for enterprise software reduces to how well the technology is accepted as an integral part of the customer’s work process. Research has shown that beliefs and attitudes influence this acceptance. Thus, understanding the potential attitude of users should be important for the software company. But it does not seem to be important. It is surprising how little attention is given to understanding the potential attitude of prospective users given that they may make or break a product. In some cases users will completely reject a new system or only partially use its functionality. In other cases they will actively resist or even sabotage a new system. Lets try to understand the characteristics that may lead to negative and positive behavior.

Technology Acceptance Models The problem of individual acceptance of a new technology is complicated but worth the effort. There has been considerable research into what causes individuals to exhibit different behaviors. Over the last two decades, this work has been tailored to predict and explain the acceptance of new technology. Academic work has drawn mostly from social psychology such as the theory of reasoned action (TRA) (Fishbein & Ajzen, 1975). TRA is a well-known model that has proven successful in predicting and explaining behavior in a number of domains. Here we highlight the technology acceptance model (TAM), which was derived from TRA (Davis, 1989). TAM can be used to help the enterprise software company identify what attitudes are important for acceptance of their solution. This can help a supplier qualify an opportunity by identifying either positive or


22 Le Clair

negative attitudes that may affect the initial purchase or subsequent use of their product. Further, understanding the attitude of potential users can help the software companie’s marketing department develop a fully integrated communication plan to help adoption. A strong theme of TAM is that beliefs and attitudes are a prime determinant of behavior, that is, that behavior is influenced by an individual’s intention to perform a behavior. Intention, in turn, is determined by the individual’s attitude. So basically, a person’s attitude predicts their behavior. In fact attitude may be the most important variable for acceptance of a new innovation. A 1992 study of e-mail, voice mail and other software packages found that attitude was a stronger predictor of system usage than even how easy the system was to use (Succi, 2003). Take for example, a new user of the Internet. They may believe that a high-speed network connection is critical to them being productive on the Internet. If they only had a dial-up connection, this belief could make them less inclined to use the Internet and may dampen their motive and curiosity to learn about it. And even though network performance may not be an issue, they may see problems that do not exist and link them to the lack of a high-speed connection. And this is the point. As a software supplier, if you understood a linkage like this you could deal with it proactively.

Predicting Acceptance of Your Solution Since a person’s acceptance of a new technology is preceded by them forming a “behavioral intention” to engage in that activity, how do we determine what that behavior intention is? According to TAM this can be determined by understanding the users attitude. A simple framework distilled from current research and industry practice can help do this. To begin, let’s review five aspects of a system that help form the user’s attitude.

Perceived Usefulness Perceived usefulness is defined by TAM as “the degree to which a person believes that using a particular system would enhance his or her job performance” (Davis, 1989). Usefulness is also influenced by the stability of the current system. It is typical for enterprise systems due to their high number of concurrent users, and system interfaces to encounter performance or stability



issues. In this case, it is not preceived as particularly useful. The more unstable, the more their attitude will support change. Stability and responsiveness, on the other hand, means it is being used to meet the current business objective. A working and stable system also means security for users and will bring a negative attitude towards the new technology.

Perceived Ease of Use Perceived ease of use is an important predictor of attitude. This has been defined as, “the degree to which a person believes that using a particular system would be free from effort” (Davis, 1989). The first impression of a new product can be a strong influencer of attitude. These initial attitudes are difficult to overcome even with subsequent improvement in ease of use. Perceived usefulness and ease of use can be tested through interviews and prototyping prior to initial deployment.

Management Support The third important predictor of attitude is management support and direct incentives. Explicit incentives and bonuses tied to roll out can help adoption. This has been shown to work for consumers hesitant to learn customer selfservice applications where lower prices or other incentives have been correlated with higher adoption. In one study of direct payment behavior, 23% of non-users claimed that they would switch to an electronic form of bill payment if offered a 5% discount on the bill (Hayashi, 2003). One potential strategy for the software supplier is to offer a pool of bonus money to the new users, perhaps to the most enthusiastic and aggressive adopter. If the customer will let you do this, it is money well spent.

Enhancement of Professional Status Potential acceptance is also influenced by a users perception of how the new system will affect their professional status or help their career. Research suggests that management that ties new system adoption to professional


24 Le Clair

enhancement will see stronger results. One study looked at teacher’s adoption of the Internet and the World Wide Web. It described a learning and adoption process that accelerated when teachers determined that the use of telecommunications contributed to their self-efficacy as teachers (Shery, 2000). In this study, adoption increased when use of the Web became compatible with their personal vision of learning. This made their time and effort well spent mastering a new set of skills.

Risk Profile and Fear of Change The users attitude towards risk will also affect their attitude. The internal users and managers of any system in use, despite stated desires to the contrary, have a great fear of change. There is security with the known environment. It may be a very bad system but the user is practiced at overcoming its weakness. They also have personal and professional investment in the system. Fear of a new system will inhibit learning about potential benefits. When it comes to risk, the attitude of the software company is in conflict with the attitude of the customer. The software company is more prone to risk. They have accepted risk as part of their job, that is, pushing new technology into new markets is inherently a risky pursuit. Unlike the initial team from the software company, the customer must live with the system for a long time. Their job and career will be affected and they tend to be more risk averse. In sitting through countless customer meetings this attitude clash is apparent. The software company swaggers like a cowboy as they speak to the cowering customer. The self-assured software representative paints a serene picture, where heaven itself will descend upon the visionary management who bravely installs their system. In many cases, the software representative knows little about the companies business or operation. In other cases the software has not yet been installed for the application in question. The customer’s body language and quiet manner are clear. Attitudes of uncertainty and doubt may be formed which will influence behavior and may thwart the change effort. In selling enterprise software it is better to be knowledgeable and up front about the implementation, economic, behavioral, and organization risk that is inevitable. The tendency, due to lack of knowledge or fear of losing the sale, is to downplay the risks. I have heard very seasoned sales executives argue that it is better not to train your sales people on these potential risks. They argue that the sales person in the field is more effective if they do not know them. With today’s sophisticated Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


buyers of technology, this is not a viable strategy. An upfront and knowledgeable treatment of risks can differentiate a supplier by emphasizing their domain and process knowledge. It can build credibility and is also the right thing to do.

An Attitude Checklist Figure 2.3 is a checklist to assess the attitudes of key stakeholders. A good exercise is to review each department involved in the implementation from the behavioral map. Circle the box in Figure 2.3 that best represents collective and individual attitudes from each affected department. From this, reach consensus on whether they are resistant, open or spirited. With this understanding, adjust your marketing and implementation strategy to address specific attitude issues. One outcome may be that this particular customer type is not appropriate for where your product is today.

D: Determine the Value/Behavioral Change Tradeoff We now have identified the departments affected by our solution through the behavioral change map. We also have used best practice from HCI, human Figure 2.3. Attitude profiles Resistant Minimal perceived enhancement of professional status

Open

Concerns over ease of use

Moderate perceived enhancement of professional status Moderate perceived enhancement of professional development Strong management support but no explicit incentive tied to change Moderate perceived usefulness of system Unsure over ease of use

Fear of change; Risk averse

Open to some risk

Minimal perceived enhancement of professional development Weak management support; No explicit incentive for change Low perceived usefulness of system

Spirited Perceived as enhancing professional status; Can raise profile in the organization Perceived as enhancing professional development Technically astute senior management with explicit incentive tied to change High perceived usefulness of system No concerns over ease of use; Sees new approach and tools as strong win for business process Strong internal champion; Wants to go for it


26 Le Clair

factors or ethnography to capture the current behavior. We also have a good idea of the users potential attitudes towards our product. We can now summarize the change in behavior required during implementation. We can combine this information to assess the value/behavioral change profile for each affected part of the organization. They can help us determine whether we are optimizing our software rather than all the components on the system. Below is a list of questions, grouped by behavioral change categories of Figure 2.2, that can now be answered. Each of these questions can influence decisions in user interface design, product features and scope, implementation strategy, training and the marketing communication plan. They can also help to determine the best market, or customer within a market to go after.

Skills • •

•

What new or different skills are required for each affected department compared to the current operation? Are the new required skills a good fit for the organization? If not, does the product try to close the gap? Does the product have online guides to help do this? Learning occurs primarily through experience. Does our training approach integrate learning on the job through advisors and facilitators?

Group Functioning • • • •

What are the changes in reporting and communication? Does the product address new as well as old reporting relationships? Does the new product understand the former tasks within and among groups and create a smooth transition? Have we incorporated enough old behavior in the new system to maintain harmonious group interaction?



Roles • • •

Will the new system change their job and how? What new roles and hires will result? An outsourced solution will affect IT jobs. What jobs are affected and can the new supplier offer a career path for any potentially dismissed staff?

Careers and Status • • • •

Within each affected department, how is the professional stature of users affected? Are we elevating the professional development potential of one group more than another and face pockets of resistance and sabotage? How does the new solution affect professional development for the various stakeholders? Does the product minimize organizational change by not shifting the professional status of key roles?

Tasks • • •

What changes in tasks will occur? Are there new tasks within IT for security administration, back up and recovery, and application support? How will business unit responsibilities and organizational tasks change? Have we tried to reduce wide variations between new and old tasks through cross training and ease of use?

Attitude • •

Do we need to garner more management support with explicit incentives to ensure adoption of our solution? Are concerns over ease of use very high due to a mismatch of skill sets in the primary user group?


28 Le Clair

•

•

Is there enough benefit for each department to induce the projected behavioral change? For a self-service application, what is in it for the user? Is the level of convenience high enough to keep the user from accessing the nearest potential human being, the phone or someone else’s Web site? Is the products perceived useful high enough for the customer to manage the behavioral change necessary to adopt the solution?

With this understanding we can see whether the demands of behavioral change exceed the customer’s capacity to absorb it. We can better prepare our customers for the amount of behavioral change in their operations and design the product to minimize these effects. We can also build implementation and training strategies that address the human response to change and design a marketing communications plan to address potentially damaging attitudes.

Case Studies It is easy for us in the business to assume a higher level of technical understanding among businesses and consumers than exists. This is true at the conceptual and the hands-on level as evidenced by this “official statement” from the weather office in the UK. Here, facsimile machines are now recommended to give local authorities’ early warning of severe weather. The emergency planning office said, “Rather than having to rely on telephones, for instance, where lines are at risk in bad weather, we are encouraging the wider use of fax machines” (Reading Evening Post, 2002). In this example, a sophisticated government service did not understand that fax machines use regular phone lines. Human and organizational issues have affected many installations. Four case studies are highlighted here not because they are dramatic examples, but because the problems encountered could have been avoided with a different perspective. The first is a major mutual funds company, where not understanding the users full behavior path led to system problems. The second case study is ObjectStore, which shows how a simple plotting of the customer’s organization may have helped the company understand challenges they faced in the market. The third case study is from the electronic bill payment market, which suffered from poor



technology adoption. The fourth is how the attitudes of potential users were able to derail a promising software application.

Behavioral Change in a New Account Processing Application A great deal of enterprise software has the goal of speeding up business processes. According to Bill Gates in this summary of Business @ the Speed of Thought increasing the speed of work processes will be a fact of life for business in the future: “The 21st century will be about velocity: the speed of business and the speed of change. To stay up with and anticipate change, businesses need radically better information flow. To get a better flow of information to develop the right processes and strategies, they need a digital nervous system.” (Summary paragraph from Bill Gates Web site, ‘Looking @ the book’, www.microsoft.com/billgates/ speedofthought. Retrieved July 8, 2004) The economics of business process automation are also compelling. Business spends $35 billion on administrative logistics each year (Trunick, 2000). The Council of Logistics Management defines logistics as “the process of planning, implementing, and controlling the efficient, effective flow and storage of goods and services, and related information from point of origin to point of consumption”. Business process automation can achieve mammoth savings but behavioral change for users is a critical issue as we see in the following. Behavioral change was underestimated in the following workflow solution to process new accounts.1 In the late 1990s, a major mutual fund company was experiencing great success and high growth. Each month witnessed the addition of new support staff to process required paperwork for expanding sales of their mutual fund products. It took the company weeks to open a new account – to allow one of their mutual funds to be sold. The delays were both annoying and expensive, but that was not the worst of it. The growth in new accounts was increasing each quarter and these times would surely rise. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

30 Le Clair

It turned out that the actual time necessary to open an account was a matter of minutes. So how could the process conceivably take so long? Simple. New account paperwork had to visit many different departments on its route. Files were built manually. They were handled serially to avoid copying, and were often misplaced. In addition, departments were highly specialized and had many human and manual interfaces. If workload were high in one department the file would sit in a pile and wait, even though another department may be idle. Dramatic gain in performance required a workflow system that would dismantle the department stovepipes and create a clear, clean line from the beginning to the end of every process, eliminate paper, and when combined with cross training, allow workload balancing. It was decided that a new account processing workflow system would allow their business to scale. In this workflow, high-speed scanners at the point of arrival digitized all paper applications. Once the image of the paper was electronically archived in the system the paper was destroyed. The system would deliver a digital image of the paper application directly to the processors desktop, where data entry and account set up would occur.

Disorientation Modern organizations are use to change. It is a fact of modern corporate life. Organizations, technologies, and procedures change constantly. But how much more effective will suppliers be if they understand the process the customer is going through when putting in their product. Eliminating paper at the mutual fund company created an unanticipated behavioral change problem. To begin with attitudes towards the new system ranged from disinterested to extremely skeptical. Key members of the staff thought a paperless office had about as much chance to succeed as a paperless bathroom. As an example, the new account processing staff was accustomed to going into the mailroom first thing in the morning to see the volume of work that had showed up that day. Each morning they could judge their workflow based on the stack of envelopes in the mailroom and plan accordingly. Planning is this case was as much personal as business. It was whether they could go out for lunch or pick the kids up on time. The new system took this



insight away, and replaced it with reports that showed the number of accounts processed per worker per hour. Disorientation occurred because the staff at their workstations had no idea whether there were 20 folders to process in the queue or one. This simple change introduced a tension for the employees, and led to poorer productivity. It is a small example that points to a human part of a system. If the software company had studied off-line behavior, they would have noticed the role of the mailroom and stacks of paper in their planning process. It could have been replaced with a counter of the number of files waiting to be processed in the “Work Queue”. This allows the user to know what their workload is. And allows them to plan their day. Important behavior for product design is often hidden in “off-line” behavior.

ObjectStore and Behavioral Change If you ever wondered how dramatically behavioral change can affect a great technology solution, look no further then Object Design. Object Design’s product, ObjectStore, was the first successful object-oriented database. In the mid ’90s an object-oriented database was a technical breakthrough. The company approached it as a “mission from God”. A highly disruptive attitude prevailed at the company made up mostly of engineers. And it would be required to slow the building momentum towards the more popular relational database products offered by Oracle, Informix and Sybase. It was a brilliant technical breakthrough. The object-oriented database allowed direct manipulation of the underlying data “objects”. This was in contrast to the relational database approach that required hierarchies of tables and indices. This innovation promised a host of advantages related to performance and data sharing and influenced the development of later “object-oriented” applications. Unfortunately, the business vision of replacing relational databases failed. By 1999, ObjectStore abandoned the mainstream database market, choosing to focus on specialized data management problems that required complex data and high performance, instead of broad, general use. They found that customers, despite performance and technical superiority, were not willing to absorb the behavioral change required when leaving more standard database platforms, such as Oracle, for the object-oriented database world.


32 Le Clair

The Teeth of the Hurricane By this point, large corporations had invested significantly in training and infrastructure to support relational databases. They had the staffs of database administrators, assemblers, systems programmers, as well as systems administrations for back up and disaster recovery. The behavioral change map for ObjectStore is shown in Figure 2.4. Three of the five primary groups supporting the relational database system were dramatically effected by movement to the object-oriented database. I spent the better part of a morning with Ken Rugg, one of the key development managers of the original ObjectStore technology now working at Progress Software. He stressed the emotional nature of the original ObjectStore sale. According to Ken, database selection is strategic at larger companies. For the managers selecting Oracle, it was personal and emotional. To accept a radically different database approach proved difficult. “The original approach of ObjectStore was flying into the teeth of a hurricane,” according to Ken. Besides the emotional issue, there were radical changes in behavior required for maintaining the new database. For starters, when a customer selected ObjectStore there was no longer a substantive role for database administrators. Most of the standard DBA work was built into the application. Even though the reduced dependency on database administrators was a business benefit, those making technology decisions viewed this as a threat, creating a political barrier to market acceptance. Even worse, data assemblers, who were proficient in software tasks requiring lower-level skills such as writing “scripts” or routines in Visual Basic, were now told to program in C++ or other “object-oriented” languages. This represented a huge leap and required advanced design concepts like “multi threading”. Multi threading is the ability to execute different parts of a program “threads” simultaneously. It was a level of software design the data assemblers could not handle. In terms of Figure 2.2, this shifted knowledge and power to the systems programmers, who were already over burdened, and devastated the data assembly group (Rugg, Progress Software, 2003).

A Study in Strategy Changes and Flexibility Caught up in the euphoria of the Internet boom, Object Design took on a new name and darted to a B-C e-commerce platform strategy. Here, an online Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


Figure 2.4. Behavioral map for ObjectStore customers Gained Influence and advanced Skills Already Overburdened

System Programmers

Documentation /QA

Lost Professional Stature Perhaps Loss of Jobs DB Administration

System Administrators

DB Assemblers

Lacked object-oriented software skills

retailer would maintain their catalogue as an XML database. XML would allow detailed access to product information and provide a host of maintenance advantages. If eBay had an XML searchable database you could search just for convertible cars. As momentum in online retail vanished, eXcelon then moved to an XML-based business process management solution for the B-B market. Consider this positioning statement from the 10K for the fiscal year ending December 31, 1999: “eXcelon Corporation (formerly Object Design, Inc.) is a leading provider of software products and services used for building and deploying business-to-business (‘B2B’) software applications that enable companies to engage in dynamic B2B commerce across the Internet (‘e-business’).” (eXcelon Annual Report, 1999, p. 2) Consider the significant number of strategy changes for this company. They went from a generalized database focus to a specialized database focus, then to at least two very distinct XML strategies. During a five-year stretch, the company changed its strategy on average every nine months.

Refocusing on the Original Need: Complex Data and Performance At their peak ObjectStore had respectable database revenue of more than $65 million a year, and this core customer base continues to use ObjectStore today


34 Le Clair

in areas that relational technology simply ca not match the performance and flexibility required. In 2003, Progress Software Corporation (PSC) acquired ObjectStore, recognizing the long-term value of the ObjectStore product, and refocused the company on the original market need: applications that required complex data modeling and high performance. Applications like telephone switching network management, geographical information systems and many financial applications, like portfolio management and trading systems, found value in the advanced performance architecture. The cycle of innovation, followed by a series of haphazard strategy changes that ignored the original value and advantage of a unique technology is sadly common in the high-flying world of enterprise software. Luckily for ObjectStore, a dedicated stable of customers and a pragmatic return to the roots of business need combined to make a happy ending, but not all cycles of innovation end so happily.

Behavioral Change (Electronic Bill Presentment) Charles Darwin spent ten painstaking years developing volumes of data on the adaptation characteristics of barnacles before he published The Origin of Species. Even though he intuitively developed the theory of evolution much earlier, he completed detailed analyses to make sure his theory was supported by a strong set of empirical data. Enterprise software companies in the E-BPP Market could have learned from his example. Behavioral change was misunderstood in the electronic bill presentment and payment market (E-BPP). The market held great promise. At the time there were approximately 150,000 issuers of bills and statements worldwide with companies issuing more than 60 billion recurring bills, statements and other commerce-related documents on an annual basis. Killen, an industry analyst, estimated that the percentage of recurring bills presented on the Internet would grow from 5% in 1999 to more than 70% by 2005. In addition, Killen estimated that worldwide expenditures on Internet billing software and services will grow from approximately $9 billion in 2000 to $15 billion by 2005. These facts told a compelling story. There were lots of bills and growing Internet connections.



Scores of technology companies bet their future and millions of the public’s investment dollars on their vision, with much of this vision depending on behavioral change. Yet these companies did not take the time to study the behavior of the consumer. They could have studied the off-line behavior to assess how much change was involved in using the Internet to pay bills. For example, software companies could have studied who actually pays the bill in the household today and are they the most likely to use the computer. How do they look at a bill and what do they look at first? If they are focused on the summary information, why not provide this first with a link to the detail to improve the experience. Consumers may want to compare last year’s energy usage with this year. Analysis of off-line behavior could have improved the experience and they would have uncovered barriers before vast sums of money were invested. The bill presentment and payment market have not yet achieved it’s projected potential? A host of companies targeting Business-to-Consumer (B-to-C) applications never reached profitability and ultimately changed their business model to Business-to-Business (B-to-B) to survive. In retrospect, the E-BPP companies focused too much on the business case component of the value proposition and too little on behavioral change. The economic advantage of an Internet billing transaction to the biller was not in question. E-mail with a bill presented over the Internet could be as low as two cents, compared to receiving a check in the mail of $2 (Edocs, 2003). The cost savings were obvious. They also underestimated the adoption of direct payment alternatives through credit card or automatic check payment. Direct approaches had similar cost savings to the biller and required very little behavioral change on the part of the customer. Direct payment approaches today are the most successful form on electronic banking dwarfing Internet and telephone banking transactions at a rate of more than five to one (Edocs, 2003).

A Case of Attitude One example of how user attitudes affected a software product involved a new document publishing application. This product allowed corporations that prepare annual reports and other regulatory documents to “author” and make


36 Le Clair

edits to the material over the Web. A software-based workflow tool allowed the coordinator of the process to see the progress of the document as it went from creation, to edit, and then to approval and filing with the Government. With the current compliance climate emphasizing “currency” and reliability of financial information, the product seemed to have a bright future. This product was a threat to the “financial printing” industry, since it replaced their “typesetting services”. These services were often based on inflexible typesetting systems that were in effect, proprietary word processing systems. Often resident on IBM mainframes, they incorporated graphic and table management features required for complex and highly formatted documents, particularly those with large amounts of tabular data. They have existed for decades. These systems used the exchange of paper via overnight delivery and facsimile as a primary means of coordinating changes. Changes directly into the publishing system could only be made by the printer and not by the customer. The inevitable changes at the last minute created typesetting charges that could run into the hundreds of thousands of dollars. The new “Web-based typesetting service” allowed the users to make changes over the Web, and provided more control over the entire process. In this way, traditional typesetting services were eliminated. The new system was installed at a major corporation with the promise of delivering these improvements. Due to the cost savings in the system, the sale was made to the very senior executives of the company. The users of the current document creation system were not involved in the selection of the new system and quickly developed an attitude of “resistance”. The system, as initially built, had no human factors or HCI participation, and usability was poor. In addition, the perceived usefulness of the application was low since the full behavior path for the user was not considered. The software product had missed several key tasks handled manually by the users interacting with the printer. The software had no replacement functions for these. In addition, the poor usability and low level of usefulness were very visible in the company. The organization aspects (changes in roles and tasks) were also not considered. The software company installing the system undertook no organizational review of the users current system. If they had they would have learned that these users had limited computer skills, a very comfortable relationship with the financial printers and sustained a certain organizational status from these relationships. The new system lessened their control over the process while giving more visibility to others. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


Things went downhill quickly for the software supplier. The users looked for errors and ways to blame the system at every turn, including purposely going through a large number of major document formatting changes just to put pressure of the new system. In one incident, one of the users came out of their office waving a report with several errors created by the new system for all to see. Within six months, use of the promising application was discontinued. The firm reverted to the legacy typesetting approach.

Summary In speaking with enterprise software companies and their customers, it is clear that there is poor understanding of the users behavior and how this behavior will be affected by new technology. There is significant amount of research that has attempted to address this industry problem. This chapter has attempted to distill some of this work into some simple guidelines that can help up build customerfocused systems and hence have success in enterprise software.

References Argawal, R., & Prasad, J. (1998). The antecedents and consequence of user perceptions in information technology adoption. Decision Support Systems, 22(1), 15-29. Bertalanffy, L. (1976). General systems theory. New York: George Braziller. Business @ the Speed of Thought: Using a Digital Nervous System (1999). New York: Warner Books. Computer World: A Dangerous Game (1994, March). New story by Paul A. Strassmann. Dalbar, Inc. (2002). Behavior-centric e-systems. White paper. Retrieved Feb 25, 2004: www.dablarinc.com Davenport, T., & Prusak, L. (1997). Information ecology. London: Oxford University Press. Davis, F. D. (1989). Perceived usefulness, perceived ease of use and user acceptance of information. MIS Quarterly, 13(3), 319-340. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

38 Le Clair

Edocs. (2003). E-billing and customer self-service presentation. Received July 15, 2004. eXcelon Corporation (1999). eXcelon Annual Report for the Fiscal Year ended December 31, 1999. SEC Commision File Number 0-21041, page 2. Fishbein, M., & Ajzen, I. (1975). Belief, attitude, behavior: An introduction to theory and research. Reading, MA: Addison-Wesley. Hayashi, F. (2003, June). Payments System Research, Federal Reserve Bank of Kansas City. Technology adoption and consumer payments: Evidence from survey data. Review of Network Economics, 2(2). Head, A. J. (1999). Design wise: A guide for evaluating the interface design of information resources. Medford, NJ: Cyberage Books. Kaarwoski, W., & Salverdy, G. (1994). Organization and management and advanced manufacturing. New York: John Wiley. Mayon-White (1993). Problem solving in small groups. In Managing change. London: Paul Chapman. News of the Official Bulletin was reported by www.getreading.com.uk courtesy of the Reading Evening Post in 2002. Norman, D. (1988). The psychology of everyday things. New York: Basic Books. Ormsby, C. (2003, August 26). [Interview on human factors with Dr. Charles Ormsby, formerly of The Analytic Sciences Corporation]. Rugg, K. (2003, July 12). Interview Worldwide and at Progress Software Corporation, North American Headquarters, Bedford, MA. Shery, L. (1999). Using the Internet to enhance standards-based instruction. RMC Research Corp., January 19. Special Interest Group on Computer-Human Interaction (SIGCHI). (2004). About SIGCHI. Retrieved March 25, 2004: http://www.acm.org/sisgchi Succi, M. (2003). Theory of user acceptance of information technologies: An examination of health care professionals.Proceedings of the 32nd Hawaii International Conference on System Sciences. Los Alamitos: IEEE Computer Society Press. Trist, E. L., & Bamforth, K. W. (1951). Some social and psychological consequences of the Longwall method of coal-getting. Human Relations, 4(1), 6-24, 37-38.



Trunick, P. (2000). Fourteenth annual state of logistics report. (See note.) Wiener, N. (1948). Cybernetics. New York: Wiley.

Endnotes 1

The Mutual Fund Case Study was based on personal experience from working on the project. Several members of the implementation team were interviewed to validate the conclusions.


40 Le Clair

Chapter III

Assimilation

“ I don’t go where the puck is, I go where the puck is going to be.” Wayne Gretsky As discussed in Chapter I, successful enterprise software will assimilate rather than disrupt in their market niches. Assimilation is gradual change to something different. The noun “assimilate” means conversion, reduction, transmutation, evolution, sea change, transit, transition; transmigration, and shifting. As a verb it means to be converted into, evolve into, slide into, glide into, ripen into, merge into, emerge as, assume the shape of, begin a new phase, assume a new phase, and undergo a change. The hope for any software product is to assimilate in the customer environment quickly. Venture capitalists and senior executives in emerging companies sometimes refer to this as “viral scaling”. You want the product to spread like a virus and assimilate into the behavioral, technical, and strategic environments of the customer. Strong products will accomplish this in a gradual and painless way. This chapter defines items required for this to occur including: A. B. C. D.

Creating a bridge to the current system Providing technology leverage Moving into a high value gap area Replacing the complete business process


Assimilation

41

We combine these with characteristics from diffusion of innovation theory to propose a complete framework to evaluate and help guide a software product towards acceptance in their target environment. We then look at two case studies that are using this approach for success. To conclude, we discuss strategies to help us protect our intellectual property.

Enterprise Software’s Dilemma The Innovator’s Dilemma was published in 1997. It distinguished between “sustaining” and “disruptive” solutions (Christensen, 1997). Sustaining technologies improve performance within the customer’s current technology and organizational framework. They improve what is already in use. Disruptive technologies emerge less frequently and produce products that are cheaper, simpler, smaller, faster, and more convenient to use. The disruptive product renders the current solution obsolete immediately. Christensen’s distinctions were based on his research in the computer storage market of the early 1990s, which experienced rapid product innovation. Since that time disruption has been more associated with hardware than software and mostly has referred to new low-end hardware that enters a market and steals market share away from the established product. In the case of hardware, obsolescence can be immediate, as in the case of CISCO systems. The initial Cisco router connected Ethernet LANs (local area networks) over wide area networks using the Internet Protocols (IP). It bypassed installed circuit switching and packet switching network architectures. The Cisco router disrupted current networking architectures. For enterprise software, the process is slower and less dramatic, and is more a process of assimilation than disruption as in the following examples: •

In 1972, five former IBM employees founded SAP. The German ERP Company was the first to provide real-time business processing which started to replace the early batch-processing systems. SAP’s products helped companies integrate diverse corporate applications. Integrated applications are now a cornerstone of corporate IT systems.

•

Oracle was the first database to be independent of the hardware it ran on. It allowed corporate data to reside on any hardware platform. Users


42 Le Clair

could access and combine data from any system that ran Oracle. This breakthrough allowed isolated corporate data sets to be integrated. The software products above succeeded due to their ability to assimilate rather than disrupt their environments. Oracle prided itself on promiscuity. It was the best at running on the wide and diverse set of hardware used at the time. SAP did not immediately replace the existing batch business processes, but provided a platform and a vision to do so. The vision embraced real-time processing and the goal of integrating administrative applications at its core. Before we tackle the problem of assimilation for today’s software products, there is much that can be learned from important research on how innovations spread within organizations and society. Software, after all, is just a way to implement an innovation.

Diffusion of Innovation (DOI) Theory Diffusion of innovation theories attempt to explain the adoption of innovation. It is defined as the “process by which an innovation is communicated through certain channels over a period of time among the members of a social system”(Rogers, 1995, p. 5). Diffusion research did not develop from a single discipline or a single event. The first discipline to contribute was anthropology that looked at how early humans adopted primitive tools. Other research areas also contributed including sociology, education, public health communications, marketing and management, geography and economics. DOI research started in the early 1900s when Gabriel Tarde plotted the now famous S-shaped diffusion curve. Most innovations have been shown to follow this curve (Rogers, 1995). Gabriel Tarde described the S curve in the following manner, “A slow advance in the beginning, followed by rapid and uniformly accelerated progress, followed again by progress that continues to slacken until it finally stops: These are the three ages of...invention...if taken as a guide by the statistician and by the sociologists, (they) would save many illusions.” (Tarde, 1962, p. 127)


Assimilation

43

The next major contribution to the theory’s development was found on Iowa’s prime farmland with a study conducted by Bryce Ryan and Neal Gross. In the 1940s, the hybrid seed was a major breakthrough in agriculture. They studied the diffusion of these “hybrid seeds” among Iowa farmers. The adoption pattern followed Tarde’s S curve, but what came from the study were the adopter categories made famous by Geoffrey Moore’s Crossing the Chasm. Ryan and Gross observed that not all farmers adopted the hybrid seed at once and that the time of adoption was correlated with the type of farmer. The farmers in Iowa were either innovators, early adopters, early majority, late majority or laggards. This construct remains a strong predictor of innovation acceptance, and has become part of our general vocabulary. The most important diffusion research for enterprise software is perhaps that of E.M. Rogers. In 1995, Rogers studied how diffusion of an innovation occurs and developed a comprehensive model to explain the variables that influence the process. His model of diffusion defined innovation as “an idea, practice, or object that is perceived to be new by an individual or other unit of adoption” (Rogers, 1995, p. 11). He defined communication as “a process in which participants create and share information with one another to reach a mutual understanding” (Rogers, 1995, p. 17). He identified five stages of adoption and “channels” through which information about the innovation is passed. A summary of the Rogers model is included in Appendix A. The software company introducing a new product can learn from these theories. They will help them fit their offering to the target population, be aware of the stages of adoption, and load their offering with characteristics important for the diffusion process. In the next section we provide guidance on how to do this.

The Dimensions of Assimilation With that brief overview of diffusion theory, lets look at the components of Figure 3.1. They are distilled from research on how new technology spreads and augmented with characteristics exhibited in the software industry for successful products. The goal was to select the important factors that affect diffusion of a software product rather than list all potential factors, of which there are many. Assimilation can be accelerated with attention to the variables shown in Figure 3.1. The characteristics on the inside of Figure 3.1 are under the control of the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

44 Le Clair

Figure 3.1. Dimensions of assimilation Managerial IT Knowledge

Bridge to Current System

Observability Transforming Technology

Trialability

Solution Complexity

Relative Usefulness

High Value Space

Replace the Complete Business Process Competitive Intensity & Market Confusion

software company. The software supplier must look for high value spaces, have transforming technology, and build bridges to the legacy systems. Increasingly they must understand the complete business process. The inside portion of Figure 3.1 shows the characteristics of successful innovation from the Rogers model. These can all be addressed in the design of the product and include: • •

• • •

Relative Advantage - The degree to which an innovation is perceived as better than the idea it supersedes. Compatibility - The degree to which an innovation is perceived as being consistent with existing values, past experiences, and needs of potential adopters. Complexity - The degree to which an innovation is perceived as difficult to understand and use. Trialability - The degree to which an innovation may be experimented with on a limited basis. Observability - The degree to which the results of an innovation are visible to others.


Assimilation

45

At the top and bottom of Figure 3.1 are two characteristics of assimilation beyond the supplier’s control. One is the customer’s comfort level and understanding of technology. Also out of the suppliers control is the competitive intensity and confusion in the industry. These are best used to “qualify” a market or a specific customer account. In other words, all things being equal, a product will assimilate faster where these characteristics are prevalent.

Management’s IT Knowledge Collective IT knowledge in an organization has been shown to be a key predictor of technology diffusion. For example, a study of diffusion for new Web-based supply chain management (SCM) technology showed that organizations with a higher understanding of the strategic potential of SCM seem to diffuse the required Web-technologies more easily than those firms who lacked such knowledge (Ranganathan et al., 2002).

Ripe Markets for Assimilation: Confusion and Competitive Intensity Confusion in a market will open the door for new solutions that allow the process of assimilation. Look for sweeping new regulations, fast-growing new markets, and where breakthrough technology will change the economics of a business process. New market entrants refining value proposition are also a symptom along with mature companies scrambling to align with the new players. This environment is easily recognized. Good companies have spent a lot of time creating solutions for flat markets. A good example of a flat market is check processing in commercial banking. Check processing includes high-speed scanning, optical character recognition and archiving of checks. The primary vendors are entrenched and dominant. They include IBM and Unisys. It is considered a flat market since check usage is declining and it is not a strategic application for banks. It does not help them gather assets.


46 Le Clair

Competitive Intensity Several studies have identified competitive pressure as important for the diffusion of technology (Grover, 1993; Premkumar, 1994). Highly competitive industries tend to drive more benefit from new technology adoption, and hence are under more pressure to deploy and diffuse technology rapidly. Investment and diffusion of new technology will occur quickly in the credit card and the cellular phone industry, for example. There is great competitive intensity in these industries. A bad customer experience or service and the consumer will consider changing. Basically, a consumer is more likely to change credit cards and cellular services than they are to change other relationships, such as their commercial bank. Commercial banks have you “locked in” to a greater extent and has less competitive intensity than industries where switching is easier. Managerial proficiency and competitive intensity are important but as mentioned they are somewhat out of the enterprise software supplier’s control. Lets move to characteristics of assimilation that can be made fundamental to product development and market strategy.

A: Replace the Complete Business Process Products that replace the complete business process are likely to assimilate more quickly than products that do not. Many software products only support part of the customer’s business process. Complete in this context does not refer to an enterprise-wide implementation such as CRM that attempts to integrate a number of departmental customer databases. Those are strategic platforms that are generally not targeted at a specific business process. The complete process referred to here is usually within a department and an important business function. It is defined as the totality of online and off-line behavior required to complete a business objective. To make this clearer, Figure 3.2 shows an account opening process for a bank. The complete process has six parts. The software supplier in this example is attempting to provide only the Web-based account-opening component. They


Assimilation

47

Figure 3.2. Example of the complete process for bank account opening Web-based Account Opening

Provided by Software Company

Customer Verification

New Accounts

Paper-Based Account Opening

Account Approval

Provided by Incumbent Mature Company

Account Maintenance

Customer Data Archive

have no solution for managing account applications submitted on paper, or a solution to provide account maintenance functions such as a change of address. They also have no workflow solution for account approval or to fund the new account. They also are missing the customer verification tools required by recently mandated anti-terrorist legislation. Why is providing only part of the solution in Figure 3.2 a problem? For one, software companies often compete with more mature companies. An established company may have solutions that cover perhaps four of the six areas. Even worse, they may already provide this solution for the customer you wish to obtain. Using the example in 3.2, the mature supplier may be missing or have a limited Web-based account opening product. If they have one at all it is probably inferior to the smaller software company. Their strength is that they have most of the solution covered. In this scenario the software company can not expect to win. Even if the online account opening has the latest “e-sign” features, which allows electronic signatures to be used, or a user interface with the latest HCI features, the partial solution is sure to stall the effort. In order to break into this market the software company will have to provide more of the account opening process that the bank requires. If you understand the complete process you can fill the gaps. You can build industry alliances that define and provide the entire solution. Alliance partners will be happy to plug into your solution, which need not be available immediately. In the enterprise market, all parts of the vision are not required immediately and can be delivered in phases. The main requirement is to present the complete vision, which will require the software supplier to understand the complete business problem as described. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

48 Le Clair

Understanding the Business Process As fascination with technology continues to wane, knowledge of the business process is gaining in importance. IT staff and their supporting suppliercompanies are starting to act less like “geeks” and more like business people. The fascination with speeds, feeds, and megabytes is being replaced with passionate understanding of the business process. Domain expertise will help us understand that complete process. I attended a meeting with several very senior financial services professionals. Each had over 20 years experience with successful companies like Fidelity Investments and Charles Schwab. They were given a tongue lashing by technologists from a start-up company, who belittled their antiquated processes and deficient knowledge of the “new economy”. The technical company had almost no knowledge of the financial services industry. The “bubble period” gave their lack of experience a bizarre credibility. In retrospect it could only be called naïve and arrogant. In this example, the software company representatives lacked domain knowledge, that is, the understanding of a specific application or industry. Its value is the ability to see the problem from the customer’s perspective and beyond. For example, the business process from the customer’s viewpoint will not be “retrieving information faster”, an IT task, but will be closer to the primary business problem such as “making a successful wire transfer”. Information is retrieved for a reason, and the customer is trying to solve some recurring problem that is part of an overall business process. Without this understanding, it is difficult to judge the potential for assimilation. Once the current business process is understood, the question becomes whether your solution has the potential to render the current business process obsolete. Will the technology and processes associated with the older process be discarded and how quickly will that occur. This is the essence of assimilation.

B: Technology Leverage One essential ingredient for assimilation is new technology that provides a major improvement over that currently used. Improved technology will allow something to be done faster, better and less expensively. But as we have seen


Assimilation

49

in the number of company failures, strong technology does not ensure success. It needs to be accompanied by reasonable expectations of behavioral change, smart implementation strategy and other value elements. During assimilation the new technology will overtake the old technology. The latest platform will be the target for new features and will steadily grow its intellectual property base. Technical innovation needs to be at the core of the new offering for this to occur, but treated in an equal role as the other factors of assimilation. Technical innovation is fundamental and enduring. Companies during the Internet boom, such as the online stores, relied solely on an innovative business model. Led by marketing professionals, these companies projected success based on behavioral change on the Internet with little proprietary technology. These companies were also the first to disappear. Companies based on innovative technologies found a way to continue as in the case of ObjectStore from the previous chapter. Their technology moved from database applications, to e-business middleware, to XML databases and is now being applied to the next challenge.

C: Bridging to the Old System Many products do not bridge from the old way of doing things to the new. In order to be accepted in their new home, products must provide a smooth way to interact with the legacy environment. The best products provide this migration path. Early adopter customers may be able to figure out a migration path and build their own bridges but if your solution does this for them it will assimilate more quickly and your value will be higher. As we will see in the next chapter, there are staff years of effort and extensive intellectual property in legacy systems. They have evolved over a number of years and are tailored to a company’s specific business problem. The system you hope to replace will operate in parallel with your product for some time. A bridge will reduce pain for your customer and raise your value in the process. It will help you assimilate. What are these bridges and how do we build them? Bridges are made up of many materials and here are a few that the software supplier can provide:


50 Le Clair

•

•

•

•

Technical compatibility with the legacy system is a major building material. Using standard and open platforms will provide this including a published set of application program interfaces (APIs). Often defined as either an “application programmer’s interface” or an “application programming interface”. These are standard and documented set of protocols and data structures. An API supports consistent interfacing by external software applications to primary software systems. The ability to access historical data from the old system is also important. Conversion routines or software can be bundled with the product that allows the user to switch from the old system to the new transparently. A socio-technical perspective can help us examine existing patterns of human interaction with the legacy system. We can look to mimic human behavior where possible to ease transition to the system. Alliances with existing suppliers are a great way to build a bridge. Connect your solution to the incumbent supplier and provide a bridge from the old to the new. This allows a gradual migration.

D: Appearance of a Significant Industry Value Gap Providing the complete business process, transforming technology, and a strong bridge to the previous solution are foundation components of assimilation. When combined with a product that combines the characteristics of innovation diffusion from the Rogers’ model, the software supplier is off to a good start, that is, the product is perceived as easy to use, and can be observed and tried out easily. But these characteristics are secondary to the customer’s perception of the product’s usefulness. In short, the new solution will assimilate only when a significant problem is addressed. If you do not find anxiety due to growth or pain in a customer and do not relieve the root causes of either then your solution has little potential for assimilation. Basically, the product must be a useful innovation and fill a value gap for the customer as described below. A growth value gap is created when the customer struggles to deliver a service in an expanding area (Heiman et al., 1998). For many solutions this is created


Assimilation

51

by growth in the customers core service offering that leads to the need for greater capacity. Capacity will depend on the industry. But it will translate to more transactions, throughput, processing power or new functions. It may be simply a new and more scalable way of doing business. A pain value gap is when a customer is not trying to improve a good situation, but is trying to avoid something really bad. The solution must provide a compelling ratio of pain relief against the disruption of embracing a new solution in terms of behavioral change, implementation difficulty, and cost. Value is not black or white, but rather set of tradeoffs that a customer makes. Lets review assimilation from the perspective of two emerging software companies.

Case Studies in Assimilation Two companies are described below that have strong strategies for assimilation. Contact Network Corporation and NewRiver, Inc., provide the necessary characteristics in their respective markets. •

•

Contact Network Corporation provides a product to automate an employee’s network of relationships and in the process found an interesting way to be compatible with existing customer solutions. In the NewRiver example, they combine e-delivery with printing a document from a database. This embodies a strong vision of a complete industry solution that will replace over time today’s process of storing documents on warehouse shelves. At the same time they built successful bridges to the legacy systems in the industry.

Social Networking Corporation Lets look at how companies in the emerging social networking market are trying to assimilate into their customer’s environment. But first lets look at the history of this emerging market. The social networking concept is simple. A person knows a lot of people from work, school, family, or church and you probably know some of their friends. But you probably don’t know their friends’ friends


52 Le Clair

at all. Join an online social network and the software will reveal these second and third degree connections. Social networking got its start when Jacob Moreno invented the sociogram in the 1930s (Fitzgerald, 2004). The sociogram showed peoples social connections with dots and lines. But each sociogram took hours of interviews and never became practical. Nothing much happened after Moreno’s discovery until 1967, when Harvard University psychologist Stanley Milgram made a startling discovery (Fitzgerald, 2004). He found that on average a person was only six acquaintances away from anyone else on the planet. Milgram was only 30 years ahead of the technology needed to make use of the discovery. E-mail, powerful-networked computers everywhere, and the Web were needed to form electronic communities to link these relationships together. In the late ’90s, emerging companies combined Milgram’s concept with the Internet infrastructure and looked for business opportunity. Times being what they were, they got funding but were unable to find a viable business model. Sixdegrees, as an example, launched in 1997 and grew to 3 million subscribers and hoped that advertising revenue would lead to profitability. There was not enough and the company closed down in 2000. But since then, a new market started to take shape called Enterprise Social Networking with a host of personal, public and professional solutions. Investors are investing again in social networking applications and it is a strong trend in information technology. White-collar workers already have contacts in electronic form, and companies are searching for new ways to ways to make better use of these electronic connections.

Contact Network Corporation Contact Network Corporation is a company in this market that has developed a strong assimilation strategy. Their three founders were experienced CEOs and entrepreneurs, with prior work experience at some of the largest companies in America. They recognized a widespread challenge that many companies had. Employees were constantly making cold calls into potential customers. These calls are ineffective, time consuming and unpleasant. At the same time, they also knew that employees have many helpful relationships that go untapped. The question became could they create a smart solution to leverage all those untapped colleagues?


Assimilation

53

The company, founded in 2001, followed a very practical path from concept to development: light prototyping, customer and industry feedback, beta test, pre-sell and product roll out (Briefing with Geoffrey Hyatt, 2004). It was an incremental approach, guided by direct user input. Their first beta test was in May of 2002, followed by a first customer in September. The idea for Contact Network came from Geoffrey Hyatt. While working at a large management-consulting firm, he had one project in which he had to test the validity of a new product development process at several large technology companies. To do this he had to call those companies, try to navigate to the right type of people, and hope they would take the time to discuss their processes with a total stranger. It was a frustrating situation for Geoffrey. He knew that many of his colleagues had friends at these companies that would be helpful, but being under a tight deadline he did not have the time it takes to hunt them all down. Sending a global e-mail does not get a good response rate. If only there was an easier way. Geoffrey had more than 15 years of experience in management and consulting with high technology and investment firms. He had founded Strong Numbers, a pricing research firm for calculating current fair market values of over 10 million products and had led the company from start-up to successful acquisition. Before Strong Numbers, he was at The Boston Consulting Group where he managed strategic and operational projects for leading global technology companies. Contact Network Corporation is targeting large businesses and the professional market. Listen to this description of their capability. It stresses aspects of their product that address the major customer issues for enterprise software discussed throughout the book. “Our product and business model make us very easy to implement (Implementation). We can have you fully up and running in 24 hours; deployment to users requires zero training – if you can use Google, you can use this [Behavioral Change and Assimilation]. Data entry is fully-automated, thus addressing one of the principal reasons for failure of sales force automation (SFA), customer relationship management (CRM) and knowledge management (KM) system implementations (compatibility with existing systems). Our system poses no risk to your mission-critical systems, and we support all leading data sources, such as Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

54 Le Clair

Microsoft Exchange and Lotus Domino. We also support integration with leading SFA/CRM and portal platforms. Finally, our straightforward business model – one monthly charge covers all license, maintenance and upgrade costs, enterprise-wide – means trying us is affordable and managing us is simple [business case: following the adoption curve].”(Retrieved from company Web site www. contactnetworkcorp.com on Oct 12, 2003) Contact Network has hit on all areas of assimilation. They build bridges to the existing CRM environment, have strong technology leverage, and offer a complete solution. Let’s look how their Enterprise Social Networking application relates to the SFA and CRM products that large businesses have installed. The assimilation strategy is two fold: eliminate data collection and enhance the value of the CRM solution.

Eliminating Data Collection CRM systems sometimes fail because the data entry workload by people in the field is burdensome. They put more in then they get out. Contact Network provides an application that grabs needed data from existing CRM systems, employment systems, outside databases, and even e-mail archives. Thus they feed on existing data repositories rather than make the organization build a new one. It can even feed the information it finds directly into a CRM system.

We are Here to Help Assimilation is also made easier by complementing rather than threatening the installed CRM systems. Laura Preslan, of AMR Research, made the following observations regarding the issue: “For years, companies have struggled to prove why tools are useful to sales people, and Customer Relationship Management. Vendors didn’t have much to add to the story. Social networking tools like Contact Network provide ways to maximize the value of an organization’s Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Assimilation

55

Rolodex. These tools don’t replace SFA, they increase adoption by improving the usefulness of the tools.” (Preslan, 2004) Indeed, part of Contact Networks value is increasing adoption for struggling CRM and SFA projects. This is strong strategy for assimilation. Ultimately, the CRM vendors will move into this market, and the customer will want to integrate the social contacts information with the overall enterprise view of the customer. Contact Network’s value proposition is off to a good start.

NewRiver, Inc. NewRiver, Inc. is a good example of hitting on all dimensions of assimilation. The solution has a complete vision to replace the warehouse-based fulfillment system for investor communications in financial services. Using XML and permission-based e-mail, it leverages the latest technology. It took dead aim at the intensely competitive financial services market that was in chaos for several reasons. More and more securities were being sold online altering the traditional broker-based distribution system. In addition, there was great pressure on costs and an increasing focus on compliance landscape. New River had discovered a major pain point for mutual funds and brokerage companies. Their solution is a strong example of building bridges to the existing systems. By handling paper as well as electronic delivery, behavioral change was reduced to zero. Financial service companies could easily migrate to the more efficient e-delivery by offering their customers a choice with a gradual and seamless way to migrate at their own pace. Other aspects important for assimilation were also evident in their solution. The new approach was easily observable. Since the product was visable on public Web sites, other companies and business units within their existing customers could observe the new solution. Since it gave customers a more focused and presentable product, the perceived usefulness and usability was high. NewRiver was founded in 1995. The first major application put marketing materials on CDs for the insurance industry. The insurance agent could print out or show materials only when needed from the CD. It reduced printing and


56 Le Clair

mailing of the material. In 1997 new venture capital was invested that allowed the company to move towards a broad range of applications in the financial services markets. NewRiver developed a solution along several dimensions. In 2000, they had the best e-delivery capability for compliance material in the market. Compliance materials such as a mutual fund prospectus are required to be delivered to investors by the SEC. In this way investors are informed about the mutual funds they have purchased. In support of the mutual funds industry alone, there are well over a billion paper fulfillments annually that must be sent to investors. The initial NewRiver application replaced the postal delivery of a securities prospectus, with an e-mail delivery. Electronic databases of SEC documents were maintained for this purpose with a patented process of associating the thousands of mutual fund filings received daily with the unique identifier. This association allowed linkage to the online trading systems used by brokers (NewRiver Inc., July 9, 2003, corporate Web site). NewRiver’s Prospectus Express™ is a great product. But the behavioral change required for individuals to accept e-mails for a prospectus or compliance mailing was moving too slowly. Replacement of a paper prospectus with e-mail required the investor to sign a legal “consent”. Investor “consent” rates were fewer than 5% for most segments. To address the low consent rates, NewRiver introduced consulting services to help clients build the electronic channel to reduce printing, warehousing and fulfillment costs. Clients could achieve savings by engaging NewRiver, which used marketing strategies and tactics to change investor behavior to increase consent adoption. NewRiver’s management came from the financial services industry and spent a lot of time thinking about the larger picture, that is, how the entire industry dealt with the problem of delivering billions of paper documents a year. In a sense, the view was of the entire “supply chain” from the filing of a document with the government until it landed in the investor’s mailbox. The research showed there are hundreds of locations where paper material was warehoused waiting for a security to be sold. Each sale, under SEC mandates, would trigger a shipment to investors through the U.S. mail. Some of these warehouses were as large as city blocks and employed hundreds of workers who “pick” documents from shelves and “pack” them into envelopes for shipment.


Assimilation

57

Figure 3.3. Example: Replacing the previous operational model (13) Cost of Delivery (Per Item) Electronic Delivery with POD Technology $1.00

$.75 Warehouse Fulfillment with Traditional Printing $.50 03’

04’

05’

06’

07’

As understanding of the entire investor supply chain became known, NewRiver became aware of emerging digital print on demand (POD) capabilities. POD allowed documents to be printed in real time and was starting to replace “offset” printing that would set up a document and produce thousands of imprints at once. With POD, NewRiver realized they could print the compliance information from their database. They would create a compliance document only when required and eliminate the warehouse “pick and pack” process. Further, this could be combined with the e-mail delivery product. Together they could provide fulfillment at half the cost of the warehouse approach. Figure 3.3 shows this trend in the industry that makes this solution work. The flat line of Figure 3.3 shows the approximate cost of sending a paper prospectus. This includes the cost of printing the material, storing it in a warehouse, and the postage to mail it. As can be seen this approaches one dollar for every document delivered and stays at this cost level. The slopped line of Figure 3.3 projects that digital printing combined with electronic delivery will move the cost of compliance fulfillment radically lower over time. As shown, current warehouse fulfillment will be replaced over time by a combination of these technologies, with POD fulfillment providing the interim step required to a full e-delivery solution. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

58 Le Clair

Build Intellectual Property Protection Around Your Assimilation Strategy Intellectual property (IP) has become one of the most important topics for an emerging company and the software industry in general. IP refers to the intangible products that stem from the collective minds of the company employees. By intangible we mean it lacks physical substance and can be the result of diligent years of labor, or momentary inspiration. These intangible products can be protected under the law, and will drive the competitive position and value of the company. IP should be of prominent concern to the senior management of the company and particularly to the marketing staff. For emerging companies, IP is simply the most valuable component of the company. Protection of IP is a highly specialized and complex legal subject. The intent here is to highlight the importance of having an IP strategy. It is important for success in enterprise software. Before an overview of how to develop an IP strategy, it is helpful to understand how it is created. Creating IP is a little like exploring dark caves. In the early days you probe unknown areas in the hope of finding something useful. You penetrate a series of layers as shown in Figure 3.4. Software companies have the ability to penetrate these layers quickly. Once the initial intellectual property base is built, they can create unique features rapidly at a low cost rate. A small group of inspired staff can get on a roll. It is what makes the software industry and the emerging company an exciting one to be in. The first layer is known and is the basis for the initial product. In many cases real value comes from areas you believe are important but are unsure what they are, and where only the customer using the new solution will discover and validate. These are areas that are known but as yet undeveloped. These innovations result from joint discovery with the customer where the urge to improve on a business process push the technology to new heights. The third and most interesting area are those that are unknown and undeveloped, and are where faith, intuition and strategic assessment become most important.


Assimilation

59

Figure 3.4. IP discovery process Emergent Demand Area Known & Developed

Known &

Unknown &

Undeveloped

Undeveloped

Emergent Demand Features A key part of developing intellectual property is exploiting Emergent Demand. Referred to in Figure 3.4, it is the development of new features that occurs as the users gain experience with the new solution. When the customer starts using the application, they will create uses for it that you can not imagine. It is emergent because you cannot know or predict the usage until the customer has the new capability in place. Emergent demand features argue well for an incremental approach to product development.

Protecting IP Once assimilation potential is identified, it is important to protect the IP surrounding it as long as possible. An IP protection strategy is one aspect of this, and there are two reasons to do this. The first is protecting your IP from potential competitors. A patent around your core technology or business process will make competitors work around what you have created. At a minimum it will provide you with a basis for litigation that can slow the competitor down. The second reason is to strengthen your market position in the eyes of customers. Surrounding your solution with a patent will create an aura that customers will respond to. Until recently a method of doing business could not be patented. After all, a method of doing business was more of an idea, like selling hot dogs with a precoating of mustard, and not a real invention. But in 1998, the U.S. Circuit Court of Appeals for the Federal Circuit changed this and allowed “business methods” to be patented. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

60 Le Clair

Now patents can be granted for software-based processes that perform traditional business functions. In a sense patent laws are tracking the trend towards technology directly addressing the business process. A business process patent can now protect a software company’s idea for doing business in a new way, even if it does not involve innovation in the underlying technology. IBM. even patented a method for keeping track of people waiting in line for the bathroom (Surowiecki, 2003). Another one was granted for describing a way for a barber to cut hair with both hands. These types of patents are growing year by year (Alexander & Lerner, 2002). In 1996, there were more than 100 such patents granted. In 2000, there were more than 1000. (Alexander & Lerner, 2002). Developing an IP strategy is straightforward. First you plan a half-day off site with key developers, marketing staff and a patent attorney, and assess what is unique about the “business process” around your solution. The patent attorney will help shape your business process patent and assess the probability of success.

Summary Figure 3.5 summarizes the primary characteristics of assimilation. These are plotted against Tarde’s S curve. A product meeting characteristics on the vertical and horizontal axis is likely to follow the adoption curve Tarde predicted. The rapidly accelerating part of the adoption curve is where you want to be. Success requires that a software product get on Tarde’s S curve. Are you really just replacing existing technology with newer versions and will be competing on price and performance, that is, have no real innovation. Are you merely a “fast follower” that focuses on your competitors? Will you have a partial solution for a business problem, perhaps providing a high level of specific value but falling short of what is needed for the complete business process? Do prospective users easily try your product? Do they perceive it as easy to use? And does it address a value gap that causes pain or provides opportunity for growth by your customer? Can others observe the value of your product easily? To get on the Tarde curve you need to be “where the puck is going to be,” searching for the solution that alters the industry in some substantial way.


Assimilation

61

Figure 3.5. Tarde’s S curve combined with assimilation characteristics Bridge to Legacy System Complete Business Process Value Gap Technology Leverage

Assimilation Potential

Management Knowledge Perceived ease of Use Trialability Observability Competitive Intensity

References Contact Network Corporation (2003). Retrieved from company Web site on Oct 12, 2003: www.contactnetworkcorp.com Patorak, A., & Lerner, P. (2002). Essentials of intellectual property copyright. Hoboken, NJ: John Wiley & Sons. Briefing with Geoffrey Hyatt. (2004, January). Personal communication with founder/chairman of Contact Network Corporation. Fitzgerald, M. (2004, April). Internet working. In Technology Review: MIT’s Magazine of Innovation, 45-49. Christensen, C. (1997). The innovators dilemma: When new technologies cause great firms to fail. Cambridge, MA: Harvard University Press. Grover, V. (1993). An empirically derived model for adoption of customerbased inter-organizational systems. Decision Sciences, 24(3), 603-640. Heiman, S. et al. (1998). The new strategic selling: The unique sales system proven successful by the world’s best companies. New York: Warner Books.


62 Le Clair

Le Clair, C. (2001). One technology: New fulfillment techniques cut costs of delivering documents to investors. Mass High Tech, Sept 24, 1-3. NewRiver, Inc. (2003). Product description prospectus express. Retrieved June 14, 2003: www.newriver.com NewRiver, Inc. (2003). Company white paper. Retrieved June 19, 2003: www.newriver.com Premkumar, G. (1994). Implementation of EDI: An innovation diffusion perspective. Journal of MIS, 11(2), 157-186. Preslan, L. (2004). AMR research quote from Network Contact Corporation Web site. Retrieved Sept 3, 2003: www.contactnetwork.corp Ranganathan, C. et al. (2002). Diffusion of Web technologies in the supply chain management function: Diffusion of interest group in information technology workshop (DIGIT), Barcelona. Rogers, E. M. (1995). Diffusion of innovations (4th edition). New York: The Free Press. Surowiecki, J. (2003, July 14). Patent bending. The New Yorker, July 14, Talk of the Town. Tarde, G. (1962). The laws of imitation. New York: Peter Smith


Assimilation

63

Appendix A: Summary of Rogers’ Diffusion of Innovation Theory Rogers points out that an innovation may be rejected during any stage of the adoption process. This is an important point for software suppliers. Success is not when the sale is made, but when the product has reached stage five of the adoption process. Rogers defines rejection as a decision not to adopt an innovation whereas discontinuance is a rejection that occurs after adoption of the innovation. Rogers summarizes many of the significant research findings on discontinuance. Many “discountenances occur over a relatively short time period” and few of the “discountenances were caused by superseding of a superior innovation replacing a previously adopted idea”. The relatively later adopters had twice as many discountenances as the earlier adopters. Previous researchers had assumed that later adopters were relatively less innovative because they did not adopt or were relatively slow to adopt innovations. This evidence suggests the later adopters may adopt, but then discontinue at a later point in time. Rogers identifies two types of discontinuance: • •

Disenchantment discontinuance – a decision to reject an idea as a result of dissatisfaction with it’s performance, and Replacement discontinuance – a decision to reject an idea in order to adopt a better idea.

The Innovation Decision Process Rogers defines the innovation-decision process as the “process through which an individual or other decision making group, passes through the innovationdecision process”. There are five stages in the innovation-decision process: • •

Knowledge of innovation Forming an attitude toward the innovation


64 Le Clair

• • •

Making a decision to adopt or reject Implementation of the new idea Confirmation of the decision

Rogers believes that prior conditions affect the innovation-decision process such as: • • •

Felt needs and problems, innovativeness Previous practice Norms of the social system

The first stage of the innovation-decision process seeks one of three types of knowledge about the innovation: • • •

Knowledge that an innovation exists Knowledge of how to use the innovation properly Knowledge of the functioning principles underlying how the innovation works

Of importance to assimilation is the innovation-decision process and how can we build products that diffuse more quickly. The assimilation model provided in Chapter III is based in part on the Rogers’ model.


Implementation Difficulty 65

Chapter IV

Implementation Difficulty

“I do not fear computers. I fear the lack of them.” Isaac Asimov To be successful a customers must be able to install and implement the enterprise solution within a reasonable time and without too much effort. Many potentially strong solutions require too much effort by the customer. This chapter has four parts to address the implementation issue. We look first at where we are today and try to understand customer’s disillusionment with the speed, flexibility, ROI and interoperability of enterprise software installations. These are circumstances we cannot control. We are where we are. More importantly, we look at perspectives and methods that will help us do something about it. These include monitoring our service-to-license ratio, minimizing customer-driven changes to our standard product, monitoring our sales cycle, keeping our solutions focused, and taking a broader view of training. In short, we look at implementation from the customer’s view. Case studies are then offered that highlight companies that have developed unique strategies to deal with today’s challenging implementation environment. Lastly, due to long-term affect on implementation, we examine Web services. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

66 Le Clair

Infrastructure Burnout Over the past decade, implementation issues have consumed customers. Many of these implementations were strategic “infrastructure” technologies. So called since their goal was to provide a strategic platform for the long term and less to solve a specific business problem. The following excerpt from a highly regarded research consultancy was typical from this era (Fontanella, 1999): “Surrender! Resistance is futile. The Internet is here, and there is no escape. Knowledge is the network in the supply chain. With it, you can buy, sell, bid, collaborate, communicate, acquire, and retain customers, define industries, and bury the competition. If you are one of the few remaining skeptics, a Luddite ignoring the inevitable transformation, you better listen up or you may be out of a job.” (p. 100) This was a prevailing attitude of the period embraced by investors, businesses, and the public that encouraged firms to launch projects based on a vision rather than fundamentals of their business. The results were truly out of control.

The Technology Period Peaks Many companies have struggled to implement enterprise software successfully. This is true for specialized applications as well as the larger enterprise applications. Without doubt the most dramatic struggle occurred with ERP systems. Figure 4.1 lists notable ERP projects. According to Meta Group, a leading U.S.-based consulting firm, the average ERP implementation took 23 months, had a total cost of ownership of $15 million, and returned an average negative net present value of $1.5 million.

The Post-Technology Era The decade began with many stories like those in Figure 4.1, as firms struggled with implementing ERP and CRM and other enterprise software infrastructures. But these were indeed unique times. Year 2000 preparations had drained Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


Table 4.1. Notable ERP implementations (2) Company

Project Summary

Whirlpool/W.W. Grainger

Project Delays and Cutover Problems

Waste Management

Had to Revert to Legacy Systems

FoxMeyer (Pharmaceutical)

The Project Bankrupted Company

British Broadcasting Corporation

At least an Eight-year Project

General Motor’s Locomotive Unit (3)

Spare Parts Unit Seriously Affected

Russ Berrie and co. (Teddy Bears) (4)

3-year Saga. Reverted to Legacy System

Hershey

Short of Quarterly Sales Target by $100m

resources and e-business required companies to implement a vast amount of new software and applications. Often the project had arbitrary deadlines that pushed the technology ahead of the organization’s ability to deal with it. The convergence of these efforts marked the height of the Technology Era and the emphasis on strategic technology (Wladawsky-Berger, 2003). We are now in a new era where corporate thinking has changed. There is now a reluctance to embrace sweeping enterprise implementations and a shift to projects that target specific business problems with a high ROI. Implementations in the posttechnology era will tend to be smaller in scope and closely aligned with a specific business problem. These trends will level the playing field for emerging companies. The door will be opened wider for innovative and focused solutions, as long as they are standards based. To make this clearer, let’s look at the major enterprise software solutions in more detail. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

68 Le Clair

The Hershey Corporation Hershey took three years and four different teams of consultants to implement their ERP system. The implementation also included planning and scheduling applications. The goal of the $115 million system was to replace scores of individual legacy systems that were running inventory, order processing, human resources and other applications. The implementation approach that Hershey used came to be known as the “Big Bang” with all parts of the new system going live at once. It became truly a big bang for senior management when the system did not work. During Halloween of 1999, Hershey’s customers were loading up on candy from competitors like Mars and Nestlé while their own warehouses piled up with undelivered Kisses and Peanut Butter Cups. The problems caused the company to fall short of its third-quarter sales target by $100 million dollars and may have been the first enterprise software implementation to trigger an earnings warning (Computer World staff, 1999). An analyst at the time said that Hershey’s approach was unusual and that most companies install ERP systems in a more staged manner, especially when applications from multiple vendors are involved (Shepard, 1999). “These systems tie together in very intricate ways, and things that work fine in testing can turn out to be a disaster (when you go live),” he said. He added that the software Hershey turned on all at once in July was, “a huge bite to take, given that (processing orders) is the lifeblood of their business” (p. 2). Hershey stayed with their ERP vendor after the early troubles and in the end the project met the original vision of integrating Hershey applications (Osterland, 2002). Ninety-five percent of its revenue and business transactions ended up being processed within a single system. The new system provides the company with greater consistency, visibility and real-time access to critical business information.

Unrealistic Schedules Hershey’s ERP project suffered from a demanding schedule that pushed the system to be cut over at once. During the technology period, this obsession with speed was common. And even today we remain obsessed with rapidly deploying new technology. A recent search through Amazon found over thirty books on technology and business that contained speed in their title. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


Is the fascination with speed healthy for implementing enterprise projects that touch on so many human and technical aspects? Or are we trying to install technology too rapidly without understanding it’s effect on the organization. The answer was yes according to the book Business at the Speed of Stupid (Burke & Morrison, 2002). Two industry consultants detail the problems that arise when a perceived need for speed gets in the way of serious planning. They document ill-advised, fast-track projects to rush into e-commerce and integrate enterprise software.

The CRM Challenge A successful CRM system combines customer databases that reside in sales, marketing, and customer service. Before the CRM vision each department would use separate systems for recording customer interactions. These departments grew information islands and were unable to share information about a customer relationship. When you spoke with your bank about a bounced check, they would be unaware that you had a car loan, a mortgage, and perhaps were a private banking client, that is, one of their best customers. Some companies were better at knowing their customers. When you ordered a pizza, the large chains often know who you are by your telephone number. They know what you ordered last time. They may comment that your son ordered before. “Is their anything wrong with Justin?” For our most advanced companies, particularly in financial services, the simple task of knowing whom you were talking to has proved daunting. CRM systems offered great hope. For these large firms, the problem was not as simple as may seem. They have many ways to communicate with their customers including e-mail, facsimile, telephone and the Web. And each line of business might choose a different way to communicate with the customer. In theory, the CRM would provide consistency with customer interaction and data collection and be the functional glue among the Web, customer service, sales, marketing and financial systems. The vision was superb, but implementing CRM systems encountered many socio and technical issues. On the organizational side there was an inability for all departments to view the customer in the same way. Each department believed they owned the customer, and saw them through a different lens, one it viewed as optimal for their business unit objective. For CRM to work, all departments must view the customer in the same way from an information perspective. For some projects, it might take months to get Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

70 Le Clair

agreement on the basics of what customer data to capture. Often the CRM software implementation would start before these important human and organizational issues were resolved. In addition, customer data meant power for that individual or department that owned it. The CRM system would often centralize and make these data available outside their department. Owning and managing a departmental customer database meant job security for many. The early CRM solutions did not do a good job of understanding potential attitudes and organizational issues.

The Integration Gap ERP systems helped eliminate silos within administrative systems or the “back office”. In the same manner CRM helped eliminate customer information silos. ERP and CRM projects both had the goal of integrating data across departments. Unfortunately they only integrated data relevant to the goals of their singular vision. CRM and ERP got rid of departmental silos but replaced them with application silos. Even worse, the software platforms proved to be proprietary and inflexible. SAP for example required something called ABAP/4, a non-XML-based set of APIs. Siebel added functions by acquiring small third-party vendor solutions, which required a plethora of non-standard interfaces to work with. PeopleSoft required proficiency in PeopleTools. In fact, the new platforms proved no more flexible than their much maligned “legacy” system predecessors. These integration efforts were difficult enough, but even more daunting was the prospect of integrating CRM with ERP with the Web. This is the integration gap shown in Figure 4.2. E-business confronted organizations with yet another significant integration task. The race to e-business widened the integration gap of Figure 4.2, as both ERP and CRM struggled to support emerging customer-self-service and emarketing. Already overwhelmed by long and expensive implementation efforts, customers could not face yet another major project, particularly when the ROI promised for the initial project was not realized. Even worse, as mentioned, the major enterprise software applications used proprietary and non-standard development environments to integrate with outside applications.



Figure 4.2. Enterprise software silos Accounting

Human Resources Payroll Customer SelfService

ERP Solutions E-Business Solutions

2005 Integration Gap

CRM Solutions Customer Service

Online Marketing

Marketing Sales

The integration gap of Figure 4.2 prevented the goal of “back office” and “front office” integration from being achieved.

Implementation Help Successful emerging companies today will provide small-scale, focused implementations that are part of a larger vision, but address a near-term business problem. The following are factors that will be common to their success: A: B:

They will manage the service-to-license ratio They will develop product adaptation strategies, vertical applications, and take a “best practice” approach C: They will monitor their sales cycle D: They will keep the solution focused E: They will understand the interdependence of their product with the customer’s organization and systems F: They will provide a “process view” of training with support for the changemanagement process


72 Le Clair

Figure 4.3. Service to license ratio 5/1 3/1

PeopleSoft (2.6) ERP Oracle (1.7) Database

1/1 .5/1 Service/SW Ratio

Siebol (1.2) CRM

Preferred Zone

A: Managing the Service to License Ratio As important a solution is, it cannot require too many professional services to implement. So how much is too much? One indicator is the service-to-license (S/L) ratio, which is the ratio of professional services to licensed software for a given implementation. This is shown in Figure 4.3. The service-to-license ratio is shown on the vertical axis. For reference the S/L ratios for the major enterprise software suppliers are shown. For enterprise software, a reasonable goal is to keep the ratio at one to one or less, towards the bottom of Figure 4.3. Every dollar the customer pays for the initial software license, should have less then one dollar required for professional services. This goal will keep profit margins high and ensure the implementation burden on the customer is kept to a minimum.

Trends in Service License Ratios Of interest is the trend in S/L ratios. Figure 4.4 plots the S/L ratio for Siebol, Oracle and PeopleSoft over the past seven years. The Appendix has this revenue breakdown reported by these companies in their annual reports. In 1997, revenue from services exceeded software license revenue and has not looked back since. As shown in Figure 4.4, 1999 was the peak where every $1 of software from these premier vendors required $3 of services to



Figure 4.4. Trends in service license ratios 3.5 3 2.5 Siebol Oracle PeopleSoft

2 1.5 1 0.5 0 96'

97'

98'

99'

00'

01'

02'

implement. This was the peak of the technology period where companies threw money and bodies at strategic visions. So why was this ratio so high? First, to get benefit from these infrastructure systems required the integration of diverse customer systems. As discussed, this was a hard task at most companies. Second, deciding the business requirements for each project required extensive consulting services. Customers had become aware of a number of failed projects and started to plan more carefully. Thirdly, realizing the vision these solutions promised just took more effort than anyone thought. Large customers had complicated organizations with fragile and interdependent parts and special needs. Projects of this scale took time and resources. During 1999 and 2000, there was also a shortage of qualified analysts and software professionals and this began to limit the growth of software firms. To help, software vendors teamed with consulting organizations to help with the integration effort. Unfortunately, these firms lengthened implementation time and the costs. Hopefully with standards like Web services and perspectives contained in this book we will see service to license ratios improve.

The Difficulty of Maintaining High Margins Despite the potential of high service-to-license ratios, the software business is attractive. Once developed, software, in theory, can be sold to many customers


74 Le Clair

over and over. Software companies are expected to have “gross margins” in the 60% to 80% range. In the enterprise software segment these economics have proven difficult to achieve. As discussed, business customers want customized solutions. Each client absorbs behavior and other change from the intrusion of the new technology. These include integration with their proprietary systems, specific client preferences and unique infrastructure requirements. As we have seen in the increasing S/L ratios, enterprise solutions have had to increase professional services. They have essentially combined the lowermargin professional service business with the higher-margin software business. This trend is clearly shown in Figure 4.4 and has reduced the profit margins of their business. The emerging company needs to have a realistic view of the required professional services to scale their business.

A Lack of Respect for Software There is also a surprising lack of respect for software. Customers know how inexpensive it is to make a copy and they focus on these low incremental costs. They undervalue the collective R&D required to develop the intellectual property. They do not understand the costs of building an enterprise software business. Hardware is not perceived this way despite having similar economics. The first satellite a company builds may cost $30 million with a large portion of that being research and development. Version two may cost only $500,000 to manufacture, yet customers are less likely to question the price of the second satellite. Perhaps customers are just more comfortable paying for more tangible products like professional services. People are more tangible than software and there may be a “hangover” from buying too much software during the technology era. The reluctance to pay for software licenses may explain, in part, the climb of the service license ratio.

Monitor the Ratio to Get a View from the Customer’s Perspective The service-to-license ratio can be monitored by the software company more carefully then it is today. It will show up in the financials as lower overall gross Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


margins than forecasted. But it is a more important indicator of how much pain the software company is pushing on their customers. All revenue is welcome but an increasing ratio may indicate the customer is struggling to get value out of your system. There may be an implementation flaw in your product.

B: Develop a Product Adaptation Strategy, Vertical Applications and a “Best Practice” Approach There is tremendous pressure exerted on the software company to modify the “standard” product to meet the needs of a specific customer. Often a major sale will hinge on this aspect of being “responsive”. How these requests are dealt with affects the potential scalability of the software company and the customer’s implementation time and cost. The reason the customer wants to change the standard product is understandable. Customers buying enterprise software almost always have “processtechnology” gaps. These occur when the general software product differs from their standard business process. These gaps can take the form of data elements that are not captured in the database schema of the product but are important to the customer’s business. Or they may be a software function, like the generation of a key report that is missing. The customer is faced with two choices to reduce a process-technology gap. They can change their business process to fit the purchased product and hope that the software vendor is using “best practice”. Or, the customer can pressure the supplier to change their product. The later approach is easier for the customer in the short term, hard for them in the long term and difficult for the software supplier on both counts.

The Slow, Painful Death Customer-initiated product changes can slow or destroy the emerging software company’s progress towards maturity. Mature software vendors realize this and may even withdraw technical support for a product if forced to make a


76 Le Clair

significant change. Resistance to customer-initiated adaptation arises for several reasons discussed throughout this book: • • •

• •

Deviation from the best practices embedded in the software may impede implementation success. Product modifications will make the implementation longer and adds risk to the project. Vendors resist adaptations since they believe, as developers of the software; they have the best perspective on what the software should do (Rogers, 1995). The complexity of the software package often makes customization difficult. Software maintenance becomes more expensive as the software company ends up with a number of “one offs” in the field.

Researchers at Harvard investigated customer satisfaction with CRM project performance based on the level of customer-driven modifications to an industry standard software package. They surveyed 60 Siebel implementations of CRM systems and collected useable performance data from 46 firms for the period ending March 2001 (Cotteleer & Frei, 2002). The study found that database modification, when used in moderation, leads to improvements in customer satisfaction. However, excessive database modification results in reduced satisfaction, leaving the firm no better off than if it had minimized this kind of adaptation in the first place. The study concluded that too much modification of the standard product was bad for the customer.

Develop Vertical Applications The study also found a higher level of customer satisfaction with “vertical” or industry versions of the product. These are general releases of product versions tailored to a particular industry. They serve to reduce process-technology gaps, address a more complete business process, and build more domain expertise within the software company. In short, versions of the software package that are adapted to meet the industry-specific needs of potential clients will create a better fit.



Use Domain Expertise to Incorporate “Best Practices” in Your Standard Product The best way to reduce the pressure for standard product changes is to have a low level of process-technology gaps in the standard product (Cotteleer & Frei, 2002). This is accomplished by incorporating “best practice” for your customer’s business process. This argues for more focus on the customer requirements in the front-end of product development. The fewer the gaps the less product changes required and hence shorter implementation times. In the future, pressure for incorporating the “best practice” into enterprise software products is likely to accelerate. Business process change is expensive and has contributed to the long drawn out implementations cited earlier. Customers will be looking to avoid these changes except where business benefits are clear.

C: Monitor Your Sales Cycle Long sales cycles are a sign that a company’s solution might be difficult to implement. The sales cycle is the length of time from first meeting with a prospect to having a signed contract. Twelve months to two years is considered long for enterprise software. Six to nine months is a good range. During a sales cycle the prospect reviews every aspect of the companies product. The security group reviews how access to the product will be controlled. Will there be a separate security database for the product or will the prospect’s master security database authenticate the user? IT will examine the products design to be sure it meets corporate standards. Can their administrators work with the products database? Is the operating system UNIX or NT? And if UNIX what flavor, HP, SUN or IBM? Does it run on the companies preferred hardware platform? And those are the easy questions. The hard ones concern the firms legacy systems. What are the integration points with other software? How much work will be required to complete the installation? Each business unit that will use the system will examine the product from the perspective of their business process. Does the product’s feature set map well to their current business process? How much development will be required for


78 Le Clair

the product to do what the customer needs? Will the customer’s business process need to be modified?

Borland Software Corporation A software company’s ability to grow can be effected by security, architecture, and integration issues. Borland Software Corporation shifted their strategy over the years from licensing software tools to small developers, to tools for large enterprises. Since 1983, Borland has provided tools to speed up application development and was a pioneer. They launched one of the first PC development environments, Turbo Pascal, ®, which made possible the commercial development of PC applications. In 1997, Borland shifted its development expertise to enterprise application deployment. In 1999, they describe in their quartely report how hard it is to sell and implement enterprise software solutions: “We believe that a significant percentage of our future revenue will be from enterprise customers. These transactions typically contain multiple elements, including licenses for development and deployment products, technical support, maintenance, consulting and training services. As a result, these customers generally commit significant time and resources to evaluating our software, and they require us to expend substantial time, effort and money in establishing the enterprise relationship and in educating them about our software products and solutions, which can sometimes result in lower operating margins. Also, sales to these types of customers generally require an extensive sales effort throughout the customer’s organization and often require final approval by the customer’s Chief Information Officer or other senior ‘C’-level employee.” (Borland, SEC Filing #0-16096) This is a succinct description of the challenges faced by the enterprise software company. One way to minimize these challenges is to keep the solution focused as we see in the next section.



D: Keep the Solution Focused From discussions with large purchasers of technology, they will be making purchase decisions based on the merits of a specific application rather than on enterprise software suites. Given this, the software company will need rapid implementation strategies, which will involve emerging standards like Web services discussed later in this chapter. A consistent theme heard is that customers will not tolerate long, drawn out implementations of enterprise software. Broad purchases of software from CRM, ERP and other vendors will give way to focused purchases. An enterprise software suite may have 27 modules. The customer will want to know the “value” of each and will select a subset for implementation. A Gartner Group survey showed that enterprises do not deploy 41.9% of the customer relationship management (CRM) licenses they buy (Gartner Group, 2003). The emerging company needs to be aware of this history when approaching customers with new solutions. Purchase of enterprise software licenses reflected the previous era’s fascination with technology infrastructure and not fundamental need. For the foreseeable future, there will be more focused purchases and implementations. One way to help succeed is to target a small number of departments for implementation. Lets look at how to do this and why.

Minimize the Number of Departments and Customer Systems Affected by the Implementation How long a product takes to implement depends on the number departments that participate. A large number of departments will mean a long implementation. A project for one department will be easier for several reasons: • • • • •

There is a single project sponsor that can make decisions. Requirements will be focused, agreed to quickly, and not negotiated. The project does not depend on departments cooperating with each other. There will be fewer customer systems to integrate with. Potential organizational change and user attitudes can be better understood and proactively managed.


80 Le Clair

The fewer the departments involved, the more likely the solution will be bought and installed. Stated another way, the chance of failure grows with the number of affected departments. Thomas Siebel is the founder of Siebel Systems, the leading supplier of CRM systems. In Taking Care of E-Business, Siebel emphasized the need for senior managers to commit to CRM for a project to succeed. He argues that the successful project requires intense cross-departmental cooperation and this must be driven from the top (Siebel, 2001). Few who have worked on a CRM project will disagree with either of these statements. The challenge is that senior management commitment is difficult to obtain and even more difficult to sustain. They are concerned with the core aspects of the business. They may not devote the needed energy to an internal system project. The larger the project the more senior management attention needed. Today’s senior management asks middle management to do more with less. Coordinating with other departments and keeping people on the same team is hard work. When this does not happen the results are too often failed projects. CEO commitment and department cooperation are requirements levied on the customer by the supplier. Ultimately, value is a ratio of customer pain to the product’s perceived usefulness. It is the collective value exchange ratio for all stakeholders. Enterprise software that requires extensive cross-departmental cooperation creates customer pain and has weakened value propositions.

E: Understand the Interdependence of Your Software with the Customer’s Systems When a customer elects to install your software they are making an implementation commitment. The value of the software product is affected by the amount of this commitment. Value will decline when a hard piece of integration is required while products that install with little commitment will have increased value.

Unlock the Value Value is sometimes held hostage. This occurs when an important use of the product is only available when it is integrated with a customer system. In this Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


case, the value of the software depends on a linkage to a customer system and is an example of the type of dependence found in complex environments. It’s common for the collective value to be part of the initial vision but in practice harder than anticipated to achieve. As a result, the product languishes with only casual users and no excitement. Early attitudes of potential users become negative and the diffusion and assimilation process is slowed. Some pockets of value require small efforts to liberate while others are significant and will lock up that value for a long time. A small example may involve the seemingly simple task of integrating the new application with the customer’s master security. Many software applications have their own security application, where a full set of authorized users and their privileges are maintained. This unfortunately requires a separate log and password to be entered by the user. In the initial vision of the system, it may have been assumed that the customer’s mainframe security would control access, so that if a user were logged onto any of the primary corporate applications, they would not need a separate log in. But getting this integration finished may prove to be a large effort. Requirements for what security criteria to pass to the master database and how to pass them may take longer then anticipated to finalize. The overbooked IT professionals required to write the software on the customer’s side perhaps are just not available. A key value to the system is under lock and key and will affect the perceived usefulness and usability of the system. How can the software company know the value of their product without a clear picture of the work involved to make the product productive in the customer’s environment? Can they understand what to charge without knowing the dependence between their software and the customer’s environment, and the expense on the part of the customer to exploit the dependence? The answer is they cannot. Significant investment in many software products has been made without this basic understanding. A good starting point to recognize key dependencies is to: 1. 2. 3. 4.

Identify the customer systems that need to be integrated with your solution. Determine the human, organizational, and technical dependencies for each. Determine the cost, time and the customer resources (staffing levels) necessary. Determine the “pockets of value” and relate them to resource required.


82 Le Clair

5. 6. 7. 8. 9.

Prioritize “pockets of value” based on value to the user and installation effort. Develop strategies for each affected subsystem. Create a project management template for the customer. Prepare a training curriculum that includes organizational and process changes. Prepare sales material or a white paper outlining the implementation.

F: Provide a “Process” View of Training with “Change Management” Support Change management surrounding enterprise systems is often harder to manage than the implementation of the technology. In speaking with senior IT and operations executives, new technology projects are exercises in “change management” (Le Clair, 2003). How will we ever adapt the organization to work withthis new system? Change management is the cost of handling all the newness caused by the system. These will include human resource expenses related to hiring, downsizing and creating new positions. For example, for many software installations, lower-skilled tasks such as data entry are reduced, while jobs that require more cognitive effort are increased. There are significant organizational costs to manage these changes. In addition, there is lost productivity that occurs when resources are shifted from day-to-day tasks to implementing the new system. Change management costs range from quite small for more specialized software products to vast when deploying a new ERP solution And perhaps the largest change management budget item is training. The academic and trade literature blames poor training for the difficulties firm’s have in generating business value from enterprise software. The cover story for CIO Magazine a few years ago proclaimed rather directly that “ERP Training Stinks”(Wheatley, 2000). While most of the research has focused on major enterprise systems such as ERP, the problem applies to most business-tobusiness software.



Why Isn’t Our Current Training Approach Working? One problem cited is that most training is focused on use of the new software and ignores changes in the organization, process and information flow. Today’s training, for the most part, helps the new user navigate through the system, but provides little understanding of the overall process, such as why they are performing the task at all. Basically, vendor software training does not enable users to understand the information flow and business processes (Wheatley, 2000). This narrow view of training is the result of the software supplier’s limited understanding of the business process as discussed in Chapter III. Whatever, the reason the software company needs to take a broader view of the customer’s business process and incorporate this view into their training. Software firms may want to think in terms of “change management”. This will require “off the screen” thinking to combine more traditional vendor training with understanding of the business process and the special needs of the industry (Augustson, 2002). It will become necessary for the software supplier to know the new positions their systems create, the new job descriptions, complete off-line and online behavior required and all required skill sets. Instead of telling people how to use the software, why not prepare a curriculum that explains the different business processes that will be affected by the new system. The curriculum can be modified with the help of the customer and started well before the software is installed (Wheatley, 2000). The irony is that we now have the most sophisticated training methods available. These include Web-based virtual classrooms, computer-based training, knowledge warehouses, video courses, self-study books and pop-up video and help screens. But if they do not take a “change management” or business process perspective, then they are no improvement.

Case Studies Here are two case studies that focus on implementation. The first discusses issues with an electronic bill payment system and shows how to understand the implementation affects of a software product. This is followed by OpenPages, a software provider in the emerging compliance application market. This


84 Le Clair

company shows how a short and focused implementation can win in the marketplace.

Electronic Bill Presentment and Payment New electronic bill presentment and payment (E-BPP) soltions created implementation challenges for most enterprises deploying them. Figure 4.5 is a simple charting of the primary affected subsystems and departments for an EBPP implementation. The shaded areas are the emerging E-BPP components that must be introduced. These two systems will affect the other systems shown in Figure 4.5. With E-BPP the consumer or business would use the Web to review a bill and pay it. An e-bill payment gateway would move the dollars from the consumers account to the billers. For this self-service application to work for the consumer and the company providing the service, it needed to be integrated with the internal systems shown in Figure 4.5 where integration is both technical and organizational. To be effective, the new E-BPP application needed to be seamless. It needed to fit in with company’s billing and customer service systems. For example, a customer service representative (CSR) must trace a transaction from start to Figure 4.5. Implementation issues of E-BPP Traditional Billing System

Printing and Mailing

E-Billing Payment Gateway

Electronic Bill Presentment and Payment

Customer Self-Service Web Site Customer Service Center



finish and do this for an electronic or paper bill. Providing this integrated view of paper and electronic transactions required integrating data across the systems of Figure 4.5. With the new system, the CSR now had to be trained to respond to issues that may be encountered from a customer using the Web for bill payment. They had to be conversant in delivery, payment, and settlement data from both the paper and Web world. So even though the numbers of call center personnel were reduced due to the Web, the remaining CSRs needed to be more sophisticated and better trained. This took time and expense and is an example of change management costs resulting from the new solution. The initial challenge of E-BPP solutions was the amount of work required by the biller to integrate with the systems of Figure 4.5. Despite having a very strong ROI the value proposition was weakened by these implementation challenges.

OpenPages OpenPages is a good study of how to break into a new market in the posttechnology era. They used a rapid implementation approach and focused on a business problem that had to be solved quickly (Duffy, 2003). The situation Mike Duffy inherited was not pretty. In December of 2000, the product of the software company he took over used a client-server architecture. His competitors in the content management market, like Vignette, were already Web-based. OpenPages was losing every opportunity it was entering. Further the product had different versions for each of the twenty customers. Like many software companies they had built one-off versions. A software development team in Russia would send patches and new releases directly to the customer. There was no U.S.-based version control or testing. Customer commitments were not being met and they were showing their unhappiness by not paying their bills. This was December of 2000, the beginning of the worst downturn for technology spending in a decade. OpenPages was burning $12 million a quarter. And at this rate, the $21 million cash balance would be gone in less then nine months. Mike needed a new direction for the company and needed it fast. The firm employed 340 people that included the145 offshore developers in Moscow. Mike relied on his general management training from Intel, and


86 Le Clair

quickly downsized the company. He cut staff in January, March and May of that year and by July 2001 he had reduced the head count to 45 employees. He closed down the Russian offshore operation, continued to get control of the existing customers, and struggled to improve the cash position. But after trying several new product directions, he still did not have a winning strategy and time was running out.

Sometimes Long Commutes are a Blessing In early 2003, CEO Mike was half way through his tortuous two-hour commute to his struggling company. Somewhere on route that morning, a radio broadcast described the new Sarbanes Oxley (SOX) legislation and the effect it may have on the stock market. Under SOX, key executives of the company had to sign off on financial reports and were liable for any wrongdoing in their preparation. If CEO’s refused to certify financial reports, the U.S. stock market may be severely affected. The message was clear. This was indeed powerful legislation and to Mike Duffy’s mind that day, there must be an opportunity.

Building the Value Proposition for SOX Compliance Mike developed a small team to investigate Sarbanes Oxley. Within a month, he began to change the company strategy. OpenPages would modify its content management product to meet the information technology needs of the brand new Sarbanes Oxley legislation. The existing OpenPages content management platform had a lot of significant technology but lacked an important business problem to solve. It was software that stored publishing content, managed changes to the content, and published it to Web. Sarbanes Oxley compliance legislation provided the significant problem (value gap) that Open Pages needed. The CEO and CFO of our major corporations were interested in complying with the law and protecting the brand name of their company, that is, avoiding scandal. Section 302 of Sarbanes Oxley forced them to sign off on financial disclosures and have a way to validate that process. Further, Section 404 required outside auditors and the CEO to “attest” that adequate governance controls were in place. Complying with these sections required a document repository to maintain a governance control structure. This repository had to be updated easily and Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


provide a “compliance dashboard” for external auditors and members of the board to review risk and control structures. Further Section 302 signoffs were a good fit for workflow technology that would route documents for approval and keep an audit trail of signatures. But how do you take an advanced software platform that contained records management, content management and business process workflow and make it a compliance application? How do you build a value proposition against this problem? Running down the list, the business case did not really apply. This was a purchase driven by the law, much like fixing the year 2000 date problem. Companies were forced to have their key business risks and controls documented to have formal sign offs for publicly reported financial data. Management could go to jail if not implemented properly. Success for the product would not hinge on having a strong business case. The customer’s organization was examined to look for important changes in behavior. SOX created a major shift in power, roles, careers and tasks. It gave more power to internal auditors, the legal group, and the CFO. Internal auditors, who for years were relatively weak group organizationally, now had a dotted line to the board of directors. The OpenPages product would provide these departments with an important tool that would give them increased visibility into operations, and with it more control and status. From a professional standpoint, these departments had increased professional stature. OpenPages targeted the CFO’s and internal auditors’ needs. Recognizing that these target groups had a low level of computer literacy, OpenPages designed a product that was easy and intuitive to use. They consulted usability experts trained in HCI and human factors to help, and used an incremental product development approach, with HTML prototypes. The approach allowed the customer to help design the product and strong usability and usefulness resulted. The result was an application that could be used by financial executives and senior management with no time for training and low levels of computer literacy. The user interface and navigation was as intuitive as possible. They used color wherever possible and created personal home pages to provide information relevant to a specific user. They introduced concepts like “bread crumb trails” that allowed users to know where they were at all times. Children in fairy tales dropped breadcrumbs so Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

88 Le Clair

they could always get back home when walking in the woods. The OpenPages’ feature used arrows and other symbols on each Web page to show where the user had been during the session and allow them to easily return. They also used off-line behavior techniques described in Chapter Three. They designed their Section 302 survey process by looking at the CEO’s online and offline behavior, capturing the appropriate level of detail and the approval steps. But not to ignore IT, OpenPages architecture was compatible with many Fortune 500 environments. The platform used “best in class” technology including Oracle, BEA Application Server and Java. From an implementation standpoint, the product could be installed in weeks. This customer-focused variable was important since the major enterprise software companies would take months to modify their platforms to meet SOX compliance requirements. With a hard deadline for SOX, quick installation became a major plus. Assimilation was also easily achieved by providing the latest technology and a complete solution that extended to compliance frameworks beyond those required for SOX. They built bridges to existing systems through automated upload programs. These allowed existing sets of compliance documentation to be easily placed into the new compliance repository.

And Great Marketing Vice President of Marketing Peter Morgan joined OpenPages in January of 2003. He was a veteran of four start-up companies and he knew that the company was headed in the right direction, but needed momentum. He registered OpenPages with leading search engines, and entered into “click through” revenue agreements. These agreements charged a small fee when someone clicked on the OpenPages link. Since clicks equaled revenue for the search engines, they featured OpenPages prominently for any search involving compliance or Sarbanes Oxley. Within weeks, OpenPages was dead center in the exploding Sarbanes Oxley market for software and services. Web searchers looking for the latest information about compliance, were directed to a new OpenPages Web site that instead of describing a general technology platform now described a focused solution to an important business problem. At this writing, OpenPages is going through a second growth spurt. But this time growth is fueled by new customers and not by spending venture capital. At this



writing they had obtained their 70th corporate customer in less then twelve months of the product being on the market. Time will tell for OpenPages in this highly competitive market but focus on customer-focused variables like behavioral change, assimilation and implementation are paying off.

Web Services No concept since e-commerce has received as much attention as Web services. Spending is expected to increase at a compound annual rate between 2003 and 2008, reaching over $11 billion (IDC, 2004). Potentially, Web services to the B-to-B community will have the same effect as e-mail had on personal communication. It will allow businesses to communicate just as informally. What is new and different about Web services? Is it just another standard with lots of hype? Why will it work when initiatives like electronic data interchange (EDI) and others struggled? This chapter will not provide a complete treatment but focus on how this emerging standard can help with implementation issues discussed in the chapter.

Web Services Description Web services, like most successful standard efforts, combines established standards to create a potentially strong enabler. Figure 4.6 shows the main ingredients. Figure 4.6. Important components for web services Simple Object Access Protocol

Programmatic and Independent Interaction

XML

Description (exposure) of Available Service

TCP/IP

Internet Communication Infrastructure


90 Le Clair

On the left of Figure 4.6 are the primary Web services standards and on the right are the primary capabilities that each provide. The most important is the concept of independent programmatic access provided by the SOAP protocol, followed by the uniform descriptions of data using the XML standard. Underneath it all is the existing Internet infrastructure. Lets dig into each of these important parts.

Simple Object Access Protocol XML has been around for a few years, and TCP/IP and Internet infrastructure for decades. The breakthrough for Web services is neither of these, but the SOAP protocol. SOAP is a higher-level data communication protocol. Protocols have been around since the early airline reservation systems and are the language used for a software programs to communicate. They were so important for early data communications that the International Standards Organization (ISO) decided there would be seven layers and devised standards for each to allow programs and hardware from different vendors to interoperate. Without standard protocols there would be no Internet today. SOAP is just another protocol with one new twist. Standard protocols must be set up in advance to communicate with another program or device. SOAP goes one step further and allows communication among programs with no previous knowledge of each other. SOAP provides standard properties that allow for unplanned communication with other Web services.

Extended Markup Language (XML) XML is a simple standard that provides structure around previously unstructured information. Gramarical structure allows people to understand the quotation below easily. This is due to a standard structure for punctuation, spacing, and capitalization. The structure transforms a string of undecipherable letters to easily understood prose. For example: You cannot be, I know, nor do I wish to see you, an inactive spectator. We have too many high sounding words, and too few actions that correspond with them. -Abigail Adams Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


Take away this structure and you have the following: youcannotbeiknownordoiwishtoseeyouaninactivespectatorwehave toomanyhighsoundingwordsandtoofewactionsthatcorrespondwith them -abigailadams XML accomplishes the same task of punctuation, word spacing and capitalization by providing a standard structure around data. The structure allows software programs to understand and act upon data without change to the data or software program.

The Potential Web services will allow independent applications (businesses) to communicate with each other when they need to. Directories available through search engines will offer products and services that will be ordered by other Web services. Services will be provided and payments will be exchanged. In this vision of the future, a business will only require a small group of technical personnel to maintain the core application. In other words, Web services will be highly profitable to operate. Think of the possibilities from a consumer standpoint. Today, an individual conducting online business generally interacts with one application at a time. The ordering, pricing, and reference information is all contained in that one application. It is an island of information. With Web services, an application is able to send requests (server to server) behind the scenes, and then return consolidated results to the requesting application. In this way, a more complete transaction is available.

Back to Reality Critics of Web services point out differences between what is being said, the hype, and what is practiced in the industry, very little, and see Web Services having a narrow role in the near future. It will be used to communicate within a company or among partnering companies and will affect the area called


92 Le Clair

supply chain management (SCM). Within SCM a company will create a community for their supply chain to order items and manage logistics. But even these efforts will not be easy. Richard Lazarus, a senior scientist at BBN, has built Web services and says that, “Ubiquitous access with sufficiently defined ‘meta data’ such that the protocols and behaviors are self-describing is an unsubstantiated vision. There is significant software development to deploy a service” (Lazarus, 2003, interview). Richard has seen few case studies that match the hype in the industry. Others point out the difficulty of developing a business case. A forum on Web services has the following message: “Cost justifying projects to senior management is proving to be a difficult task as many IT managers struggle to find effective and consistent approaches to quantifying potential payback” (Computer World staff, 2002). Despite this difficulty, Web services are the best bet over the next several years to fill the integration gap described earlier, and will support the trend away from large enterprise software purchases towards more focused applications. Web services will help new focused products integrate more easily with customer systems and reduce the pressure on customers to buy enterprise software suites with a large set of pre-integrated components.

Web Services and Switching Costs Once a supplier’s technology is installed in a business’s IT infrastructure there are “switching costs” to remove it. These costs can be substantial for enterprise solutions. A simple document archive system, for example, will require retrieval of the documents in the old system and the reindexing of them into the new system. If there is too much history, the old system will be maintained for a period of time. But this requires a change to the new product coming in. It will have to switch between the new system and the old. This will require customized work by the incumbent vendor and the new supplier. Even with “standard” components such as a relational database and a standard document compression format, there will be proprietary aspects of the system. The database “schema” may be specific to the customer. The user view and navigation through the system may be unique. And the software conversion is only part of the switching costs. Hardware will be replaced. New, third-party software licenses will be needed. There are



behavioral change costs highlighted earlier. It is easy to have a large project even for a small of system replaced. Suppliers use these switching costs to “lock in” customers. In fact, an enterprise software company’s value is in part determined by the “stickiness” of their solution. Investors want to know how much does it stick and how difficult is it to get unstuck? The higher the switching costs the more value attributed to that vendors installed base (Shapiro & Varian, 1999).

Switching Costs and Web Services Several trends will make switching costs an important topic for customers. For one, Web services will provide customers with lower switching costs and clearer strategies for conversion. Secondly, the high number of technology company failures has made companies wary of small-company solutions with high switching costs. The emerging company can proactively counter this objection by developing a strong and verifiable “switching” strategy. And thirdly, switching costs will remain but decline over time. This means the incumbent solutions will compete with emerging solutions on a more even playing field.

Summary The implementation history of the last decade has provided us with a wealth of experience. The most important lesson from this period is to view implementation from the customer’s viewpoint. Only by doing this, will be able to adjust our approach for success. We need only to capture this history and put it into a workable guideline. To assess how difficult your solution is to implement, evaluate:

Service-to-License Ratio What is the cost to implement your solution, compared to the cost of the software? Will the customer have to purchase professional services from you or another consulting firm to implement the solution?


94 Le Clair

Product Adaption Strategy Customers buying enterprise software almost always have “process technology” gaps. Have you identified the process technology gaps in your product? What is your product adaption strategy to deal with these? Will you customize your product for the client? Do customers believe you have captured “best practice” for their business processes? What is the product strategy for vertical market applications?

Sales Cycle How many people do you have to meet with to introduce, explain, and convince them that your company’s solution will work? Is your typical sales cycle three to six months or nine to 18? How can we shorten the cycle by making the product more compatible with the customer environment?

Number of Departments Involved How many departments must implement the solution for it to be effective? Is the number of departments high enough that the eventual purchase decision must be made the president, CEO or other company officer?

Switching Costs What are the switching costs for your solution? Do you have an answer to that question for your customer? What actions have you taken to reduce switching costs and make the customer comfortable that they are not locked in?

Training What is your training philosophy? Does your professional services and training staff understand the complete business process surrounding your product? Does your training focus on the users online and off-line behavior?



References Borland SEC Filing #0-16096. From Borland Software Corporation 10Q for period ended September 30, 2002. p. 24. Fontanella, J. (1999). The issue: Your supply chain execution systems can’t support e-business. AMR Report, 1-10. Augustson, A. (2002). ERP solutions (and other contradictions of terms). Paper written by PhD student at the University of Chicago, Harris School. Songini, L. (2002, February 11). GM locomotive unit puts ERP rollout back on track. Computer World, News Story Quicklink #27053. Songini, L. (2002, February 1). Teddy bear maker prepares for second attempt at ERP rollout. Computer World, News Story Quicklink #26956. Wladawsky-Berger, & Wladawsky-Berger, I. (2003, May 4). The term “post technology era” was first used. New York Times, business section, p. 1. Stedman, C. Computer World Story. (1999). Failed ERP gamble haunts Hershey. Computer World, November 1. Shepard, J. (1999). AMR Research. Comments on Hershey. Quoted in Computer World Stody Stedman, C. (1999). Failed ERP gamble haunts Hershey. Osterland, A. (2000). Blaming ERP. CFO Magazine, January. Burke, D., & Morrison, A. (2001). Business @ the speed of stupid: Building smarter companies after the technology shakeout. Cambridge, MA: Perseus Publishing. Rogers, E. M. (1995). Diffusion of innovations (4th edition). New York: The Free Press. Cotteleer, M., & Frei, F. (2002). Enterprise-level packaged software adaptation: An empirical study of firm-initiated and vendor-initiated strategies. Draft working paper. Cambridge, MA: Harvard Business School. Gartner Group. (2003, February). Select CRM applications carefully to get maximum benefits. Survey. Stamford, CT: Garnet, Inc. Siebel, T. (2001). Taking care of e-business. New York: Doubleday. Le Clair, J. (2003). Interview with Janet Le Clair, Senior Vice President and Operations Executive, on August 12, 2003. SVP Wachovia Bank.


96 Le Clair

Davis, C. (2004). Enterprise integration in business education: Reflections on a capstone ERP-based undergraduate e-business management course. Saint John: New Brunswick: University of New Brunswick. Wheatley, M. (2000). ERP training stinks. CIO Magazine, June 1. Duffy M. (2004, January 20). [Personal interview with OpenPages CEO Michael Duffy]. IDC. (2004). Cautious Web services software adoption continues: IDC expects spending to reach 11 billion by 2008. June 1, 2004, p. 1. IDC, Framinghan, MA. Lazarus, R. (2003, August 15). [Personal interview with Richard Lazarus of BBN Technologies]. Hoffman, T., Computer World staff. (2002, October 20). Web services ROI remains tough to prove. Computer World, 36(44), QuickLink #33929. Shapiro, C., & Varian, H. (1999). Information rules: A strategic guide to the network economy. Boston: Harvard Business School press.



Appendix A: Service and License Revenue Data for Major Software Vendors Siebol

Oracle

PeopleSoft

Year

*License Services S/L Ratio

80 20 0.25

156 50 0.32

290 118 0.41

499 291 0.58

1114 705 0.63

1065 1018 0.96

700 934 1.33

License Services S/L Ratio

2296 1926 0.84

2896 2787 0.96

3193 3950 1.24

3688 5138 1.39

4446 5683 1.28

4706 6152 1.31

3513 6160 1.75

License Services S/L Ratio

294 219 0.74

509 422 0.83

664 810 1.22

339 1061 3.13

496 1153 2.32

645 1370 2.12

530 1411 2.66

96'

97'

98'

99'

00'

01'

02

* In millions


98 Le Clair

Chapter V

Customer Core Competency

“Any sufficiently advanced bug is indistinguishable from a feature.” Kulawiec Corporations that need technology must make a decision. They can solve the problem themselves or purchase an outside product or service. Their core capabilities influence this decision and affect the value of the supplier’s product. It is probably difficult to sell ice to Eskimos. It is always hard to sell anything to someone who already has what you have, or can make it inexpensively. Despite this, many enterprise software companies depend on being successful in this manner. This chapter emphasizes the need to look at how the emerging company’s core competency lines up with that of the customer. Of little concern for providing an e-commerce service to a consumer, it becomes critical when providing a technology-based solution to another business, and therefore for enterprise software. The reason is simple. When the emerging company asks another business to buy their technology rather than to develop it from within, they are asking that



99

customer to make a strategic decision. The “build versus buy” decision is strategic since it may alter their business opportunities in the future and affect their competitiveness. This is growing in importance due to the temptation for large buyers of technology to become technology providers themselves. Here are a few examples: •

•

• •

•

American Airlines gained market advantages through its Sabre subsidiary. At different points in time, Sabre was making more profit providing tickets to the industry than the airline was flying planes. The planes became mostly for show. Fidelity Investments has attempted numerous technology business ventures including specialized data communications equipment, a workflow business and various record-keeping platforms for other investment managers. Merrill Lynch for years offered its print and mail solutions to other brokerage companies. Amazon is attempting to open up their e-commerce platform to other online stores and enter the enterprise software business. Had Amazon.com outsourced their e-commerce engine, they would not have this opportunity. General Motors once owned EDS and has several technology subsidiaries.

Competing with Your Customers The problem is that the software companies target customers who may become competitors. Companies that market their solution to “split-personality” customers like those above, may end up educating the much larger company on their intellectual property. And even if they buy your product, the competing core competency dilutes your value. The closer to the customer’s core competency, the easier they can build your solution themselves. They will build it themselves if they have the infrastructure, skills, and the domain expertise. The emerging company should look first at customers who


100 Le Clair

have no strategic interest or core capability in their area of competence. These companies will pay more and be better prospects. In the following cases you will probably not get top dollar for your product: •

•

•

It will be difficult to sell your outsource solution to an outsourcing company because their core competency is managing technology for others. It will be difficult to sell your CRM system to a consumer marketing company, since building databases about customers and providing intelligent uses of those data are their lifeblood. It is difficult for a content provider to agree to distribute your externally sourced content.

Flying Too Close to the Sun All things being equal, the further the emerging company’s solution is from the customer’s core competency the better, as seen in Figure 5.1. It shows the three options a customer has when evaluating an external solution: •

•

•

If the external solution is dead center to their core competency, the company will likely make the “build” decision. They can implement your solution as easily as you did. The second ring is the “build versus buy” zone. The emerging company is in a weakened position when they find themselves here. In this zone they will confront a serious build versus buy analysis. This analysis can go on for months and be very political. This zone will put the emerging company in the uncomfortable position of having to reveal intellectual property to the potential customers who may turn around and build the solution themselves. Ouch! The strongest position for the emerging company is the outer ring, where the company has made the clear decision that it must look externally for the solution.



101

Figure 5.1. Flying too close to the sun Customer Core Competency (Domain Expertise, Technical Capability, Strategic Interest)

Customer Likely to Conduct a Build versus Buy Analysis (Prepare for a Battle) Customer Likely to Build in House (Avoid) Customer Likely to Buy from an Outside Supplier (Great Target) Value of Supplier’s Solution

Controlling Intellectual Property As discussed, technology will assimilate into the customer environment. Success will require a team effort that will blend the supplier’s technology with the domain expertise and operational knowledge of the customer. It is a fusion of Intellectual property and the result of the joint effort often has value to the industry. The emerging company wants to exploit that value as fast as possible. Before the ink dries on the contract, they will know what the fusion implies. They will plan to penetrate other like customers and build a vertical or applicationspecific strategy. The issue facing the customer concerns controlling the intellectual property and not limiting future growth options. They have no incentive to share the joint IP with their competitors. The project may develop new ways of operating and it may provide a competitive edge that they would like to keep to themselves.


102 Le Clair

Keeping Options Open Customers are doing more than just buying an outside product or service when they sign the supplier’s contract. They will limit their own ability to develop expertise and capability in that technology area. They are handing that opportunity to the supplier that will own the software and all enhancements. That supplier will sell it to the rest of the industry including the company’s worst competitor. The closer the needed technology is to the customer’s core competency, the more difficult it is to buy it from the outside. Internal resistance to the outside product increases the closer that solution “flies to the sun”, that is, how close the solution gets to the center of the potential customers’ skill sets, domain knowledge and intellectual property of Figure 5.1.

Case Study: Application Service Provider (ASP) Applications Of all the new markets spawned during the Internet boom, perhaps none rose so fast yet failed so quickly as that of renting enterprise software. Over 1,000 self-proclaimed application service providers, or ASPs, were launched during 1999 and 2000, with venture capitalists betting more than $1 billion on the foolproof but unproven business model (Verity, 2003). Within two years, the great majority of those start-ups fell victim to their own hype, leaving investors in shock and the ASP model widely repudiated as an inherent loser. In many minds, the term ASP came to mean “a stupid proposition”. The ASP idea was compelling and the “surface” value proposition looked sound. Businesses could not afford large enterprise software licenses. With the ASP model, they would simply rent these applications for a monthly fee. Web technology would allow this new remote and inexpensive access. ASP customers would avoid hardware, support staffs, but more importantly get the application up and running fast. As described, companies were struggling to get applications like SAP, PeopleSoft and others implemented before retirement of key staff. These firms would benefit from shorter implementations. They would leverage the pooled resources of the ASP, who would create easily tailored templates for fast implementation.



103

The Most Successful ASP The concept of outsourcing a business process is far from new. The only difference between traditional business outsourcers and the new ASP was that the later rented off-the-shelf software platforms. Traditional business outsourcers built proprietary systems. Perhaps the most successful ASP is Automated Data Processing. ADP has outsourced payroll applications for more than 50 years and they are now a $7 billion business. With a core competency in accounting, they focused on the pain corporations felt calculating payroll and meeting new record-keeping requirements. In addition, corporations that spanned many states had to deal with different and changing state tax regulations. Today ADP pays approximately 30 million people worldwide each payday and issues more than 43 million year-end tax statements in North America. ADP’s payroll application is arguably the most successful outsourced application in history. It was the first “killer app” based on the ASP model. In addition, their brokerage division dominates the market for outsourced brokerage services handling approximately 25% of all trades cleared on the New York Stock Exchange (ADP Web site, www.adp.com, 2003).

Clash of Core Competency There are many reasons for the slow development to this point of the ASP model. One reason was that emerging ASP solutions had conflicts with established IT organizations. An ASP solution had to convince a professional IT organization, whose competency is running and hosting software applications, that they could do it better and cheaper. Many of these customers already had large operational IT infrastructures. The business side of a customer would be the ultimate decision maker, as in any outsource solution, but the IT department was a key stakeholder and a difficult hurdle to overcome particularly when the application being hosted was generally available. One example of this can be seen with a firm that provided microfilm and traditional records management solutions. In 1999 they purchased, a leading document management company that had a high-volume document manage-


104 Le Clair

ment solution. At the time of their purchase there principle business consisted of microfilm archival equipment and services. A great deal of business information is archived for long-term storage on microfilm. Their products took information directly from mainframe files and moved them to microfilm. It was cheap, legal, and permanent and they grew to a very large business. Unfortunately by 1999, microfilm was migrating quickly to computer storage that allowed rapid and higher-quality retrieval. Anyone who has ever searched microfilm needs no explanation of the advantages offered by digital storage and access. They purchased the document management company to build a next-generation records strange capability. They would migrate customers from microfilm storage to digital storage and in the process they would enter the fast-moving application service provider (ASP) market. With declining microfilm revenues, and strong analyst estimates of ASP market potential, they built a dedicated data center to host the application. This was to become an industry utility on a vast scale to store business information electronically and provide access over the Web. In March of 2000, a major financial institution visited the new data center for due diligence. They were headed by their SVP of operations, an ex-Marine and a 20-year veteran of the company. The visiting financial services firm was one of the most respected IT organizations on Wall Street. On any given day they had billions of dollars changing hands on their systems. Their IT security operations assumed malicious intent, that is, that a hacker was trying to break in and worse, that at any point in time, small teams of sophisticated professionals were planning to compromise their systems. As a result, their security was among the most sophisticated in the world. The firm was looking at outsourcing an e-mail management solution to store the 20 terabytes of e-mail they generated annually. And while they preferred that no one ever look at this information, the Securities and Exchange Commission had passed a law that licensed security brokers must keep e-mail records. It was not a strategic application and therefore a candidate for an ASP solution. The company had the new ASP facility operational when the firm visited for due diligence. The senior staff from operations and software development were interrogated on physical, data, and application security, operational procedures, hiring practices including procedures for archive of employee back-



105

ground checks. The meeting ran out of time before getting anywhere close to discussing the application. The firm was polite and professional in their assessment, but was unimpressed. Their operation was far more sophisticated, mature, and tailored to their stringent security and operational requirements. This meeting points to challenges with the initial ASP’s value proposition. Sophisticated firms represented the target market for many ASP solutions at the time. Yet there was a strong clash of core competencies. Many high-end customers were better-equipped and more expert in running applications. And in this case, the potential customer had invested millions in meeting special requirements of the financial services industry. They would be hard pressed to see a lot of value in an independent company running an application on their behalf. ASPs are now targeting less sophisticated IT organizations. They have less infrastructure expertise and are less likely to have the skills needed to host enterprise software applications.

Summary To assess how your solution relates to your customer’s core competency, evaluate: • • • •

What companies are your primary targets? What do these companies sell? What are the traditional strengths these companies offer their customers? Do they have the expertise to build your application in-house?

References ADP Web Site. (2003). Company background. Retrieved November 24, 2003: www.adp.com Verity, J. (2003). Down but not out: There may be a second act for ASPs. CFO Magazine, Summer.


106 Le Clair

Chapter VI

The Customer-Focused Business Case

“You can see the computer age everywhere but in productivity statistics.” Robert Solow, 1987 Nobel Laureate This chapter first describes challenges that software companies face in making a strong business case to prospective customers. These include a history of solutions falling short of projected business case expectations, the customer’s unique perspective of costs and the difficult issue of technology adoption. Secondly, a process for building the software company’s business case in the new era is discussed. The process uses strategic frameworks to estimate and validate strategic objectives. Lastly, we look at a case study of e-docs that developed a unique way to manage unpredictable technology adoption.

Productivity Trends In 1965, Intel Corporation co-founder Gordon Moore predicted that the number of transistors that could be placed onto a microchip would double at a regular interval. Since this claim, the number has doubled between 18 and 24


The Customer-Focused Business Case 107

months and has helped provide the tremendous performance improvements we have all benefited from. Moore’s prediction, like many in the IT profession, came from painstaking research. Gordon enjoyed deep-sea fishing, and early in 1965, he was doing just that. He wondered about the fact that over the last year he was able to get a couple more transistors on each chip. And he thought, “Hmm, I wonder how often these things are actually going to double in terms of the number of transistors I can get on the chip?” And he thought, “I know – however many fish I catch today, that’s how many months it’s going to be.” He got 18 fish, and 18 months became the number (Intel Developers Conference, 1997).

Typing Pools and the Imaginary X Let’s step back and look at what a business case really is. Largely it is about reducing people. One of the disturbing aspects of a new technology implementation is the day you do the “walk through” of the customer environment. It has the feeling of a victory lap as the winning supplier performs a detailed review of the customer’s operations. As you walk past the sea of cubicles in the different departments you know which employees will be gone in six months time. Those 20 microfilm clerks will vanish, as data will be available from everyone’s computer. Eliminating paper will reduce one out of every three administrative staff and one in four call center operators will go since the new system will increase accuracy of data sent to customers and reduce call volumes. Walking through shop after shop you can quickly draw imaginary X’s on select foreheads. Productivity improvements like these are not new. My grandmother worked for Thomas Edison in East Orange, New Jersey, where he had created the first organized corporate-research department for product development. This was in 1876. I’d like to say my grandmother was an MIT graduate signing over patents to Thomas Edison but she was a mere member of the central typing pool, where typists (almost always women working at low wages) operated with the latest typewriter technology. These centralized typing pools lasted for decades but were gradually replaced by word processing systems. In the same way our technology continues to eliminate repetitive tasks by: •

Capturing data in computer form at the beginning of a process to reduce data entry tasks from paper.


108 Le Clair

•

• •

Providing Web-based customer self-service applications that siphon off routine questions and tasks formerly handled by telephone calls. This leaves more sophisticated problems to a smaller number of staff. Eliminating copy, filing and retrieval tasks with document management and workflow technology. Moving processing tasks offshore using business process management.

Jobless Recovery Technology, in this manner, is contributing to the “job1ess recovery” which is now a term we are all familiar with. It means we are able to increase our output without adding people, or at least adding people in this country. And we are only at the beginning. Eliminating repetitive tasks like those above will build healthy business cases for technology providers for the next several years. The entire IT industry could just focus on healthcare and be busy for a long time. In the U.S., it takes 3.6 million administrators to handle payments and other processing tasks to support our medical system. There are more administrators today than doctors and nurses combined. The Duke University Medial Center has more than 1000 staff in their bill payment department alone (ABC staff, 2004). But are positive business cases from fewer people sustainable? In the future departmental budgets will need to show recurring productivity and this will come from intangible benefits. The strong product will affect the enterprise’s immediate operating costs but also will have a permanent effect on the income statement. To accomplish this, enterprise software will need to apply hard savings to intangible pockets of value. This chapter helps us prepare to do that.

Business Case Challenges Customers make technology-spending decisions based on a business case. That is, a customer will consider your product when it has an obvious return on investment (ROI) – that is, it is doing something that is important for them better and cheaper. It is therefore important to have strong and demonstrable business case for your product. However, it has become harder to convince customers your business case is real for the following reasons: Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


A. B. C.

There’s a history of unrealized cost savings. The customer has a unique and understated view of costs. The future adoption of technology is difficult to factor into the business case.

A: A History of Unrealized Cost Savings Increasingly, CEOs push CIOs to prove how IT investments increase shareholder value. If they ca not make the case, budgets do not get approved. This additional scrutiny is due to disappointing project returns over the last three decades. Customers have invested millions in enterprise resource planning (ERP), millions more in customer relationship management (CRM) and many other initiatives that have not lived up to their business case claims.

First, the Monolithic Mainframes In the 1970s and 1980s, IBM dominated the high-end of the computer hardware market with their highly proprietary mainframe architecture. As a result, IBM maintained very high prices for all components to its systems. They were so dominant that the government sued them for a good part of the 1980s for violating antitrust laws. Microsoft gained ownership of the disk operating system (DOS) from IBM in part due to concern over the government’s antitrust litigation. Unfortunately, the mainframes of this era required large staffs of specialized experts to maintain. Users could only access them by “dumb terminals” that also were controlled from the mainframe. New applications or enhancements were usually more expensive then anticipated, but customers had little choice.

Second, The Fat Clients In the early 1990s, the monoliths were ridiculed for inflexibility and expense and IBM was on the ropes. They had cash concerns and considered breaking up


110 Le Clair

the company (Gerstner, 2002). Client/server products were hitting the market and offered “drag and drop” features, at what appeared to be very low price points to eager customers. With the client/server model, the intelligence of the mainframe was now split between the server host system and multiple personal computers (PCs) connected to the server. The client/server system created what became disparagingly known as “fat clients”. Criticism of the “dumb terminal” was now replaced with outrage over these “fat clients”. Initially, the client/server architecture was a great improvement over the mainframe because more tasks were put directly in the hands of the users. However, the decentralized maintenance and replacement cycle of thousands of PCs turned out to be difficult and expensive. At that time, the analysts estimated the total cost of managing a single PC was more than $13,000 per year (The Gartner Group, 1995). What appeared to be a lowercost approach in the end merely shifted costs around.

Third, The Thin Clients The expense of the client/server system opened the door for the next great promise, Web-based products. The “thin clients” promised to solve many of the problems with the client/server architecture. Unfortunately, Web applications for business proved expensive to build in a scalable, fault-tolerant, and secure manner.

Fourth, The Enterprise Software Application At about this time companies started to invest in ERP, CRM and data warehousing enterprise software applications. These proved to have disappointing ROIs. In September of 2002, Nuclear Research, a consulting firm, conducted a CRM study that found that 61% of Siebel customers listed on the company’s Web site did not receive a positive return on investment (Wall Street and Technology staff, 2003). In the end most projects fell short of the projected benefits. Another 2002 study showed that companies that bought CRM software had poor results. The list below points to problems in four of the five customer-focus areas (Sodano, Keltz & Johnson, 2003):



• •

•

•

12% of projects fail to ever be implemented, usually for technical reasons (implementation and assimilation). 47% of projects have major end-user adoption problems, even though the projects were successful from an implementation standpoint (behavioral change). 25% of projects meet technical and user standards, but have not proven value. Either they are “only as good” as the replaced system or the benefits are difficult to define or measure (assimilation). Only 16% of projects show real ROI (business case).

From monolithic mainframes to client/server, thin clients, and enterprise software, history shows that features and usability improve but costs do not go down as much as anticipated. This history makes the business case more difficult for the emerging company to define, and even more difficult for an experienced IT manager to believe.

B: The Customer’s Unique Perspective The customer’s view of the business case is very different than the suppliers. They see costs and benefits differently. We can benefit from understanding this view, which is a product of the legacy systems that surround them and their unique organizational and accounting perspectives.

The Trolls Guarding the Existing Systems It often seems that legacy systems grow trolls that lurk at their core to fight off attempts at replacement. The older the system, the stronger and meaner the trolls become. The IT, operations, and business owners of the legacy system have vested interests and intellectual ownership and will nurture the trolls. Their value to the company correlates heavily, perhaps exclusively, with that system. They make sure the trolls are fed and derive great pleasure from protecting them. Common troll protection techniques are to understate the true costs of the system, to make access to the system difficult, or to maintain minimal or poor documentation.


112 Le Clair

In cahoots with the trolls are often the emerging companies themselves. They frequently overstate the value of the new solution and understate the value of intellectual property in the legacy system. The legacy system has software that has evolved over a number of years. It is tailored to a company’s specific business problem. This explains why so many IBM mainframe systems with software written in COBOL still exist and to this day, run the most important systems on the planet. The mainframe applications may run on inflexible and outdated architectures, but they meet business requirements. As the new solution is brought in, it will be in catch-up mode, perhaps for years. So while it may embody the right vision, the new system will be less efficient and more costly than initially estimated. In many cases, it will run in parallel with the old one for some time. This will dampen the forecasted savings in the initial phase of the project where the company investment is the highest.

Killing the Old Systems In short it is very hard to kill the old system. One of the problems affecting the business case for e-commerce is the inability of the Web to reduce the costs of other customer channels. Commercial banking is perhaps the most dramatic example. Electronic banking was supposed to reduce automated teller machines (ATMs), telephone banking and tellers. But instead, electronic banking just made things harder. It created another customer channel for banks to manage and to this point has caused little reduction in ATMs, telephone services or tellers.

Understand the Customer’s View of Costs To make matters worse, the customer’s view of costs is often based on unique, company accounting. For example, an emerging company may have an excellent business case based on replacing paper. But the customer may own the printing equipment already and could view the investment in this equipment as “sunk costs”. They may ignore the building that houses the equipment. The labor for the current system may be allocated to a different budget and considered free. These rules make the emerging company’s business case difficult particularly if they do not understand what the rules are. Too often we



make assumptions about the customers costs that may influence our pricing strategy. Often we do this without asking the customer what the rules are.

Take a Complete View of Costs One thing that can help is to take a more complete view of costs. The enterprise software supplier often views the cost to the customer as their license price and any professional services required to make it work. Sadly, these costs are only the tip of the iceberg. The total costs are likely to be many times that amount and include “change management”, internal technical and business resources, and purchase of hardware and software. Chapter Four provided a framework to better understand cost from a complete perspective.

The Stovepipe Problem The stovepipe is a metaphor to explain communications and interaction among departments in larger companies. The stovepipe, being a strong, singlepurpose and stand-alone item, implies there is none. Many strong companies organize by individual business units that are managed as profit centers. As a result of this structure, departments operate independently and do not share information, that is, they are stovepipes. The relevance to the business case is that while one company will acquire and own the project, often costs and benefits are spread across many. As a result, companies may not include cost savings from other departments in their internal business case, even though they may be substantial. What causes this? For one, departments do not want to point out or gather data on inefficiencies of other departments. And that department head, perhaps a rival, may be unwilling to provide the data. A fair view of the “ business case” is thus hemmed in by these line-of-business boundaries. We will use emerging strategic frameworks to help overcome the stovepipe problem. Process improvement tools such as Six Sigma have helped this problem. Six Sigma assigns “black belts” that are independent and take a cross-departmental view to improve operations and lower defect rates. Unfortunately, the vast majority of companies still revert to a “stovepipe” view for new technology projects.


114 Le Clair

C: Behaviorally-Dependent Business Cases Many technology projects require user adoption to realize projected savings. With a business case dependent on adoption, there may be little savings on the first day of the new system. Savings will occur only after “behavior” changes over a period of time. This makes the business case uncertain, and will create a difficult pricing challenge for the software supplier. Lets look at how one company managed this dependency.

Edocs and Customer Self-Service Founded in 1997, edocs employs more than 200 staff and is focused on the online self-service and electronic bill presentment and payment (EBPP)/ market. Edocs knew why customers called contact centers and developed a solution that enables customer to do those same things online instead. The edoc’s solution gives customers control over all their account-related tasks. They can find information and execute transactions via the Web or telephone. Previously, many of these tasks had to be handled by a person in a call center, retail outlet or other channel. The company started by offering e-billing and payment and these still make up the most common self-service activities customers use. But since then, edocs has added a variety of other self-service capabilities including account management, order management, analytics and natural language search.

Road Rage and E-Billing The traffic in the Los Angeles area gets some credit for giving Kevin Laracey the vision for edocs. With a one year old at home, life was hectic for Kevin and his wife, Stephanie. She worked for Symantec, Inc., and spent hours commuting and working from her car. Her cell phone bills were more than $500 a month. Each month, Stephanie spent hours sorting business from personal calls. She used a calculator and a yellow marker. Kevin understood more about bills then he cared to admit. He could look at one and tell by the fonts what type of device it was printed on. Whether it was Xerox



or IBM printer and what model. He could tell the software used for composing the bill. With this background, he also knew that the billing data were easily accessible and that someday these billing data would be available to a customer over the Web. Simply hitting a button could do the task Stephanie struggled with. It would take a second. These thoughts combined with his experience led to the founding of edocs. Prior to edocs, Kevin was vice president of marketing at Elixir Technologies. Elixir developed software for form design, personalized document composition, data extraction and print stream conversion. These were important technologies for converting legacy bills to the Web. And they gave Kevin the perfect background for the emerging bill presentment and payment market.

Creative Pricing Models: Following the Technology Adoption Curve Edocs bet strongly on behavioral change. They described themselves in their March 24, 2000, S-1 statement, as follows: We develop market and support a leading software platform for Internet billing and customer management. Our solution enables companies to utilize the Internet to transform the traditional paper-based bill and statement delivery process into the foundation of an online customer account management strategy (Edocs S-1 SEC Filing, 2000, p. 2). On the surface, edocs had a killer business case. They saved between $1 and $2 for each bill that did not have to be mailed. Success would require only that consumers received and paid bills over the Internet. Consumers would just have to change their behavior. But would they and how fast? Edocs decided to share the risk of adoption with their customers by selling a software license. Selling a software license is a one-time event. The customer pays for perpetual use of the software. Each year firms that sell software licenses must replace the majority of their revenue with new sales. License sales can lead to very fast growth but is hard to do consistently. To avoid this difficulty, edocs could have priced on a transaction basis. For example, they could have received a quarter for every bill paid online. This approach had the advantage of being recurring revenue. Every month the dollars come in like an annuity. Even better, high rates of Web bill viewing and payment would make transaction pricing lucrative.


116 Le Clair

But low rates of adoption would be disastrous for edocs. It would also be bad for customers because they would get less value from the technology and this is what happened. The initial adoption rates for online account management were disappointing. This made edocs’ early decision to sell software licenses sound. Today, adoption is growing. According to edocs, adoption of e-billing and payment is on the rise, and 20% to 25% of all major credit card and telephone company customers now manage their accounts online. With this trend, edocs is moving towards a “managed solution” offering. In this case, the online account management software is run at an edocs data center. While this is not transaction-based, it charges a recurring monthly management fee. Upfront costs for the biller are avoided as well. By moving from a licensed product to a managed solution, edocs followed the technology adoption curve. It reduced the dependence on behavioral change. And is prepared to do well. At this writing, edocs has had six consecutive years of revenue growth. It continues to deliver customer self-service and e-billing solutions to many of the world’s leading companies. Edocs continues to broaden its offerings with more customer self-service options, further reducing the dependency on consumer viewing and paying their bills online. This enables edocs customers to increase revenue and decrease customer service costs, and makes edocs less dependent on the elimination of paper bills for its business case. In fact, today, the number one benefit edocs customers trumpet is operating efficiencies from reduced customer service calls. The company will deepen its vertical market expertise in telecommunications, financial services and healthcare insurance. They are a strong choice for enterprises that surround their e-billing and e-payment functions with crosssales and online customer service. On January 14, 2005, Siebel Systems, Inc., announced the acquisition of Edocs. The combination of the leading CRM supplier with edoc’s customer self service applications will be a strong force in enterprise software for years to come.

Find the Curve and Adapt Enterprise software companies can mitigate the risk of adoption in just this way. Pricing models can simultaneously create the highest ROI possible for the customer and minimize the dependence of user acceptance. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


Building the Business Case The new era has replaced the emerging company’s ability to sell a vision with the harsh reality of selling a productive solution. The goal of the following business case approach is to help with this challenge. Figure 6.1 shows a highlevel view of important steps to accomplish this.

A: Build the Business Process Model Most business case models start with a spreadsheet, but this should be the last step. Put Excel away and start with a model of the business process. This does two important things. It creates a perspective similar to the customers and helps us understanding the customer’s environment. To understand the maximum benefits possible from a new system, it is important to learn about the people using the system. New solutions will alter their roles, tasks, and relations with other departments. It may restructure, eliminate, or replace a business process. The business case you identify will come from these changes. It helps to create a business process model based on use-case or workflow diagrams. These should define the human-machine interfaces and generate a Figure 6.1. Building the business case A. Build the Business Process Model B. Identify Strategic Goals and Objectives C. Apply Performance Metrics

D. Apply Financials for proforma Business Case E. Monitor and Improve


118 Le Clair

common understanding of the customers “ecology” as described in Chapter Two. The model should detail how business processes will change and what effect those changes have on the customer. Without this due diligence no adequate business case can be understood or articulated.

B: Identify Strategic Goals Using Performance and Risk Management Models The strategic framework is applied once the business process model is complete. There is a growing number of governance; risk management and performance frameworks and many of these can make the business case more concrete. The trend towards stronger governance of public companies and their critical systems has created tremendous interest in these frameworks, and it is likely your customer is being trained in how to think in these more strategic ways. Strategic frameworks encourage enterprises to look beyond traditional financial metrics to understand performance, that is, to look at more strategic and intangible contributions to the company’s success. These include productivity from better training, increased product innovation from investment in technology, or enhanced competitiveness from investment in market research. The standard ROI-based business case does not measure progress for these intangibles well. Kaplan and Norton, originators of the Balanced Scorecard, make this point as they reflect on their decade of work in their 2004 book Strategy Maps, converting intangible assets into tangible outcomes. “We believed at the time, that knowledge-based assets – primarily employees and information technology – were becoming increasingly important for companies competitive success. But companies’ primary measurement systems remained the financial accounting system, which treated investment in employee capabilities, databases, information systems, customer relationships, quality, responsive processes and innovative products and services as expenses in the period in which they were incurred.” (Kaplan & Norton, 1994, p. IV)



Strategic frameworks are important for the software product’s business case because much of the value of software comes from these strategic and intangible areas. Business cases can benefit by augmenting the typical financial ROI with a more strategic approach that captures the benefit of investment in intangibles. Simply put, the vendor’s business case can be improved with a firm grounding in strategic goals that can then be aligned with performance-metrics and ultimately cost savings.

Framework Overload Looking at these frameworks, it is easy to get overwhelmed. They often seem abstract, too strategic, and just plain too much work. Figure 6.2 lists the basic structure of four strategic frameworks. Six Sigma is associated with performance management. BSC is used for strategy development, while COSO’s risk-management framework is being used increasingly to manage financial risk. CobiT’s focus is IT governance. Figure 6.2 makes the case that these frameworks reduce to three basic elements: goals, measurement and improvement. A summary of leading strategic frameworks is included in Appendix 1. Applying any of these structures to a business case need not be overwhelming. Lets look at how the Balanced Scorecard can be applied (Kaplan & Norton, 1992). This is shown in Figure 6.3, which starts with the customer’s business strategy, “to provide of the best overall service in the industry”.

Improve

Measure

Goal

Figure 6.2. Similarities of strategic frameworks SIX Sigma (8)

BSC

COSO

CobiT

Project Goals

Vision

Objective

Objective

Defects

Participation

Events

Control

Analyze

Metrics

Risk

Information

Improve

Credibility

Control

Control

Commitment

Communication

Execution

Monitoring

Performance Management

Risk Management

Monitoring

IT Governance


120 Le Clair

From the company strategy, Figure 6.3 then breaks this down to an operational strategy and then to specific objectives. The objectives are to improve customer responsiveness, employee morale, and brand recognition. These become the heart of the business case, for if they are met, then the business case will be achieved. Key performance indicators (KPI) are determined for each objective and are used to monitor performance against these goals. The next section provides guidance on performance measurement.

C: Apply Performance Metrics As shown in Figure 6.3, performance goals are mapped to objectives. In the past, enterprise software projects could be approved on a strategic vision with a secondary emphasis on performance. Today, it is important to quantify hard (operational) and soft (strategic) objectives. Since they are so important, lets drill down into these two different types of objectives. Strategic objectives tend to be qualitative and it is easy to conclude they cannot be quantified. Unfortunately with this approach the customer will ignore them. One value of strategic frameworks is the ability to make these strategic, soft objectives quantifiable and actionable. As shown in Figure 6.3, these include improved customer service, employee morale and improved brand recognition.

Figure 6.3. Using the balace scorecard to develop a business case Business Strategy Provide Highest Level of Customer Service in Industry

Objective A Improve Customer Responsiveness

Operational Strategy Improve all Customer Contact Points

Objective B Improve Employee Turnover

Objective C Improve Brand Recognition

Performance Goal: Objective A Performance Goal: Objective A

Performance Goal: Objective B Performance Goal: Objective B

Performance Goal: Objective C Performance Goal: Objective C



Unless these are made concrete the purchasing company will understate your business case. A good way to think about the problem is with the pyramid in Figure 6.4. At the top are the “hard cost” objectives of the business case, which may include reduction of paper expenses and cost saving from staff reductions. But as you look deeper, you see that the underlying strategic benefits of the new system, the lower part of 6.4, dwarf the operational savings by a factor of five. In Figure 6.4, the strategic savings are far greater than the hard-budgeted items. This notion was validated by a Gartner Group (2002) report on information infrastructure investment that said, “Although hard measures may gain initial management support, the strategic benefits represent the true payoff of infrastructure investments in business terms”. The Gartner Group has hundreds of Fortune 1000 clients and is routinely consulted on a wide variety of IT investments.

Look to the Base of the Pyramid The electronic bill payment solution discussed earlier is a good example of the validity of the lower part of the pyramid. Mostly, e-billing saves printing and postage costs. If the customer pays their bill online, the bill never gets printed and mailed. The standard business case for e-billing is based on these savings. Sprint found this view to be narrow.

Figure 6.4. Operational and strategic objectives

Operational

Strategic

$1-$2

Reduce Paper Quantify From Budgeting Reduce Staff Time Process Improve Cash Flow Retain Customers Improve Cross-Selling Improve Quality Control Reduce Employee Turnover Reduce Management Time

$5-$10 Quantify with Strategic Framework


122 Le Clair

“‘My Sprint Account Manager’, MySAM (Computer World staff, 2002) is an e-billing system that has evolved into a complete consumer self-service application. When Sprint convinces customers to adopt MySAM, they are saving more then paper. The company saves $80 per customer for everyone who chooses to use MySAM over the course of one year.” Potential savings are strategic and come from the bottom of Figure 6.4. According to Claudia Moore, a senior marketing manager, “Naturally, with fewer incoming calls, we are able to manage our workforce accordingly.” Moore explains further, “It doesn’t necessarily mean fewer reps, but it may mean more of them are available for cross-selling or handling inbound sales calls.” Customer turnover is another strategic benefit often not quantified in business cases. Consider this, also from Claudia Moore, that, “Thirty percent fewer ebilling users switch carriers compared with those who use regular mail to pay their bills.” This is a powerful testimony to the strategic value of technology. Churn (customers changing carriers) is one of the biggest issues facing wireless telecommunications companies today. Online account management gets a customer hooked. They develop an online relationship that can get better each year. Reducing churn by 30% within the online population is phenomenal and valuable. The value of reduced churn as described above would not be in most business cases today. Looking deeper than the primary ROI target will make these types of strategic savings more apparent to the customer but they need to be presented in tangible way that supports higher value to the customer.

D. Apply Business Case Financials Once performance metrics have been assigned for operational and strategic objectives, an ROI template can be provided. There are many types of standard ROI methods available in finance texts and elsewhere including using a Balanced Scorecard, economic value added, internal rate of return, net



present value (NPV) or payback period. Any of these ROI calculations will produce a workable result as long as they use real numbers from a potential customer. This analysis should focus on understanding the total costs and benefits of pursuing a solution and take into account assumptions that may affect attainment of the expected ROI. The ROI should include: • • • •

A business-as-usual analysis A business-as-a-result-of the new solution A comparison of the two An analysis based on time with key milestones that affect cash flow, investment and return

E. Monitor and Improve Figure 6.1 shows a continuous learning framework for measuring and managing the business case. The real value of the scorecard or other performance management approach is to emphasize continuous self-inquiry. Start your business case with the idea that you are in it for the long term with the customer. Appendix B shows a business case template that provides this mapping.

Summary The way that customers view a supplier’s business case has changed. Poor returns from many projects in the past have created a more skeptical view. In addition, simple cost savings due to staff reductions and speeding up work processes will become a smaller percentage of the overall benefit. Benefits will increasingly be related to strategic and intangible improvements. In addition, customers are being trained in emerging strategic frameworks. It is likely that the supplier’s business case will be reviewed within this context in the future. It is an important perspective for emerging companies building value propositions in today’s environment.


124 Le Clair

The value of the business case framework presented is the ability to make these strategic, objectives quantifiable and actionable. Below is a summary of the major points of this chapter.

Move from Making a Technology Case to Making a Business Case Companies should focus on the business case, not on the technology case. An operational benefit is more important to a customer than having an XML-based solution. The emerging company should be well versed in the concepts of the business case for their solution, and be able to sit with the business owner and a CFO and debate and modify their assumptions.

Leverage Strategic Frameworks Strategic frameworks can help a company understand and articulate their business case. These “toolkits” provide additional credibility for the solution and ensure a matching of the solutions objectives with the strategic objectives of the customer, and help quantify soft costs.

Understand and Mitigate Adoption Risk Understand the affect of technology adoption on your business case. Follow the path of edocs and adapt your pricing model to mitigate adoption risk. Find ways to share risk and return with your customer.

Bridge to the Existing System to Lower Dependence on Behavioral Change Many software solutions have weak business cases because they do not bridge from the old way of doing things to the new. Applications need to provide blended solutions that minimize the business-case dependence on behavioral change, that is, that do not assume rapid cutovers to the new technology.



References ABC staff. (2004, October 21). Health care in America series. Webster, J. (2002). Moving beyond just paying the bills. Computer World, 14, October QuickLink #33255. Edocs quote from March 2000 SEC S-1 Filing, p. 2. Gartner Group. (2002). Information infrastructure investment: Communicating the need to senior management. Stamford, CT: Gartner, Inc., PC Week staff (1998). The true cost of doing business: Quotes commonly cited study by Gartner Group that estimated the total cost of ownership of a PC as near $10,000. PC Week, P 1. New York: Ziff-Davis. Gerstner, L. (2002). Who says elephants can’t dance? New York: Harper Business. Intel Developers Conference (1997). Keynote address story about Gordon Moore. October 27-29, Portland, Oregon. Kaplan, R., & Norton, D. (1992). The balanced scorecard: Measures that drive performance. Harvard Business Review, January / February, 7179. Smith, D., & Blakeslee, J. (2002). Strategic SIX SIGMA best practices from the executive suite. Hoboken, NJ: John Wiley & Sons. Sodano, L., Keltz, H., & Johnson, R. (2003). The Customer Management Applications Report, 2002-2007. Boston: AMR Research. Schmerken, I. (2003). Earning a payback on CRM: Smaller projects, more homework. Wall Street and Technology, August 26, Articld ID 14702314.


126 Le Clair

Appendix A: Strategic Frameworks Below is a summary of the major strategic frameworks: •

•

•

•

CobiT: CobiT’s origins are as an auditor’s tool. It is vast and defines 34 significant processes, linking 318 tasks and activities to them, with an internal control framework for them all. CobiT is based on established frameworks, such as the Software Engineering Institute’s Capability Maturity Model, ISO 9000 and the Information Technology Infrastructure Library (ITIL). ITIL is based on defining best-practice processes for IT service delivery and support, rather than defining a broad-based control framework and has a much narrower scope than CobiT but may be more applicable to a specific IT business case. Committee of Sponsoring Organizations of the Treadway Commission (COSO): COSO is a voluntary private sector initiative dedicated to improving financial reporting in companies. It has made a series of recommendations, the most significant of which is the Risk Management Framework. COSO has become the de facto standard risk-management framework for compliance with new governance initiatives. The wellknown COSO cube shows the relationship between the four “Objectives” categories (strategy, operations, reporting, and compliance) represented by the vertical columns and the eight components represented by the horizontal rows. Once an objective is set, key events are identified such that when they occur will trigger a series of risk assessment and response activities. An enterprise software company’s business case would have clear objectives with events that will affect it positively or negatively and trigger a reassessment of the project. Balanced Scorecard: Typically organizations have elaborate but sometimes overwhelming reporting systems. They also have strategic plans, strategic marketing plans, human resources plans and operational plans for the fiscal year with clear objectives. What is often missing is a single focal point for the key indicators, measures and objectives. The balanced scorecard is that focal point and a communication tool. For each area there should be an objective tied to specific results that are desired. Enterprise Performance Management (EPM): EPM is a super-set of applications that cross-traditional department boundaries to control and manage the full life cycle of business decision-making. EPM is a market



•

for software and solutions rather then a framework being promoted by a standards body. But like all the above, EPM is driven from a company’s strategic goals and establishes a framework to actively, not passively, use performance data to pilot the firm toward desired results. EPM strategies involve setting targets, measuring against those targets, providing incentives for worker performance, and dynamically modeling the business to simulate potential business scenarios. Six Sigma: Six Sigma is a highly statistical quality improvement technique born at Motorola in the mid ’80s. Literally it is the 18th letter in the Greek alphabet, sigma , and the symbol (standard deviation) for statistical measure of variance. When a process is operating at Six Sigma, no more than 3.4 “defects” per million opportunities are produced. Used at the operational level with companies to cut costs, improve process, and reduce business cycle times, Six Sigma practitioners focus on systematically eliminating the defects so they can get as close to “zero defects” as possible. The focus on identifying problems and providing a statistical view of the problem is applicable to business case development.

Appendix B: Developing the Business Case for Customer Self-Service Customer self-service has a strong business case. These solutions transition a percentage of customer inquiries from assisted service to self-service, enabling a contact center to reduce operating costs while in theory, improving customer satisfaction. The average loaded customer service call ranges from $15 to $301. Encouraging clients to use the Web for self-service is scaleable and cost effective. Intangible benefits can also be significant for customer self-service solutions. The cost of a customer acquisition is so high in most industries that it makes sense to invest in keeping the ones you have. This is particularly true where customer-switching costs are relatively low, such as cellular phone and credit card companies. A credit card customer will readily change with continual levels of poor customer service.


128 Le Clair

Build the Model The template below is the summary of the business case. Each tab of a spreadsheet can capture hard and soft benefits, and build to the summary shown. Detail is required for the customer’s investment. These include implementation costs, both from the customer’s investment and the payment to the emerging company. Assumptions of behavioral change can be shown with different assumptions of adoption. Done correctly, the model can provide estimates of intangible and tangible benefits as shown. Each can be expressed as a performance objective. An interactive model is a good way to enable the company to create specific business case scenarios in order to drive interest with the prospect.

Endnotes 1

National Investment Company Services Association (NICSA) (2001) Annual Shareholder Satisfaction Survey: States that average loaded customer service call ranges from $15.00 to $30.00. Project Investment

Startup

Migration

Recurring Cost Total Cost 2005………2008

A. Internal Staff Time B. External Consulting C Enterprise Software D. Hardware and other Software

Strategic

Recurring Benefits

2005……2008

Total Benefit

A. Reduce in customer acquisition costs 5% B. Increase cross-selling success by 15%% C Increase customer retention by 10% D. Reduce employee turnover by 5% Operational E: Reduce Mail and Print Costs F Reduce Reprint Costs G Reduce Consumption (CPU,Storage) H Eliminate Software license I. Call Center Support FTE (people x time) Total Project Return


Assessing Your Affect on the Customer 129

Chapter VII

Assessing Your Affect on the Customer “Cogito ergo Sum” - I think, therefore, I am. Rene Descartes Renes Descartes (1596-1650) was a man of many talents. He was a mathematician, scholar, traveler, physicist, philosopher and thinker. In his spare time he was a primary contributor to modern philosophy as well as analytic geometry. According to Descartes, the guide to truth is to doubt everything systematically until you arrive at a clear idea that is beyond all doubt (Flexner, 1995). This is sound advise for any enterprise software product. Every day believers surround us. We are passionate about our product and company and we can all benefit from taking a step back and forcing a harder look. Using Descartes philosophy, the preceding five chapters are brought together to form a systematic method to challenge a company’s product from the customer’s viewpoint.

Plotting Customer-Focus Variables In Chapter II, we looked at how to identify and minimize the affects of new technology on humans and their organizations. In Chapter III, we studied the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

130 Le Clair

Figure 7.1. Plotting customer dimensions Implementation Relation to Customer’s Core Competency

Business Case

Assimilation

Behavioral Change

characteristics that can help our innovation spread through the customer environment. In Chapter IV we saw how implementation affects the customer’s internal IT organization and project resources. In Chapter V we looked at how the business case affects the economics of the firm. And in Chapter VI, we decided how our product would affect the customer’s strategy. Figure 7.1 provides an easy to use “template” to collectively discuss these effects. Each customer focus dimension can be plotted to assess the strength and weakness of a solution. The further a product is from the center, the stronger it is. The sample plotting in Figure 7.1 shows a solution with strong prospects for assimilation and a positive affect on the customer’s economics. There are concerns about the amount of behavioral change but there is no overlap with the customer’s core competency. The biggest concern is the strain the product places on a customer’s implementation resources.

Drilling Down on Assimilation Figure 7.2 expands the assessment of assimilation from Figure 7.1. For each characteristic of assimilation it is easy to plot where the target solution is and the likelihood of assimilation in the new environment.



Figure 7.2. Assessment of assimilation Managerial IT Knowledge

Bridge to Current System

Sample Plotting

Technology Leverage

Observability

Solution Complexity High Value Gap

Trialability

Relative Usefulness

Replace the Complete Business Process

In the example the solution is weak in replacing the existing business process. This solution may be focusing too much on the technology and not supplying what is needed for the complete business process. It is not essential that all areas be covered for assimilation to occur but it is important that the complete vision exists. The product in Figure 7.2 provides a strong bridge to the current system. This has the positive affect of lowering behavioral change for the user. There is only a small hill to climb rather than a cliff to fall off. The “high value gap”, caused by growth pressure or a strong current business problem is an essential for assimilation. In this example, the product is perceived as only marginally useful. The user may not be in enough pain. Many emerging companies become blinded by the elegance of what they have created. For assimilation to occur the solution cannot be only a nice to have or a strategic direction. It must be something that provides a positive value tradeoff for the customer.


132 Le Clair

Figure 7.3. Product assessment grids Lower Implementation Time

Nice to have, non-essential

High Customer Focus Region

Behavioral Change Relation to Customers Core Competency

“Blue Sky” Still Searching

Highly desired but hard to get there

Higher Lower

Higher Business Case, Assimilation Level

The Product Assessment Grid Another way for products to be evaluated from the customer’s perspective is shown in Figure 7.3. This grid helps to understand where you are and what needs to be improved. Lets look at each quadrant. Products in the lower left are “blue sky” and have a long way to develop. As shown in Figure 7.3, they require long implementation times, high amounts of behavioral change, and infringe on the customer’s core competency. They tend to be very innovative in their vision but have yet to make the business case to the customer. They also tend to low levels of assimilation since the solution is incomplete with no clear identification of the target business process. Many interesting products never leave this quadrant.

Lower Right In the lower right, the customer recognizes that the product has a strong business case and the product has the primary characteristics for assimilation. The product is compatible with the customer’s environment and addresses the complete business process. The customer is convinced to invest in the nextgeneration approach.



But the softer areas of value are not addressed and may stall the products development. For starters, the product takes too long to implement. It may have an unmanageable service to license ratio, or require too strong a commitment from the customer. As important, there is just too much behavioral change by the customer. There may be significant disturbances to the organization, where roles and tasks are altered in ways not completely understood. Or the attitudes of users could be resistant and not spirited. The product also may infringe on the customer’s core competence. It may have redundant expertise with that customer.

Upper Left Products in this quadrant are easy to install, do not conflict with the customer’s skills, and require a low level of behavioral change. Yet, they have not made the business case to the customer. Nor do they have the primary characteristics for assimilation. It may not be perceived as useful or very usable, or if useful it may not be easily observed as such. The product might have a hard time catching on. It also may not offer a complete enough solution to obsolete the previous operating model. This quadrant contains products that are “nice to have” or non-essential, to the customer, and are destined to remain on the lower end of project priorities.

Upper Right The upper right quadrant contains product and services that combine a strong business case and a complete solution, with the attributes required for success. Here is the region of true value both to the customer and the company. In this quadrant the normal barriers of implementation difficulty, behavioral change, and relation to core competency in the customer environment are low or nonexistent, and the solution has a compelling business case. It has achieved the balance of customer pain and value. These attributes allow the solution to be drawn into a market where it is likely to spread like a virus. The focus of the rest of the book is how to build products that move to the upper right.


134 Le Clair

Using the Model to Improve What does an emerging company now do with this information? Firstly, each dimension has now been examined. The company understands a great deal about how the customer sees its solution. Using the example at the beginning of this chapter in Figure 7.1, it can study the implementation process to reduce that effect on the customer, perhaps by adjusting the professional services approach, take a process view of training, and reduce the process-technology gaps. The company can use the process outlined in Chapter II and drill into behavioral change required by the customer. They can examine the organizational and human aspects of their solution. From a marketing perspective, the firm can focus on the positive aspects of Figure 7.1. The solution has a strong business case, which can be emphasized. With the assessment template and Descarte’s attitude we can continually question our solution in a very specific manner. The Balanced Scorecard (BSC) approach, for example, can make each weakness uncovered actionable. Each customer dimension can be viewed as an objective within the BSC framework. It is an easy task to specify tasks and goals to reflect progress against each customer dimension. Figure 7.4 shows a BSC-based assessment map for implementation. The particular areas of weakness for the solution are highlighted.

Mapping of Technology Markets Figure 7.5 maps the primary business-to-business technology markets into the product assessment grid of Figure 7.3. The mapping points out challenges Figure 7.4. Assessment map for implemenation Implementation S/L Ratio

Product Adaption Sales Cycle

Solution Focus

Process View of Training

Customer Commitment



faced by companies in each of these markets. As can be seen, all markets have challenges in moving to the upper quadrant, but some focus variables are harder than others for each market. E-BPP and customer self-service, for example, have a strong business case stemming from paper replacement and reduction in call center expenses. The continued Achilles heel remains in the behavioral change arena. At what rate will consumers adopt online servicing? Both CRM and ERP suffer from extensive implementation challenges with business cases that tend to be loaded with soft costs. Document management due to the vast expense of paper-based systems will continue to have a strong business cases. These systems will still suffer from potentially high behavioral change, and implementation issues. These companies also need to start attacking specific business problems and begin to address strategic objectives of their customers. Business intelligence (BI) is a broad market consisting of tools, enterprise software suites and platforms, which support reporting and analysis of business data. The goal is to gain business value from analyzing quantitative data using statistical models, conditional logic, reports and custom interfaces. BI vendors have had low levels of implementation success and have struggled with assimilation. Implementation issues result from too high a process-

Figure 7.5. Customer impact challenges enterprise software markets Lower Nice to have, nonessential

High Value Proposition

Implementation Time

Content/Document Management

Behavioral Change Relation to Customers Core Competency

CRM

ERP Business

Still Searching Intelligence

Higher

E-Commerce

Customer/self Service Highly desired but hard to get there

Lower

Higher Business Case, Assimilation Level


136 Le Clair

technology gap for their products. General BI packages needed to be tailored to the business process to have value. To succeed and move to the upper right they must acquire sufficient domain expertise for each functional or vertical application and apply it to their product. Companies in any of these markets have the potential to move to the upper right. The rest of the book provides guidance to assist companies in this pursuit. The Appendix shows more detail on the specific challenges faced in each of these markets.

References Flexner, D. (1995). Optimists guide to the history. New York: Avon Books.



Appendix A: Customer Challenges by Software Market Below is a quick review of the implementation challenges faced within the major enterprise software markets. For easy reference, the five value components are summarized below. Customer Business Case

Firms make decisions on technology spending based on return on investment

Behavioral Change

Behavioral change measures what effect your solution will have on the customer’s “ecology”.

Implementation Difficulty

Market share is greatly affected by installation time and effort on the customer’s part.

Relation to Customer’s Core Competency

The customer’s core expertise and capability affect the value of the solution.

Level of Assimilation

A high level of assimilation is required for a successful software product.

Business Case Challenges by Market The following table shows the customer business case challenges in the primary application software markets.

SOFTWARE MARKET

BUSINESS CASE EVALUATION

ENTERPRISE RESOURCE PLANNING/SUPPLY CHAIN

MEDIUM. THERE IS LITTLE IMMEDIATE BOTTOM LINE IMPACT.

E-COMMERCE /WEB SITES

HIGH. EXCEPTIONAL ROI FOR CUCTOMER SELF SERVICE.

CUSTOMER RELATIONSHIP MANAGEMENT

MEDIUM VALUE IS IN SOFT DOLLARS: BETTER CUSTOMER SERVICE, MORE REPEAT BUSINESS. LONG IMPLEMENTATION TIME DAMPENS ROI.

CONTENT MANAGEMENT WORKFLOW/DOCUMENT MANAGEMENT

HIGH. EXCEPTIONAL BUSINESS CASE WHEN PAPER-BASED SYSTEMS ARE REDUCED,I.E. DOCUMENT MANAGEMENT MEDIUM FOR PURE CONTENT MANAGEMENT APPLICATIONS

MIDDLEWARE SOFTWARE

POOR COST SAVINGS ARE LONGER TERM.

BUSINESS INTELLIGENCE

POOR STRATEGIC/ COST SAVINGS ARE LONGER TERM.


138 Le Clair

Behavioral Change Challenges by Software Market The following table shows the behavioral change challenges facing the emerging company in the primary application software markets.

SOFTWARE MARKET

CUSTOMER BEHAVIOR CHANGE


HIGH USED BY ADMINISTRATIVE PERSONNEL WHO MUST LEARN NEW BUSINESS PROCESS


VERY HIGH. CONSUMERS HAVE BEEN RELUCTANT TO FULLY ACCEPT THE INTERNET.


MEDIUM. USED BY PEOPLE POSSIBLY THROUGHOUT THE COMPANY, REQUIRING MODIFICATION OF WORK PROCESSES.


MEDIUM. COULD INVOLVE PROCESS RE-ENGINEERING AS PAPER-BASED SYSTEMS ARE REPLACED BY ELECTRONIC WORK-FLOW SYSTEMS.

MIDDLEWARE SOFTWARE

MEDIUM. COULD INVOLVE EXTENSIVE RETRAINING TO LEARN NEW TECHNOLOGIES.

Assimilation Challenges by Software Market The following table shows the challenges facing the emerging company in building disruptive solutions in the primary application software markets.

SOFTWARE MARKET

POTENTIAL DISRUPTION


MEDIUM INTEGRATION POTENTIAL AND APPLICATION DEPTH ARE CRITICAL, BUT CAN RESULT IN DRAMATICALLY NEW BUSINESS PROCESSES.


HIGH PARTICULARLY FOR PAPER-BASED APPLICATIONS


MEDIUM WHEN BLENDED WITH E-COMMERCE SOLUTIONS, LEVEL WOULD INCREASE SIGNIFICANTLY. CAN REVAMP EXISTING BUSINESSES APPROACH TO CUSTOMERS.


HIGH WHEN COMBINED WITH RE-ENGINEERED BUSINESS PROCESS, WOULD RESULT IN SIGNIFICANT SET OF REVISED BUSINESS PROCESSES.

MIDDLEWARE SOFTWARE

MEDIUM STRONG POTENTIAL FOR NEW STANDARDS-BASED DEVELOPMENT METHODOLOGIES TO RAPIDLY OBSOLETE EXISTING APPROACHES.


MEDIUM CAN REDEFINE THE METRICS USED TO MANAGE A COMPANY



Implementation Difficulty Challenges by Software Market The table below shows the challenges facing the emerging company in implementing solutions in the various software markets.

IMPLEMENTATION DIFFICULTY

SOFTWARE MARKET




VERY HIGH COULD BE SIGNIFICANT WITH DEPARTMENTAL INVOLVEMENT

SKILL

SHORTAGES

AND

CROSS

HIGH COULD BE EXTREMELY INTEGRATION.

HIGH FOR

EXTENSIVE

LEGACY

SYSTEM

HIGH COULD BE EXTREMELY INTEGRATION.

HIGH FOR

EXTENSIVE

LEGACY

SYSTEM


HIGH WILL REQUIRE LEGACY SYSTEM INTEGRATION

MIDDLEWARE SOFTWARE

MEDIUM COULD REQUIRE RETOOLING.


MEDIUM WILL REQUIRE INTEGRATION OF DIVERSE INFORMATION SETS AND POTENTIALLY “FILTERING” OF EXTENSIVE DATABASES

Customer Core Competency Challenges by Software Market The table below shows the challenges faced by emerging companies in each of the major software markets.

SOFTWARE MARKET

RELATION TO CUSTOMER’S CORE COMPETENCY

ENTERPRISE RESOURCE PLANNING/ SUPPLY CHAIN

DEPENDS. GENERALLY LOW, BUT EXTENSIVE COMPANY INVESTMENT IN LEGACY SYSTEMS CAN ELEVATE CORE COMPETENCY


DEPENDS. SOME FIRMS MIGH HAVE BUILT UP EXTENSIVE E-BUSINESS EXPERTISE


DEPENDS. MANY COMPANIES THINK CUSTOMER MANAGEMENT IS A CORE COMPETENCY


DEPENDS. GENERALLY LOW, WITH THE LARGEST MARKET IN FINANCIAL SERVICES.

MIDDLEWARE SOFTWARE

LOW GENERALLY MINIMAL.


LOW


140 Le Clair

Part II A Customer-Focused Approach to Value Discovery in Developing Markets


Product Development Background

141

Chapter VIII


This chapter addresses issues in systems development and design of software products. The goal is to describe three problems in the industry. First, is the inability of current methodologies and practice to factor in human and organizational issues. Second, is the high number of “one off” or custom solutions that we see in practice. And third is the inflexibility of current systems development methodologies. Chapter Nine will introduce a method that addresses these observed industry issues. We begin by describing the difficult task facing the software company when creating solutions for new markets. Next, the leading systems development methodologies used in the industry are provided for context. The state of the industry in terms of software practice maturity is then described with emphasis on the typical development approach taken for new software applications.

The Difficult Task of Creating New Products Although, I never saw him play, one of my favorite baseball players is Pete Reiser. He played for the Brooklyn Dodgers in the 1940s. At the time, it was Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

142 Le Clair

thought he would be one of the all time greats. He was so enthusiastic, determined, and focused on the single objective of catching a baseball that he kept crashing into unpadded outfield walls. He was injured no less then seven times. After one particularly heroic effort in 1947, he was paralyzed for 10 days. A priest even gave Reiser last rites. Companies breaking into new markets tend to take the Pete Reiser approach. Full speed ahead into hard surfaces and like Peter Reiser they get up and back in the field the next day (Appel, 2002). Why is breaking into new markets so hard? • • • • • •

You have no customer references or credibility because the markets you are trying to break into are new to you. You start with very little domain experience. You must figure out a value proposition. You must develop the application often with barely proven technology. You have to figure out how to market it in this unknown space. There is a technology hangover from the Internet bust.

Introducing new technology is difficult for any company, regardless of whether the market is new for them or not. Look at Figure 8.1; you’ll see that the easiest task is when firms sell existing technology to their current market (lower left quadrant). The technology is proven and that market knows them. Selling proven technology to new customers (lower right) is the next easiest. The value proposition is proven in one market, but the credibility, commitment, sales, and marketing infrastructure all need to be established in the unknown market. But at least you have a product. It has been successfully deployed and you have a reference. Introducing new technology to existing markets (upper left) can be positioned as product extensions. You can go to your best customers and convince them to take your new product. You have leverage and domain knowledge. Our focus is creating new markets with new technologies (upper right quadrant of Figure 8.1). This is what emerging companies do. It is the same as steering a large ship in a deep fog without navigational support. You have only vague ideas about the most fundamental things.



143

Figure 8.1. Technology introduction (Adapted from the Ansoff Matrix: Market

Opportunities, 1957)

Technology New

Proven

Product Extensions Existing Market Share Existing

Missionary

Market Expansion New

Markets

“What technology should be developed? What major problem should be solved? Will the technology work? Who are the likely competitors? How large could the market be? How much investment will it take to get there? For that matter, where is there? What new events will alter the path?”

The Isolated Mindset Product development must begin with the customer, for without customers with needs to be met, the solution has no reason to exist. Many emerging companies create products in an isolated manner from their customers or the market. Basic customer research is not adequately performed. Basic questions are often unanswered like whether the product already exists or whether its existence is something the customer cares about. This is often due to a narrow reliance on the entrepreneur’s innovative ideas or the isolated mind set of the company’s management. In some cases the founderentrepreneur feels they know the best application of the technology and can make this determination independent of market feedback.

The Thrill of the Chase In other cases, the entrepreneur’s great technology will chase after a problem to solve. Tangible products, like automobiles, are “pushed” out to the market Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

144 Le Clair

with the company in firm control. The auto company defines the market, designs a product and then pushes it out to the field with a carefully planned launch. By contrast, enterprise software products blend a strong “pull” from the customer with technical innovation. Figure 8.2 shows this balance. The vertical axis shows technical innovation and vision; the horizontal shows the pulling force of the customer. When they combine in just the right way, conditions are ripe for a successful product. The shaded area of 8.2 is where a product need is discovered in business and visionary technology is then adapted. But unfortunately, in many cases, a software company will develop an interesting technology and will search for a problem to solve. Technology chases the problem in this case. On occasion, the software company can become obsessed with the innovation and not listen to the market. This dogmatic vision can stifle the growth of promising innovation as in the following example. Novocain was invented in 1905 by German chemist Alfred Einhorn for use in major surgery, but it was not suitable. Dentists wanted the product immediately, but the inventor tried to stop them from using it for the mundane purpose of drilling teeth. Einhorn never gave up trying to apply his invention to general surgery (Drucker, 2002). He had the classic isolated mindset and dogmatic vision of Figure 8.2. The other extreme to the “big idea” developed in isolation is to create products in the field. This is, in effect, listening too much to the customer. It is always good to listen to the customer describe their pain. It may lead to a product idea and then to product development but in the end may require too much investment before the viability of the solution is known. From a company standpoint, it is a scattergun approach to business development. One that potentially creates more opportunities then the company can handle. And one that can create all kinds of unforeseen problems as in the following example.

Trouble in the Field My first experience with extreme, customer-driven product creation was when trying to win a data communications competition in the United Kingdom. It was for the data processing arm of a major car manufacturer. They desperately needed more networking capacity and wanted to offer a public data communications service to other U.K. manufacturers. At the time, BBN Communications was the technology leader in switching equipment for large-scale networks. They had successfully transferred the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


145

Figure 8.2. Customer-driven product planning Technical Innovation & Vision

Dogmatic Vision

Flexible and Creative Adaption of Technology

No Interest Zone

Complete Opportunistic Selling

Pulling Force of the Customer

government-funded Internet technology to the corporate environment and had captured a large share of the international market. In this particular contest the best network design called for a large concentration of switching power in one central location. BBN built small, very intelligent switches, while our competitor built very powerful but not very sophisticated ones. With the customer’s highly concentrated network traffic, this was an excellent fit for their equipment. Our initial network design had over fifteen of our less powerful switches in the single data center, making our bid cumbersome from a maintenance perspective and very expensive. We had contacts at the company that told us our bid was twice that of the competition. They told us to not bother coming to the meeting, but instead we went to a nearby pub to assess the situation. “What’s the main problem”, I asked our U.K. team. “Our main problem”, they said, “is always the same. Our switches are too slow and too expensive. We are wasting our time in this market, and no one in the states is listening.” The beer may have been a factor. But we came up with a plan that “extended” our product line. It boiled down to taking the main communication board out of our 15 communication switches and putting them in four tall cabinets. This reduced the number of total switches in our solution to four from 15. This made our switches look more powerful. We renamed the product and priced the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

146 Le Clair

solution to just below our competitor Northern Telecom and hoped our advanced technology would carry the day. We did call development. But as pointed out in the aftermath, it was very late in the evening. Probably to get us off the phone, they gave us a” tentative” thumbs up on the napkin-based design. We sent in the bid, presented well, and won the contract. It was one the company needed. The next morning we had breakfast with our CEO and could not wait to relay the story, but rather then being congratulated and as I watched my English friends run for cover, we were lectured on potential problems created by inventing products in the field, without going through product marketing and development to get necessary signoffs.

Lessons Learned in the Field It turned out that our “design” did not account for additional heat generated by so many communication boards in one rack. The product ultimately required a redesign of the hardware. But eventually things worked out. The effort started the new low-end product line and helped fend off CISCO systems for a few more months. And the customer was happy. But there was a lot of pain that could have been avoided. The main lesson was clear to me then and has carried through to this day. Firstly, there is nothing like the pressure and intensity of the field to understand and shape the product. This repackaged product was exactly what this product line needed. We should have figured that out in marketing a year earlier. Secondly, you absolutely need the checks and balances of marketing and development.

How Flexible Should We Be? The key to the success for visionary and successful companies has been flexibility. Many like IBM, Hewlett Packard and Sony did not succeed with their original idea or plan (Collins & Porras, 1994; Hargadon, 2003). The development of a unique core competence led the application of any technology to a specific product. The path to success required flexibility and picking good spots. They were able to balance opportunity with innovative thinking. Given the creative task at hand and the need for flexibility, what is the best framework for developing enterprise products for new markets? Before we attack this question, lets review the state of current development methods. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


147

Software Development Background The first models of software development were derived from other engineering processes. They made the formerly abstract process of software development more visible and were widely accepted. Much of this early research came from contractors and “think tanks” that developed major military systems. Companies like RAND and Mitre Corporation developed leadership in “systems engineering”. They had complex systems to tackle, and the luxury of a government funded research environment to focus on “best practice”. These early processes were devoid of the human element and have been referred to as “hard approaches” reflecting this absence and the emphasis on basic engineering practice.

Systems Development Life Cycle (SDLC) Today, the primary “hard approach” and the de facto standard is the SDLC model. This process represents development activities as separate phases such as requirements specification, software design, implementation, system testing, operation and maintenance. After each stage the deliverable is “signed off” and goes on the next phase. Because of the cascade from one phase to another, the model became known as the “waterfall” model. Most system problems can be traced to errors in design. Recognizing this, the waterfall extensively studied and documented the early design steps. But this led to very long requirements and specification phases and to longer and longer development projects. In addition, the pace of technical innovation increased and systems started to involve humans more, leading to unstable user requirements. This challenged the waterfall methods, as the premature freezing of requirements often meant the system would not do what the user wanted. The basic problem was the inflexible partitioning of the project into distinct phases. The advantage of waterfall development is that it allowed for strict decomposition, which led to better control. It also made sure adequate attention was paid to requirements definition. The work would proceed through the development process in a serial and controlled manner like an assembly line in a factory, and theoretically, be delivered on time. Many projects met deadlines, but in too many cases the wrong system was delivered (Sommerville, 1996). Due to deficiencies in the waterfall model other SDLC methods evolved. These included rapid application development (RAD), joint application development Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

148 Le Clair

(JAD) and various spiral models. A summary of each of these models is included in Appendix A.

Evolutionary (Spiral) Methods In response to the inflexibility of the waterfall models, evolutionary methods evolved. These started with exposing a quick initial implementation to users for comments, and refining this through many versions until an adequate system was delivered. Rather than a set of long serial tasks, the specification and development activities were carried out concurrently with rapid feedback. The primary evolutionary development approach became known as the “spiral” method and proposed by Boehm (Boehm, 1988). The most important distinction between the spiral model and evolutionary SDLC approaches is explicit treatment of risk. Risk is often a result of inadequate information. Breaking the project into short phases, as in a spiral method, would allow better information gathering. Specific risk mitigation strategies could then be applied. For example, if user requirements are unstable, the project could create a throwaway prototype and get user feedback. As system grew in complexity, Boehm provided a model that explicitly recognized the risk of getting the requirements correct.

Object-Oriented Design Methods Object orientation emerged from concepts developed in the late 1960s from early work in building simulation systems. Simula-67 was the first programming language to include the concept of classes and objects. The term “objectorientation” was first used at Xerox PARC in developing the first graphical user interface (Goldberg, 1985). The work at Xerox led to development of mainstream object-oriented programming languages such as C++. In the late 1980s the principle of object-oriented programming began to influence the of system design process. The goal of object-oriented design is to align the design method with the latest software development approach. Object-oriented design and programming has gained momentum since it allows the greater reuse of software components. It does this by providing a semantic context to group and generalize common tasks.



149

If you were designing a new radio for example, but ultimately wanted to build a full line of electronic devices, you might take an object-oriented approach. You would recognize that the headphones, antennae, and rechargeable battery would be common to these future products. These components would be designed as common objects so that that could be plugged into all products. Common to all software design approaches is the need to decompose or break down systems into more manageable components. SDLC and its derivatives decompose at the process level with the goal of dividing a complex system into simple parts that are executed serially or in parallel. Object oriented approaches decompose into individual and autonomous objects that then communicate to solve a problem. Current research and practice favor object-oriented design approaches (Maiden, 2003). The primary advantage is that object-oriented decomposition results in components that are reusable within the system being built and also in future systems. This provides “application scalability”. Generic software functions can be more easily applied to new customer problems without rewriting the software base. In addition long-term maintenance is reduced since as upgrades to a component occur they can be migrated to all applications in the field.

The State of Software Development in Enterprise Software Before we look at the state of software development practice, it is helpful to refer to the capability maturity models (CMM). First developed by the U.S. Department of Defense to determine likely contract performance in software acquisition, it is used to judge the maturity of the software processes of an organization. With CMM key practices required to increase the maturity of these processes can be identified. CMM is becoming a de facto standard for the U.S. and worldwide software community. One advantage of CMM is the focus on the entire process as opposed to a narrow focus on software testing. It describes the principles to improve the maturity of software processes with an evolutionary path from ad hoc and chaotic processes to mature and disciplined approaches. The five maturity levels are described:


150 Le Clair

• •

Level 1 has few defined processes with reactive and ad-hoc activity. Level 2 has established management processes to track cost, schedule, and functionality, and earlier success on projects that can be repeated with similar applications.

•

Level 3 has a standard software process that documents, standardizes, and integrates both management and development activities. Level 4 collects detailed measures of the software process and product quality to quantitatively understand and control the process. Level Five contains continuous process improvement enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

• •

According to the Software Engineering Institute (SEI) (2001), most companies do not have mature software practices. Their survey questioned almost 2000 mature organizations. They found that 77% of U.S. corporations were at Level 1 or 2 with more than 50% of companies worldwide at these levels. More than 30% of U.S. companies were at Level 1, that is, chaotic and ad-hoc processes. With the above research it would seem likely that software companies at the nexus of new markets are at the Level 1 as defined by the CMM model, that is, they have ad hoc, and even chaotic processes in place. This would mean that few processes are defined, with success depending on individual effort and heroics. This profile fits with my experience working with many software companies. In fact it is really worse then this. Software developers at several of these companies viewed what they were doing as having no process at all. Attempts at following a standard process continually broke down under the pressure of their business.

The “One-Off” Syndrome An important question is whether the software company trying to develop new products for new markets is ready for the comprehensive system development models described above. The SDLC or object-oriented methods assume that value has been discovered, and a clear product strategy is in place. This is seldom the case for newer markets. These formal approaches may not have the flexibility required for developing products under these conditions and could Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


151

Figure 8.3. Typical development cycle for enterprise software Customer Fit

One Off

Generalized Platform Rebuilding Stage Scalability

explain why they seem not to be used. Let’s take a look at a typical development cycle for companies going into new markets to try to understand why this is so. Development processes for new for enterprise solutions follow a predictable pattern and unfortunately do not use formal development methodologies until very late in their maturity. As a result the pattern is not always a pretty one. The first release of software is similar to the first pancake off the griddle. The stove temperature was not quite right. The frying pan’s surface is perhaps a bit sticky. The chefs are not sure when to make the flip. And, depending on the batter inventory, the first batch is usually discarded. The second batch of pancakes is always better, and it is the same with software. Figure 8.3 shows the path that many software development efforts take. Phase 1 is the “one-off stage” where software is tailored to the needs of the early adopter customer. Here the feature match to the customer is extremely high that is, the process-technology gaps cited in Chapter Four are low, since it was built to the customer’s specification. It does very specific things and the early customer is initially happy. Unfortunately, their was no standard development process used that would allow a high percentage of the “software base” to be reused. For example, there was no object-oriented design approach that created reusable components. Over time the software company will realize that the implementation time and expense will be as much for the second customer as the first. So why was a one-off system built with no SDLC. The reason was probably schedule pressure. Customer number one needed to be implemented with an unrealistic schedule. Perhaps the software company had tried two other product initiatives before this one that did not work and were under the gun to show progress. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

152 Le Clair

As a result most features were “hard coded”, making them difficult to modify or enhance. No administrative tools were built so that the customer will have to ask the software company to make even simple configuration changes. There was no APIs used to integrate with the customer’s internal applications, so that changes to those applications will require software changes to the supplier’s software. And there was no formal architecture and design process meaning that additional users or transactions may result in performance issues. In short you have built a non-scaleable custom solution. Even scarier, the software companies business plan may have assumed a rate of customer growth not achievable with the “one-off” platform created. Implementation time for each customer is too long and uses too many software developers. Many crisis meetings result in the correct decision to rebuild the first system and begin to build a “generalized” platform. The software company then enters a “rebuilding stage” where formal processes for systems development ware used. Scalability and reusability are the goal, but with it comes painful discipline for the sales force. They have to start selling what they have. They can not expect to sell exactly what the customer wants and expect development to bail them out. Those days are gone. Equally painful, your small number of happy customers must now convert to the general platform. The generalized platform makes the software easier to maintain and is very important for the software company. However, it is somewhat less important for the customer, particularly in the short term, and they will be unhappy when asked to convert. They have suffered through being an early adopter, and it works well. The emerging company then enters the “generalized platform stage” where happy customers and higher margins can be sustained. Unfortunately this stage occurs very late in the game. Just as the company is gaining momentum they have to slow down and redo their software base. Perhaps by this point they were purchased by another company and are handing them an unreliable and non-scaleable platform.

Why Are “One-Offs” So Bad? Software development tools have improved significantly. In one sense, these improvements free us to focus on higher-level concerns, such as finding value at the business level. In another sense, advanced tools allow us to build poorly Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


153

thought out systems and deliver them quickly, and have led to an increase in the ability to create one-off solutions. Mature enterprise applications will have hundreds of thousands of lines of software. Value for the customer can emerge from the most heavily exercised software paths or from the exceptions or rare occurrences. While it has become easier to generate this software, once completed it is now more complex to manage. Basically, one-off systems are difficult to manage over time. Now imagine that you have installed five unique versions of this software for your initial customers and that each one is asking for new administrative features. The software company now has to make five different versions and test them with each customer. It can be done, but what often happens is the software company begins to respond poorly to its customer base. Software enhancements requested by the customer become very expensive and have long delivery times. Over time, the customer begins to look for alternatives. The complexity and difficulty in managing software is well understood by the software testing industry which will tell you that in mature applications only 20% of the software base can be reliably tested due to the rapid growth of usage and exception paths. This complexity is underscored by the following.

Starry, Starry Night The Mitre Corporation is a nonprofit research facility for the U.S. government specializing in advanced technology, primarily for military applications. They design some of the most sophisticated computer systems in the world. I was a member of the technical staff at Mitre shortly after Ronald Reagan make his famous “Star Wars” speech. This idea launched the spending of billions of dollars of research on a space-based weapons systems. The program was controversial on many levels but if you were a software professional you worried about how to test the command and control software. Many believed there was no way to develop a reliable test plan for the brains of the system, that is, the software that controls the weapons. To many, the spaced-based hardware was easy. Weapons and satellite technology were mature compared to the command and control software. When completed the command and control system for Star Wars was estimated to require 60 to 100 million lines of software. There was only one problem with this. No one could say with certainty that all possible software paths for the system could be 100% tested and therefore be certified as reliable. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

154 Le Clair

The biggest critics of the system came from the software research area, and were people who knew what they are talking about. Now would you trust the control of space-deployed weapons to untested software? With billions of dollars of resources, the best available talent in the world, the software was too complex to manage. The point is that software is not produced and shipped. It is started and never ends and evolves over time into something other then the original form. It nestles into the target ecology and expands like an organism responding to its environment. Without discipline in design and development, it becomes an unmanageable custom solution and at some point will be discarded. The next chapter will discuss approaches to maintaining flexibility without creating “oneoff” solutions.

References Ansoff, I. (1957). Ansoff Matrix: Market Opportunities. One of the pioneers of strategic management first introduced the idea of simple matrix in 1957. Strategies for Diversification. Harvard Business Review. Appel, A. (2002). From Ellington and Armstrong to Matisse and Joyce. New York: Alfred A. Knopf. Boehm, B. (1988, May). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72. Collins, J., & Porras, J. (1994). Built to last. Harper Business. Drucker, P. (2002). Managing in the next society. New York: St. Martin’s Press. Goldberg, A. (1985). The language and its implementation. Boston: AddisonWesley. Hargadon, A. (2003). How breakthroughs happen. Boston: Harvard Business School Press. Maiden, N. (2003). Lecture. City University, London: School of Informatics. Software Engineering Institute. (2001). CMM Review of 1970 companies. Assessment conducted through June 2001 and reported to the SEI. Sommerville, I. (1996). Software engineering. Boston: Addison-Wesley.



155

Appendix A: Summary of Software Development Methods The following descriptions are distilled from a combination of sources including searchVB.com, a TechTarget site for Visual Basic professionals; searchWin2000.com, a TechTarget site for Win2000 professionals; and searchSmallBizIT.com, a TechTarget site for SmallBizIT professionals. These are an excellent resource for the information management professional.

SDLC Software development is a complex undertaking and there continues to be significant research resulting in many different approaches. Most attempts use a standard set of steps to manage and control development. The traditional and most commonly adopted approach is the software development life cycle (SDLC) model which breaks the overall process into sequentially ordered set of phases marking the progress of the systems analysis and design effort. In general, SDLC includes the following phases: 1) project identification and selection; 2) project initiation and planning; 3) analysis; 4) design; 5) implementation; 6) maintenance. SDLC enables systems projects to be planned and controlled in a business-like manner to ensure that users and managers get the systems they want in a reasonable period of time and at acceptable cost (Necco, 1987). In general, an SDLC methodology follows the following steps: 1.

2.

3.

The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel. The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement. The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.


156 Le Clair

4.

5.

6.

The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

However, criticisms of traditional SDLC have led to other approaches developed to complement the traditional SDLC. These approaches include the object-oriented analysis and design, prototyping, and joint applications development (JAD). These are now described.

The Waterfall Model The waterfall model is a popular version of the systems development lifecycle approach for software engineering. It is considered the classic approach to the systems development life cycle; the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.



157

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well thought out in the concept stage.

The Spiral Model The spiral model, also known as the spiral lifecycle model, is a systems development method SDM used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. The steps in the spiral model are as follows: 1.

2. 3.

4.

5.

6.

7.

The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: 1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; 2) defining the requirements of the second prototype; 3) planning and designing the second prototype; 4) constructing and testing the second prototype. At the customer’s option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.


158 Le Clair

8. 9.

The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Rapid Application Development Rapid application development (RAD) is a concept that products can be developed faster and of higher quality through: • • • • •

Gathering requirements using workshops or focus groups Prototyping and early, reiterative user testing of designs The reuse of software components A rigidly paced schedule that defers design improvements Less formality in reviews and other team communication

There are third party products that provide some or all of the tools for RAD software development. These products include requirements gathering tools, prototyping tools, computer-aided software engineering tools, language development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented development methodology, which inherently fosters software reuse. The most popular object-oriented programming languages, C++ and Java are offered in visual programming packages often described as providing rapid application development.

Joint Application Development (JAD) JAD is a methodology that involves the client or end user in the design and development of an application, through a succession of collaborative workshops called JAD sessions. Chuck Morris and Tony Crawford, both of IBM, developed JAD in the late 1970s. The JAD approach, in comparison with the more traditional practice, is thought to lead to faster development times and greater client satisfaction, because the



159

client is involved throughout the development process. In comparison, in the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews. A variation on JAD, RAD (described above) creates an application more quickly through such strategies as using fewer formal methodologies and reusing software components.

Synchronize and Stabilize Synchronize and stabilize is a SDLC model in which teams work in parallel on individual application modules, frequently synchronizing their code with that of other teams, and debugging (stabilizing) code regularly throughout the development process. The sync-and-stabilize model offers advantages over the older waterfall model, which is strictly sequential in nature. Because sync-andstabilize development allows for changes at any point in the process, it can be flexible, and more easily able to respond to market requirement changes. At a recent XML Web Services One conference, Cusumano cited as-yet unpublished research findings indicating that a majority of development projects follow the sync-and-stabilize approach. The sync-and-stabilize approach was created by David Yoffie of Harvard University and Michael Cusumano of MIT. Cusumano and Yoffie studied commonalities between processes Microsoft used in developing Internet Explorer and those Netscape Communications Corp. used in developing Netscape Communicator. The researchers found that, among other similarities, both companies compiled all the project code nightly. They both also brought together all the components and tried to stabilize code before it was released. Cusumano and Yoffie integrated the successful common strategies of the two projects into the sync-and-stabilize model.

Object-Oriented Design An object-oriented design organizes the application around “objects” rather than “actions” and data rather than logic. Historically, software has been viewed as a logical procedure that takes input data, processes it, and produces output data. Object-oriented design takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by


160 Le Clair

name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars). The first step is to identify all the objects you want to manipulate and how they relate to each other. Once you’ve identified an object you generalize it as a class of and define the kind of data it contains and any logic sequences that can manipulate it. The object or class instance is what you run in the computer. You communicate with objects – and they communicate with each other – with welldefined interfaces. The concepts and rules used in object-oriented design and programming provide these important benefits: •

•

•

•

The concept of a data class makes it possible to define subclasses of data objects that share some or all of the main class characteristics. Called inheritance this property of forces a more thorough data analysis, reduces development time, and ensures more accurate coding. Since a class defines only the data it needs to be concerned with, when an instance of that class (an object) is run, the code will not be able to accidentally access other program data. This characteristic of data hiding provides greater system security and avoids unintended data corruption. The definition of a class is reusable not only by the program for which it is initially created but also by other object-oriented programs (and, for this reason, can be more easily distributed for use in networks). The concept of data classes allows a programmer to create any new data type that is not already defined in the language itself.


A Customer-Focused Value Discovery Process

161

Chapter IX


“Action without theory is fanaticism, but theory without action is sterile.” Lenin This chapter addresses the inability of current methods to factor in human and organizational issues, the high number of “one-off” solutions produced in the industry, and the inflexibility of current systems development methods. Several case studies are included that point to the value of using prototypes and having rapid customer feedback. The goal is to blend best practices from the industry’s current systems development methods introduced in Chapter VIII, with a socio-technical approach for new product development covered in Chapters II through VII. This is admittedly an ambitious goal, and it is not intended that there be a strict adoption of the methodology proposed here. It is hoped that these thoughts will influence what we are doing today. Ultimately, the best product management and development approach for a software company will depend on the culture of that company, and will be influenced by their maturity, and the market they are in. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

162 Le Clair

As argued throughout, the industry is ripe for some change. Our products need to fit better into the customer’s organizational ecology. They take too long to implement, do not address the complete business solution, and have business cases dependent on significant technology adoption. In short, they do not involve the customer early enough in the process to overcome these obstacles. To respond to this, product development needs to emerge directly from the customer’s human, organizational, and technical requirements. Doing so will allow us to provide a strong socio-technical foundation to the development process. Flexibility is fundamental to the process. The history of software design, from waterfall to spiral and then to object-oriented approaches, has shown a continual emphasis on flexibility. Following this trend, the framework tries to develop the ultimate “light” development process suitable for the emerging company or for mature companies venturing into completely new markets, where firm value propositions are not in place. This discovery process depends on the established development methodologies described in Chapter VIII. SDLC and object-oriented methods are very much part of the process. A primary goal of the proposed framework is to avoid or shorten the “one-off stage” described in Chapter VIII and move quickly to more rigorous approaches as the software initiative matures. If most software companies are using limited process today, this has to be an improvement.

The Discovery Framework The discovery framework is shown in Figure 9.1. The four parts to the process are concept, research, initial development and assessment and validation. Product initiatives compete to move through the product development funnel. As shown there may be ten product ideas at the step A and five at step B. Step C narrows the focus and applies formal development processes. It is an important gate and where investment in the idea increases. Chapter X will provide a process to compare products and determine whether they can pass this milestone. The framework recognizes the likely maturity level of software firms and blends the needed flexibility, with the required discipline of formal development methods. Various socio-technical techniques introduced in Part 1 are used in steps B and C. The approach ensures attention to these principles. The Balanced Scorecard is used for the assessment and validation phase. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


163

Figure 9.1. A customer-focused framework for value discovery Research (5) Initial development (3) B

A

Customer Refinement

Capture Customer Focus Variable in CRM

C

Locate Value Gap

Product Vision

Assessment & Validation D

Rapid Prototype Customer Refinement

Study Online and Off-line Behavior Determine Attitude Profiles

Apply SDLC or Object-Oriented Development Practice

Gate for Strategic Assessment

Concept (10)

Implementation Core Competency Assimilation

Balanced Scorecard

Behavioral Change Business case

Continued Improvement

HCI

Company Investment

A: Concept Stage (Rapid Market Assessment) The process starts with a concept or product vision from the marketing or management team. They are immersed in the market and study the competition, technology, and the customer and will create new product visions. In the software business this is a never-ending process and results in many concepts with passionate champions. The initial product vision is tested with customers with a simple process called rapid market assessment. Early customers are essential to validate, develop and enhance a vision, but will not see the industry broadly enough to create it. While the best technology products usually start with a strong “pull” from a business solution, it is rare for complete product ideas to come from the visionary customer. Potential customers may be interviewed, or sent a short survey that lists product features and benefits. There are few facts regarding the important issues, and little hope of definitive answers, but it is important to test the concept quickly


164 Le Clair

with a large set of potential customers. The key here is to survey a reasonable number of target customers, because at the next phase you will tend to work with fewer companies and have fewer data points.

B: Research (Value Gap Discovery) It should be obvious, but if you do not find anxiety or pain in a customer and do not help relieve the root causes of either, then your solution probably has no value. The goal of the research phase is to study the customer’s current behavior to discover this anxiety or pain. There may be many aspects of the customer that are worth learning about but pain or anxiety is by far the most important. This is why is it a primary focus in this framework. Perhaps the strongest aspect of this phase is the intensive interaction with a target customer to address the socio-technical issues. Figure 9.2 shows how our process interacts with the customer. As shown the greatest customer interaction occurs in the research phase. Here we use the techniques of previous chapters to study the customer’s behavior with a focus on pain and anxiety. These included ethnography, human factors and human computer interface (HCI) design. Value gaps will emerge from this study. At the end of this chapter we describe an interaction of a software company with a major financial services customer. It is a case where customer interaction early in the product development helped shape an enterprise product. Before we discuss how to find value, let’s contrast the software business with the biotechnology. This makes the point that there are few “must have” products in the software business and the software company in the end must manage a value-exchange ratio. It is sometimes said that a value proposition requires having something the customer cannot live without. Providing water to stranded people in the desert, for example, would qualify. Unfortunately for enterprise software there are few value gaps this dramatic. In almost all cases the customer is limping along with some system that meets critical requirements. So pain and need are matters of degree and, as proposed throughout, more of a “value exchange ratio” comparing economic, behavioral, and implementation discomfort with perceived value.



165

Figure 9.2. Customer interaction with revised product management approach Concept (Rapid Market Assessment)

Customer Interaction

Research (Value Gap) Initial Development (Prototyping) Assessment and Validation

Product Development Time

Biotechnology, by contrast, has the ability to develop a “must have” product. Genetics Institute (GI) is now part of Wyeth, one of the largest pharmaceutical companies in the world. As an emerging biotechnology company, GI was the first to develop two synthetic blood clotting factors for hemophiliacs that met the “must have” criterion. Hemophiliacs can bleed uncontrollably due to genetic deficiency in a clotting factor. Since the 1960s, they depended on “factor preparations” that were isolated from blood. As a consequence, more than half of hemophiliacs became HIV positive as a result of treating their disease. When GI’s synthetic clotting product was approved for marketing, it allowed hemophiliacs to avoid the terrible dilemma that treatment for their bleeding disorder confronted them with. Synthetic hemophilia factors now dominate the market, and represent a clear case of a “must have” product. But this is type of instant dominance is rare in informative technology. There are few “must have” occasions. The key task is to find and manage the value exchange ratio.

Finding Value Gaps Figure 9.3 shows the value gap caused by the customer’s struggle to cope with growth in their business. This is the most common value space for the emerging company to pursue (Heiman et al., 1998). In this chart the bottom line is the level of transactions the customer’s business can support today. The dotted line shows the number of transactions that will be needed. The discrepancy between the two lines is the growth value space for the emerging company.


166 Le Clair

Figure 9.3. Growth value gap (Adapted from Miller Heiman Strategic Selling 1991)

Required Transactions, Scalability Value Gap (Growth)

For enterprise customers the value space is created by growth in the customer’s core service offering. This growth leads to the need for greater capacity, more transactions, higher throughput, processing bandwidth, or simply a new more scalable way of doing business. It is about doing more, or doing it better.

Pain The present is always more clear than the future. As a result current pain is the easier to spot than concerns over meeting future growth needs, when studying human behavior. It is likely to be economic, legal, strategic and experienced by the user or organization every day. It will be evident in their behavior. Figure 9.4, The pain value gap, shows this second potential area for value discovery. The bottom line shows an acceptable pain level for the customer. The top line shows the growing level of pain the customer is experiencing. Again, a substantial discrepancy is required for a value space to develop. The pain value gap is very different from growth. Here the customer is not trying to improve a good situation, they try to avoid something really bad. It is the need to fix something, and the greater the problem the greater the potential value of the software. The current Sarbanes Oxley market is a good example. The CEO and CFO of our major corporations are interested in staying out of jail. Section 302 of Sarbanes Oxley forces them to personally sign off on key financial disclosures and they must “attest to” documentation of governance and compliance procedures. Complying with Sarbanes Oxley requires extensive accounting, auditing and risk management work. It needs new software and implementation services to Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


167

Figure 9.4. Pain value gap ( Adapted from Miller Heiman Strategic Selling 1991) Pain

Value Gap (Pain) Time

manage compliance data and automate business processes. Corporations are in pain due to the amount of work and strict deadlines. In 2004 corporations will spend $5.5 billion on consultant and technology dealing with this pain (AMR Research staff, 2003).

A Positive Y2K Problem The last great pain like Sarbanes was for the year 2000 date conversion problem. It is the classic example of an industry Value Gap created by pain. And never was more money spent so fast, while accomplishing in the end so little visible value. This letter received below is one of the most positive Y2K problems on record (ITS, Y2K 2001). From: Automated Payroll Processing Dept. Date: January 1, 2000 Subject: Vacation Pay Dear Valued Employee: Our records indicate that you have not used any vacation time over the past 100 year(s). As I’m sure you are aware, employees are granted 3 weeks of paid leave per year or pay in lieu of time off. One additional week is granted for every 5 years of service. Please either take 9,400 days off


168 Le Clair

work or notify our office and your next pay check will reflect payment of $8,277,432.22, which will include all pay and interest for the past 1,200 months.

Patterns of Value Gaps A big part of the research phase is probing to find high value gaps. It is not enough to find one or two. Consistent gaps across companies are the goal and will tell you a potential business is possible. Finding consistent value gaps is only one step towards success, but without it, there is no hope. Once the consistent set of gaps is validated, the process moves to initial development.

C. Initial Development (Legitimate Use of “Vaporware”) Given the number of unknowns and the imperative to move quickly, it is impossible to plot out every aspect of the product or service before implementation. Once the consistent set of value gaps are validated at some level of confidence, an initial prototype is developed and shown to a variety of customers. With positive feedback and recommended changes to the prototype, a formal design and development methodology is now introduced. Using SDLC or an object-oriented design approach, all parts of the system can be identified. It is important that a design approach be introduced at this time so that the path to a “generalized” solution is started. Even though this prototype and product effort may be abandoned, it is worth incurring this overhead at this time, given the huge potential expense of producing a “custom” platform. At this time though, only prototype the first phase (a small increment) and bring it to the field. HTML modeling can he illicit requirements with a low level of investment. This prototype is only a shell with very little behind it. It may be a simple set of HTML screens but it allows the customer to shape the product in an incremental fashion. Small increments will keep resource investment to a minimum.



169

Introducing Formal Requirements Definition As the initial prototype is introduced into the field a marketing requirements document (MRD) should be started as part of the SDLC or object-oriented design approach selected. An MRD records customer requirements and updates them, as the new product features are understood. The MRD provides a document to validate requirements and provides a guide to development on what to build. The MRD will ultimately form the internal contract between Product Marketing and development on what the new product or service will do. It should have a versioning component. To document when a requirement changes and why. The Appendix includes a template for the MRD document. An MRD can be more powerful if it distinguishes a requirement from a solution, a common error in requirements analysis. The requirement is the desired result. The solution is how we get there. This abstraction is important. The developers who build software are creative and inspired. A strong requirement will allow the software development to review several paths and solutions. Your lawn can provide a simple example. A properly stated requirement might be “to keep grass to a height of four inches or less”. We all know a lawn mower is the best solution and might want to say “ the requirement is to mow the grass before it gets to high”. Stating in the former way is clearer and more flexible than this. Why restrict the solution to a lawn mower. You could use a pair of scissors and an army of workers and meet the requirement. You could plant a slow growing grass and reach a permanent solution. The requirement is best stated as a business goal that leads to a strategic objective. In this process, requirements can be gathered directly in the selling stage. One of the largest expenses of building software companies is the sales force. Why do we not explicitly use them to shape the product? Why do we not use the CRM system to capture customer input in the field? This can be added to the sales management and marketing communication function it was justified on. The normal “demo process” is simply made more formal by using the CRM for requirements documentation, and being sure a socio-technical perspective is used.

Applying Socio-Technical Principles You need information from the potential customer to overcome the sociotechnical challenges described throughout this book. The behavioral change Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

170 Le Clair

map of Figure 2.2 can be used as a starting point. The customer can help you get it right and understand the relationships among the components that make up their environment. The software companies view can then be to optimize the full system, not just the software. While showing the prototype to the customer you will have their attention. Instead of becoming completely absorbed by the demo, use the energy in the room to ask about the current organization. Probe the customer to get an understanding of the roles and tasks of the users, and the relationships among the affected departments and how these are likely to change with the new system. Use the attitude template of Figure 2.3 to understand the likely attitudes you will face during initial deployment of the software. These socio-technical aspects of the system will be overlooked unless made an explicit part of the design process by including them in the MRD described above. Parts of the MRD template, shown in the Appendix, include sections for socio-technical requirements for roles, skills, group functioning, attitude, careers and tasks. These issues all can translate into specific system features that will make the product fit better with the customer’s organization. By putting them in the MRD and mapping them to important system features you will guarantee they are addressed. Why do we not have a process to formalize the collection of this type of customer information? Input screens can be developed in the CRM system to capture data about implementation, behavioral change, or assimilation issues. You can, in effect, build a socio-technical library that can shape your product.

Leveraging Prototype Feedback The prototype process should get feedback from a range of customers. Early and late adopters should be identified. Prototype feedback can be obtained from a mix of selling and pure marketing meetings. Sales meetings try to get an order for the system. In the early days of a software company this means selling a vision, and is often referred to as “missionary work” since most of your time is spent educating the customer or anyone else who will listen. The solution is presented as if it exists, and in fact, part of it probably does. Another part may be in development, and some other part may appear someday if a customer will pay for it. The sales presentation will uncover objections that will help measure the exchange of value. They will provide data to measure the five customer focus Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


171

dimensions. Implementation hurdles will be raised. Thorny transition issues will come out. The amount of customer resources and internal costs will be uncovered. The amount of behavioral change required by the customer will be clear. You will know whether the customer has the skill and infrastructure to create the solution. The selling meeting will give you the harder set of objections to the solution and are invaluable (Ryan, 2001). It is also good to have a smaller number of “pure marketing meetings”. The customer will speak freely about their concerns and issues without the pressure of “being sold” something.

A Failure of Documentation and Feedback Software companies can improve by doing a better job of capturing this information and feeding it to the product development process. Two individuals are always better than one to document the sales and marketing meetings and as stated, it is a good idea to record client feedback in the CRM system. This way a consistent set of data will be captured. A large amount of intellectual property is lost by not having a simple way to record the client’s comments. Initial meetings will gather feedback, which will modify the prototype and hopefully move the process towards closure. Listening to the customer is key, but feedback must be continually checked against the value variables and other target customers. Over time the product will take shape as the prototype is modified and hardened by each client interaction and eventually you will find that “anchor customer”. You are now ready for assessment and validation.

D: Assessment and Validation (Tying Balanced Scorecard to the Customer-Focus Variables) Assessment and validation is the final phase of the process and really should never end. The suggestion here is to set up a process of continual improvement based on the five customer-focus variables. The BSC approach described previously can help measure and monitor behavioral change, implementation difficultly, customer core competency, assimilation and business case elements.


172 Le Clair

They are perfect candidates for the BSC approach whose value is building bridges between the highly conceptual and the actionable. David P., one of the creators of the BSC, was recently interviewed. “How you create value is like a recipe. You have to put together several ingredients. Training your people is only one ingredient. You also have to give them computer systems. You have to give them incentives. You have to give them leadership. It’s impossible for a financial system to describe this process of value creation. Financial systems are always snapshots: they ca not describe a time-based logic of cause and effect. They ca not integrate different kinds of assets into what I would call a strategic recipe. That’s why you need something different. That’s why the Balanced Scorecard has become so popular with organizations.” (Daun, 2002, p. 11) Once a value scorecard has been developed for the customer-focus variable, it serves as the organizing framework for continued improvement. During validation each customer-focus variable is viewed as an objective within the BSC framework. Creating a “recipe” as described above, for each will ensure a comprehensive treatment. For example, the primary characteristics of Chapter III can be linked into a recipe for assimilation as shown in Figure 9.5. With the BSC approach, the management team can identify performance goals for each assimilation characteristic shown in Figure 9.5. With this approach, intangible concepts like “observability” can be linked to specific progress milestones to measure progress against goals. In a similar manner, the socio-technical aspects of attitude and organizational disruption of Chapter II can link into a recipe for a Behavioral Change Scorecard. Implementation difficulty can be monitored as well. This would require linking the S/L ratio, product adaptation strategy and training approach into a recipe. This approach will help focus on important characteristics for success. It will also set up a framework for continual monitoring and improvement. Perhaps, most importantly, it will help close the implementation gap between the hard and soft sciences.



173

Figure 9.5. Assessment map for assimilation Assimilation Observability

Trialability Value Gap

Ease of use

Complete Process

Bridge/Legacy

Case Studies The following case studies are provided to support the validity of the framework described. Prototypes are first discussed from several perspectives including how they can help control the sales process, how they can help win business, and their value in human communications. Secondly, a case study shows the importance of working with sophisticated customers to shape a new product. This case study shows why having a rapid feedback loop with the customer is essential in the early development of new solutions.

Controlling the Sales Process when Using Prototypes: The Pearly Gates The approach to selling enterprise solutions is interesting. On the one hand your sales representatives need the normal strategic selling skills. These can be reinforced through strategic selling courses like Miller-Heiman that are tailored for complex customer environments (Heiman et al., 1998). And on the other hand, the sales person needs technical knowledge and the ability to reason conceptually. These are rarely found in the same individual. Too often companies equip poorly trained salespeople with PowerPoint slide decks that convey very little information. The salesperson is not equipped to understand the interdependence and scope of the customer’s systems. The exchange is often light and not focused. I have heard it said the difference between a used car salesmen and a software salesperson is that the former knows when he is lying; the latter cannot make the distinction. One way to help with this problem is to use a prototyping to make the sales process more concrete. It takes some discipline to do this but it can be very effective. An old high tech joke makes an important point.


174 Le Clair

A man had passed away and was confronted by Peter at the pearly gates. Peter asked whether the man would prefer to go to hell or to heaven, and the man being analytic by nature, said, “I don’t know, I know little about either”. Peter looked down at him and said, “Lets take a look”, and punched up a video of Heaven. The video showed some very bored people sitting on clouds with sad looks on their faces. Peter then moved to a second video, which showed Hell. Here was seen a nightclub setting with a very hot jazz band. People were dancing, talking and having a great time. “Well”, the man said Hell looks like a lot more fun, I’ll go there”. “So be it”, said Peter, and sent the man to Hell, which turned out to be fire and brimstone and miserable. Some time later the man got a message to Peter. Why was Hell so different from the vision he had seen? That was our demo, Peter replied. Prototypes and demos can be dangerous and misleading to clients. But when used properly they can provide discipline to the sales force and make up for inadequate product knowledge. The important rule is to never put anything in the Prototype that cannot be delivered to the client.

The Word is Not the Object: Why Prototypes Work Prototypes work for the same reason that a picture is worth a thousand words. When a customer views a prototype of the application, they are able to visualize how it will help them in a real and concrete way. Words are misleading and generally poor way to communicate technology. In the 1930s, a Polish count, Alfred Korzybski, wrote a book called Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics. The 800-page tome is nearly unreadable except by scholars, but the concepts for human communication are powerful and started the field of



175

“general semantics”. These concepts are actively debated today and are relevant for product development. The most important statement from general semantics for product management is, The Word is not the Object. When a word describes a thing, it cannot designate what the thing is. The word is only a symbol, like a map, which describes a territory. Just as no map can actually be the territory itself, no word can be the thing itself. General semantics argues that the word is a flawed device for communication. Korzybski and his followers believed that humans spin enormous webs of words and get mired in symbolic nets due to the structure of language. Communication surrounding the software development process is a symbolic net of vast proportion. Today, words are the primary means to describe systems that do not yet exist. They struggle to describe how humans and business processes are affected by the new system, particularly when the system changes the human approach to accomplishing a task. Words on paper or in oral communication are just not up to the task. For example, one person may dislike or have an allergy to peanut butter. The words “peanut butter” in their mind conjures up negative and perhaps nauseas feelings. Another person may love peanut butter. When hearing the word they may experience warm images of eating sandwiches as a boy in their grandmother’s kitchen. The point is that the same word can lead to very different impressions. The more abstract the thing being described is, the bigger the problem. Defining product requirements for enterprise solutions is as abstract as they come. Prototypes can communicate much better than words. Words are useful in the marketing requirements document, which is a contract between marketing and development. But for determining what to do, the prototype is superior. Let’s look at a real world example.

Prototypes Make the Point at a Major Credit Card Processor Prototypes tell a story. The story of how someone will use technology to make his or her life better. Great communicators understood the power of storytelling. Ronald Reagan used simple stories about people to make huge political points. Jesus did not give people a set of rules to follow. He told them a series of stories. If you are trying to make a point, the best way is through a picture, an example or an antidote. It is one thing to use quantitative descriptions to customers Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

176 Le Clair

concerned about system reliability as in; the system will be 99.99% reliable. It is better to create a vision of the customers experience after adopting your solution. To have the customer imagine himself on a vacation, sitting on a beach, drink in hand, without a care in the world for having adopted your reliable system. The latter is the more powerful description. In the same way, the prototype is an image-based method of communication. It paints a vision, and is superior for conveying the potential of the emerging application. A major enterprise software competition with a major credit card company is an excellent example. The software company was an unknown player with little chance to win and there were ten bidders in the hunt. All had existing business with the customer and had strong enterprise credentials. The software company lacked both. If it had not been in Florida during the winter they might not have bothered.

Being on the Same Page as Your Customer The goal of this project was to build a statement archive and presentment system to solve two major problems: Provide an exact view of the credit card statement in the call center, and provide a new solution for statement reprints. The credit card processor was feeling pain in their expanding customer service center. This center had more than 2000 associates answering phones. Each associate had one or two years of college on average and solved problems with a complex set of mainframe and UNIX applications presented on SUN workstations. Pain occurred when a customer called in to discuss their statement. The associate could not look at the same statement the customer was holding. The customer had a richly formatted paper statement with page numbers and marketing notes. The associate viewed a transaction file that had most of the content. When discussing the statement they were literally on different pages. The conversation might go like this, Customer: Hello… “Can you tell me what this $4.75 finance charge is on page 3? I’ve never seen it before”.” Associate: “Sir, my computer screen does not show page numbers. Can you tell me what the charge is for.”



177

Customer: “If I knew what the charge is for I would have saved the dime. It’s next to the chart.” Associate: “I can’t see the chart. Tell me. Is it towards the end of the statement? Oh. Here it is. Sir it’s been on your statement for several months running”. Customer: “I find that hard to believe. Get my July bill. I’m sure it’s not on that”. Associate: “I have no access that far back. I can make a request to the records department. It will only take 4 days”. Customer: “Never mind. Just forget the whole thing.”

The Random Statement Generator A second area of pain was in the mundane area of “statement reprints”. It’s hard to believe how many people misplace their credit card statements. But each day there were thousands of requests for “reprints” to send to customers. These customers had already received their statements but they lost them and were entitled to another copy. While this may seem like a simple problem, it was not is this case. Once the original statement was printed and mailed, the electronic version of the original was thrown away. To generate the required copy the credit card company maintained a duplicate statement system that would recreate the statement from the original transaction file, that is, the mainframe system. It is unfortunate that all systems have some error rate and the duplicate statement process was no exception. It sometimes, in fact, created a perfectly fine looking statement with different totals from the originals. If customers knew this and were feeling lucky, they might keep requesting “reprints” until they got a lower balance. This created exposure for the company plus the cost of maintaining a second statement system. The proposed statement archive system would retain the original electronic print file and would generate the same paper version sent to the customer. In this way, they could eliminate the costs of the duplicate system, and eliminate the potential errors.


178 Le Clair

The Competition The credit card companies project manager gave all competitors a sample file of one of their statements. This was given only to software companies developers who was absorbed at his Sun workstation. He was asked to create a mock-up or prototype of the call center application. It took four hours of inspired work, but in the end his prototype showed a replica of the credit card statement integrated with a mock up of their customer service agent’s session. He had been able to display the statement and this small task was a major achievement. He substituted postscript commands for the proprietary IBM descriptors. The Sun workstation could now display the paper statement electronically. The next meeting with the customer was the type most people hate, but entrepreneurs live for. It was the “bake off” between vendors, each with an hour to make their case, with millions of dollars at stake. A major hardware vendor was a player in the general purpose UNIX-based systems market and the software companies alliance partner. Basically, their software application ran on their hardware. They sent the hardware supplier email and said it was important to have a Sun workstation in the room so the prototype could be demonstrated. At arrival, however, the partner neglected to make this arrangement. They thought it was nice but not important but as found out later, they did not want to showcase a hardware competitor’s platform. Not to be denied, the software firm disconnected an unknowing associate’s workstation and rolled it into the conference room. Instead of PowerPoint slides, they showed the prototype on their target platform and heard ohs and ahs. They were the only company to show a prototype of the application with the statement displayed and won the contract They were the first to the market with a statement archive and presentment solution for IBM’s new printing format that would later dominate that niche. They never got to the slide deck, and spent the meeting working out implementation details (Le Clair, x).

The Value of Early Customer Involvement at a Major Brokerage House Emerging products can benefit from involving the customer very early. Early large customers must be responded to and will help shape the product. Here Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


179

is an example involving a large sophisticated customer early when combined with an incremental and responsive process. The U.S. Financial Services industry is drowning in paper. This has created a multi-billion dollar market in document management and related software services. An emerging software company was trying to break into this market, largely through a great opportunity with a major Wall Street brokerage firm. The brokerage company was one of the largest financial services firms in the world. Focusing on the affluent investor, they provided investment advice and wealth management services to more than three million individual clients. The brokerage firm realized the potential savings and customer service advantages of sending their monthly brokerage statement electronically. In the first phase, the e-version would replace the paper statements going to the branches. The branches needed the paper copy to speak with clients about their account. It would be the first company to eliminate branch copies in the industry using Internet technology. The software company had spent nine months presenting their solution to the large numbers of stakeholder, which included IT, operations, the retail brokerage group. Progress towards the sale was being made. The solution had overcome the five customer obstacles; there was a strong business case. The solution eliminated the shipment of paper statements to thousands of branch offices. There was a short implementation time. Months before, a test version was installed with graphical administration tools to help with the task. It was being certified to roll out with the next major branch upgrade. The brokerage company had no domain expertise in this segment of document management so there was no conflict with their core capability. The only concern was behavioral change. The full service brokerage house had very mature brokers with classic relationship-based business model. In particular, the head of the Retail branches had concerns with eliminating paper. He had worked his way to branch manager, regional manager, and now was head of one of the largest broker networks. In his mind success had little to do with technology and everything to do with personal contact. He felt the brokers in the field would not give up receiving the paper statement and allow an electronic version to replace it. He felt his brokers lacked computer skills. In short, the demographic was not perfect for browser access to information. Fortunately senior executives at the firm were pushing the project and saw a potential savings of millions of dollars a year.


180 Le Clair

The software company had worked on this project for nine months and thought they had won the seven-figure project that would put them ahead of the market. But as it always seemed, there was one more checkpoint. They had to meet with the computer architecture group who wanted to be sure the product met internal standards. They entered the land of UNIX systems with SUN,IBM and HP test servers everywhere, and were greeted by a longish haired 30-year-old half way through a box of donuts. He was also playing with a yoyo. They started to present the solution using a white board and showed the database, security, storage and network architecture, but were cut short and told with little emotion, “It doesn’t work. You’ll absorb most of our network bandwidth to the branch and cause poor performance for our users.” The group was stunned. The team had worked hard for months on this project, the most promising application for the company. After some prompting they were told why their product was incompatible with the customer’s technical environment. At the time, the brokerage company had only 64 KB data communication lines from each branch office to the data centers. When a broker logged on in the morning the solution sent “directory” information over this low-speed branch network. The directory information provided the storage location of the broker’s copy of the statement. Between yoyo pulls, they were told that when thousands of brokers logged on between 8 a.m. and 10 a.m., the solution would negatively affect the network. The software supplier called the home office and gathered the top developers together who always have a classic response to technical crisis such as,“According to our calculations, the problem doesn’t exist.” True to form, the team did not disappoint. The lead software developer was defensive, saying, “The product’s architecture is not the problem. Tell them to upgrade their network bandwidth to their branches. They need to step up.” Upgrading the communications bandwidth from that many branch locations would add millions of dollars a year to the solution. But by 3 p.m. that day they had a different approach that solved the problem, one that did not require the initial loading of directory information. During this process the product design was greatly improved. Forcing a second meeting, the software company’s product was approved by the brokerage company’s architecture group and the software company was on their way. This example shows the way things sometimes happen. Not the way they should happen, but in many cases they way they actually do. Interaction with



181

sophisticated customers is valuable. This customer helped improve the product. All this was done within six hours (Le Clair, 1998).

Summary The Internet has existed as a widely available infrastructure for some time. Enterprise Software has made great strides yet we are still trying to figure out how the Internet can be used to add value for business. Small experiments are the best way, as science will tell you, to make advances. Rapid prototyping and incremental discovery is the best way to experiment. Software companies can focus on gaining small but real insights and build value slowly and steadily. The framework provided here does the following important things: • •

• • •

It explicitly recognizes the “search for value” process inherent in the enterprise software market. It involves the customer directly in shaping the product. This ensures the complete business solution and the customer-focus variables are addressed. It introduces SDLC or other development methods at an appropriate time. This helps avoid or shorten the “one-off” stage. It incorporates the customer-focus variables, that is, a socio-technical view directly in the process. It plugs into emerging strategic frameworks such as the BSC providing a way to continually assess and enhance value.

References AMR Research staff. (2003). Estimate of 2004 software and services for the Sarbanes Oxley Market. AMR Research. Dukart, J. (1999). Breaking the brokerage paper habit strategic vision (pp. 1315). Interview with Craig Le Clair.


182 Le Clair

ITS Y2K (2001). NEED Wouldn’t you like to work for this company? Retrieved January 5, 2004 from: www.uwo.ca Heiman, S. et al. (1998). The new strategic selling: The unique sales system proven successful by the world’s best companies. New York: Warner Books. Le Clair (1996). Case study: Credit card processing: Based on unpublished project notes from work engagement. Le Clair (1998). Case studies: Brokerage industry: Based on unpublished project notes from work engagement. Daum, J. (2002). Intangible assets and value creation. Chichester, UK: John Wiley &Sons. Interview with David Norton regarding the balanced scorecard. Ryan, R. (2001). Smartups. Cornell University Press. For more detail on these types of meeting see Bob Ryan.



183

Appendix A: Marketing Requirements Document (Template) Authors: Date: Version: Revision History Version 1.0

Date 11/18/03

Description Initial Draft

Revised By

Introduction Describe overall intent of product and the phasing and pilot strategy. 1.0. Definitions Define key terms. 2.0. Use Cases Describe Use Cases with reference to HTML Prototype screens attached. 3.0. Socio-Technical Requirements 3.1. Roles and Tasks # 3.1.1 3.1.2 3.1.3 3.1.4

Description Minimize new skills required Guided application for skill enhancement Capture existing on-line and off-line behavior in new system Provide cross-training curriculum to minimize gaps among tasks

Source

Priority


184 Le Clair

3.2. Group Functioning # 3.2.1 3.2.2

Description

Maintain reporting and communication within and among groups Provide additive reporting for management

Source

Priority

3.3. Careers and Status # 3.3.1 3.3.2 3.3.3

Description Enhance professional development (all effected departments) Enhance status (all groups) Provide “process” view of training to build spirit of “ownership”

Owner

Priority

3.4. Attitude # 3.4.1 3.4.2 3.4.3 3.4.4

Description Observability Trialability Enhance perceived usefulness above current system Enhance Ease of Use through HCI study

Owner

Priority

4.0. Functional Requirements 4.1. Templating # 4.1.1 4.1.2

Description

Source

Priority

4.2. Administrative Features # 4.2.1 4.2.2

Description

Source

Priority

4.3. Sorting, Searching, and Filtering # 4.3.1 4.3.2

Description

Owner

Priority

4.4. User Features # 4.4.1 4.4.2

Description

Owner

Priority



185

4.5. Users Interface # 4.5.1 4.5.2

Description

Source

Priority

4.6. Back Up and Recovery # 4.6.1 4.6.2

Description

Source

Priority

Source

Priority

Source

Priority

4.7. Reporting # 4.7.1 4.7.2

Description

4.8. Security # 4.9.1 4.9.2

Description

4.9. Audit Trails, Display, and Reporting # 4.10.1 4.10.2

Description

Source

Priority

Source

Priority

4.10. Import/Export # 4.11.1 4.11.2

Description

4.11. History # 4.12.1 4.12.2

Description

Source

Priority

5.0. Open Issues


186 Le Clair

Chapter X

Strategic Assessment

“There is only one way out – and that’s from within.” Leo Wrye Having a strategy and sticking to it is difficult for enterprise software companies. They can apply their skills and technology to many business problems and they are hunting in growing markets. Almost any pursuit can be declared “strategic” since it could lead to something big. Think of the problem in this way. The firm’s people are highly motivated. They have technical and business skills that can innovate in a number of areas and can do it quickly. The world is a playground of potential opportunity. The challenge is that the company has limited resources and time. It ca not pursue all options and it must select the right ones. In new product development it is said that one commercial success results from one hundred new products generated (Eccles, 1992). And as we have seen, development of the killer value proposition is difficult; time consuming, and not a sure thing. It is therefore prudent for the emerging company to pursue more than one opportunity. This is the reality of developing new solutions for emerging markets. A clear strategy is undermined by several recurring themes:



• • • • •

187

The inability to focus on core value drivers The difficultly of saying no to revenue opportunities A blurred view of the market and competition The need to diversify due to rapid change and poor data The level of uncertainty in emerging markets

As if this were not challenging enough, the emerging company is not certain about the markets they operate in. Is this market forecast correct? Is the market valid? What value will be placed on a software company in that market? What products or services will be the most desired in that market? How do we select the correct products and markets to pursue? We first discuss strategy and vision in general to provide some perspective. Then we introduce a strategic assessment model. We then use to assessment model to look at how the company that designed the Internet lost the data communications market to Cisco systems.

The Vision Thing Much has been written about the need to have a clear vision when building a company. Raising capital demands it. The business plan will insist you know where you are going, how you will get there and when. Knowing where one is going always makes the ride easier. Yet, in early stages of a company, vision may hamstring the innovation required at the company. We just passed the 10-year anniversary of “Built to Last”, a six-year research effort that studied 18 of our most visionary companies. That research showed that only three of 18 visionary and successful companies began life with a specific, innovative and successful product or service idea. •

HP started with welding equipment, automatic urinal flushers and bowling alley sensors. For the first several years HP kept itself alive with contract engineering. But in the process it built general engineering capability, which prepared it for success, the calculator for the professional.


188 Le Clair

•

•

IBM began with time clocks and measuring scales and was almost liquidated before it turned the number crunching expertise to the general problem of tabulation. Sony had no founding product concept whatsoever only a vague idea to apply technology to consumer products. They struggled with failed rice cookers and stayed solvent selling crude heating pads. They gradually built up competency around “miniaturization” which ultimately produced the (pocket radio), the company’s first success (Collins & Porras, 1994).

A more recent study argues that innovation is not the function of a single vision from the genius inventor. But rather that innovation originates from leveraging a network of knowledgeable people and preexisting ideas (Hargadon, 2003). Successful innovation comes from pulling together these ideas in an incremental and serendipitous process. The point is that the big idea and “vision de jour” that technology markets obsess with are less important to a software company than incremental growth of valuable competencies. This argues to focus on the basics of what the company does well, and less on a single product idea and remain as flexible as possible. The average entrepreneur must attempt 3.8 ventures before they make a successful business (Urban & Hausen, 1980). For the emerging company whose strategy may change often before maturity, it is important to keep vision in perspective.

Thelonius Monk Developing new products for new markets is different than for mature products and markets. They differ in a similar way to how jazz and classical piano are approached. The classical pianist works from a fully notated set of music. Every note to be played is defined on the bass and treble cleft. Virtuosity is achieved by a complete mastery of a very difficult execution. The jazz pianist has a different approach. They play from a “lead sheet” that uses only a single melody note and one or two chord changes per measure to describe a song. The lead sheet is the executive summary of the song and contains the minimum amount of information needed to express the musical idea. The song is described in this basic way to provide flexibility to the artist. Jazz musicians choose their own “arrangement” (specific notes, timing and tempo)



189

and improvise around the basic framework provided by the “lead” sheet. The unique rhythms of Thelonius Monk, a famous jazz pianist, are achieved by the way his piano and drummer space their notes around and off the basic structure and beat of the song (Alfred, 2002). The best articulation of vision for moving into new markets is the “lead sheet” style, which, in this case, contains the software companies, definition of primary value drivers. It is what the company does really well and wants to be known for in the industry. It is the meat of what you are, as defined by your intellectual property, competencies, and value drivers that derive from their depths. Successful emerging companies improvise around that basic structure and theme.

Strategic Assessment The question is how many product initiatives to pursue and which ones. At all times the emerging company could pursue a dozen directions. Rather than being a symptom of poor discipline or lack of a concrete vision, this is normal and healthy. All the projects seem to make sense, but in fact they all do not and we shall see why. A simple framework can help you pick the best projects1. Using this framework a selected project should meet two criteria: • •

Leverage the value drivers of the company Have enough revenue potential to make the fight worthwhile.

Description of the Assessment Model Chapter IX showed a product development funnel with several products at the concept stage (A) and research stage (value gap) (B). To that point the company has researched the new product area but there has been minimal investment. The assessment model picks up at step (C). Here the company must decide to move the concept into a formal development process such as SDLC.


190 Le Clair

At regular intervals senior management will plot potential initiatives against the two axes shown in Figure 10.1. On the vertical access is a measure of the company’s value drivers, that is what the company does best and what is most unique in the marketplace. It is the basis of technological and application expertise in specific aspects of their value proposition (Treacy & Wiersema, 1995). One the horizontal access is the potential revenue from the product. The further out this axis a potential product is plotted, the greater the revenue potential. The company gets into trouble when it picks projects with low revenue potential. It may be a great fit for the technology, but may never generate enough revenue. This is the upper left part of the chart. Equally bad is picking a project that turns the company towards a booming market, but is too far a stretch from their value drivers. This would be the lower right. The software company may never achieve success in this pursuit. They my lack the underlying skills to compete over time. Product opportunities in the upper right are the best for the company to pursue. Here the product has high revenue potential and maps to what the company does well. Given the importance of plotting projects correctly, a detailed description of “value drivers” and estimating revenue for a product are now provided.

Distinguishing Between Value Drivers and the Value Proposition The value proposition is visible to customers. It is the strategy that a company selects to differentiate its product and services in the market. Michael Tracy and Fred Wiersema (1997) proposed three categories of value. These were operational excellence (meaning lower cost), customer intimacy (meaning excellent service), and product leadership. They found that successful companies focused and excelled at one of these. They beat competition on only one of the three dimensions. In enterprise software terms, a document management supplier might take a low-cost value strategy. It may run the product on the low-cost Microsoft NT platform with few outside licensed components. The value proposition may be to: Reduce the cost of document storage by 20% through use of existing and low cost infrastructure.



191

Figure 10.1 Strategic assessment model

Stronger

Can Get There but Why?

High Potential and it Fits.

Relative Fit With Emerging Value Drivers Weaker

What were we Thinking?

It’s just not us.

Lower

Higher Revenue Potential

Another document management provider may run their application on high-end hardware and offer all possible features including collaboration, digital asset management, electronic records management, and so on. It may have the following product leadership value strategy: Provide a complete and integrated suite of content management technologies The value driver, on the other hand, is a step removed from the customer value propositions above, which define the company’s market strategy. Value drivers are not always visible to the customer in the same way the value proposition is. For example, they may involve a technique for high-volume archiving, or advanced compression algorithms that allow the lower cost to be realized. It may be a method to efficiently manage many versions of complex documents, or a low-cost way to link documents together. Value drivers could also stem from the background of the key technical staff. They may have mathematics and information science backgrounds and be strong in developing algorithms. Perhaps the CEO, as in the OpenPages case study, has a background in auditing, that argues well for developing compliance products. The challenge is to locate and continually refocus and realign the company’s activities around what the company is good at. It boils down to common sense. Companies, like people, achieve success by focusing on their strengths. They focus at all times on what they can do well and not what they do poorly. The best bet for the emerging company is to experiment relentlessly, but do it around strengths. These simple questions identify the value drivers of the company: • •

Which aspect of our products or services are the most distinctive? What is the company known for today?


192 Le Clair

• • • •

Which are the happiest customers and what do they say is the most distinctive quality of your service? What is the most profitable segment of the business? What technology does your technical staff know the best and is there a pattern to what they know and where they came from? How would the Intellectual Property of the company be described and possibly patented?

Using Value Drivers for Sustainability The projects a company pursues should map to value drivers. It is fundamental to be competitive, and to sustain competitiveness. It is harder for a rival to match a linked set of specialties than merely match a particular software feature. Specific domain expertise, proprietary software, databases or a business process patent are tough to beat. The competitor may identify your important value linkages but they will have difficultly pulling them together in a cohesive service. This is due to the way software-based solutions evolve over time. They are shaped by a growing knowledge base and interaction with the customer. The more the solution stems from the soul and inner depths of the value drivers the more sustainable the solution will be over time. They provide a platform to further innovate and maintain a competitive position.

Determining Revenue Potential: The Difficulty of Market Assessment The revenue opportunity is on the horizontal access of the strategic assessment model. Determining potential revenue for a product is difficult. The discussion below will point out common issues faced in this challenging task.

The Humongous Market Investors, emerging companies, and interested parties fall into the “humongous market” trap where large estimates of potential market numbers influence Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


193

strategy. However, the fact that a market is estimated to be huge may not be relevant to the product you are evaluating. The hardware, software and services in the estimate may not be obtainable for your product. The focus needs to be on the reasonable available market. There is no shortage of market size estimates from external analysts but the portion available to the emerging product is difficult to derive from this. In addition, estimates from external analysts tend to be high for the following reasons: •

•

• •

Firstly, the new technology area being assessed is not defined well. There is little empirical data to drive estimates. In many cases, the very creation of the market being studied depends on success of emerging companies. Secondly, analysts make estimates from information provided by overly optimistic entrepreneurs. Analysts speak to a large set of vendors, but generally do not have a wealth of independently gathered research due to the market’s immaturity. Thirdly, the analysts are biased towards high market projections that tend to create excitement about a new market. Fourthly, the analysts often project growth without adequate understanding of behavioral change, implementation issues, and drivers for assimilation.

Even before the Internet boom, there were many examples of market estimation errors that affected billions of dollars of investment by new companies. Analysts in the early 1990s predicted widespread adoption of Integrated Services Digital Network (ISDN) in the telecommunications sector. This technology was going to bring cheap bandwidth to home and business but failed to assimilate with the legacy phone network The Internet boom was driven by wild estimates in e-commerce, supply chain management, content management and other markets. These were largely unrealized. The application services market (ASP) was one of the most dramatic. In 1999, the revenue from “off the shelf” application rentals for the ASP model was miniscule. Yet leading analysts predicted the ASP market would reach approximately $4.7 billion by 2004 with mass adoption of the outsourcing alternative taking hold beyond 2000 (AMR staff, 2000). This would have been staggering growth for a new technology market and one that did not happen. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

194 Le Clair

A Check on Analyst Estimates So how do you get reliable estimates for market assessment to base strategic assessment on? Often the best information is gathered from asking experienced people in the industry basic questions. Informal data are often dismissed too easily in the face of outside “validated” information. One check against humongous market estimates from industry analysts is a ground up approach. Add the total revenues from all of your competitors in the new market, and total them. No one can dispute that this is the current market or that it is relevant since your competitors are in it. Unfortunately, the market size is likely to be small and uninteresting. But then assume that half of the companies making up this market will achieve “hockey stick” revenue growth in the 50% to 100% range per year. Accumulate that number three years out. This will be a conservative and probably realistic market estimate. Models that use broad assumptions must be looked at closely. Most dangerous are those where small percentage shifts in behavior result in tremendous new market growth. The following are only examples: • •

Every 1% increase in consumer bills paid online will add $250 million of market potential. 97% of business information is stored in paper form. Every 1% movement to digital storage will result in $500 million of spending on document management and business process software and services.

There is usually a suspect customer-focus dimension. The likely candidates are behavioral change, business case, or implementation difficulty. In summary: • • • •

Validate industry analyst’s projections. Do not believe the estimate because it is what you want to hear. Focus on the market available to your company. Use ground up calculations to check the sanity of market numbers.



195

Using the Assessment Model Each new product opportunity needs to be mapped into the strategic assessment model. The assessment plots each active initiative relative to these two axes. The stronger the market opportunity and the mapping to value drivers, the higher towards the right quadrant of Figure 10.1 the project is ranked. Strategic assessment is an ongoing process. As new initiatives come up they are positioned and discussed. The company should invest in initiatives that fall in the upper right quadrant, where the level of obtainable revenue is the highest. It is in this area where the match to value drivers is also the highest. This framework provides a strategic filter that is flexible yet keeps management focused on highvalue emergent areas.

Case Study: Applying the Strategic Assessment Model Bolt, Beranek and Newman (BBN) is an excellent case study of the principles of strategic assessment. Thirty-five years ago they created the Arpanet, the forerunner of the Internet. Richard Bolt and Leo Beranek started the company in 1948. Both men were acousticians and members of the MIT faculty in the 1940s. The company started with a project to design the acoustics for the new U.N. building. From there, business flourished. They were called in after the assassination of John Kennedy in 1963 to determine how many shots were fired. The most famous audio analysis would come during the Watergate scandal in 1974, when they analyzed the famous 18.5-minute gap. A committee headed by Dick Bolt would conclude the erasure was deliberate (Hafner, 1996). During this time, BBN started various research projects in computers. One day, Ken Olsen, the founder of Digital Equipment Corporation, stopped by to tell them about a new computer he was building. He asked them to examine a prototype of the machine called the PDP 1. BBN took delivery of serial number two of the machine and suggested design changes. They would later buy the first model available for $150,000. This leading edge computer activity started to attract young talent. BBN’s human resources policy at the time was to recruit MIT dropouts. The theory Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

196 Le Clair

was that if you could get into MIT you were smart and if you dropped out you were cheap to acquire (Hafner, 1996). Larry Ellison of Oracle and Bill Gates of Microsoft would have been hired in a heartbeat. With this talent and perhaps attitude BBN positioned itself well for the coming explosion in computer activity.

Building the Internet BBN won a contract with the Advanced Research Product Agency (ARPA) in 1969. The task was to build the first packet-switching network called not surprisingly the Arpanet (Hafner, 1996). From old warehouses on quiet streets near Fresh Pond in Cambridge, Massachusetts, BBN designed the first widearea computer network. The network used the first packet switches called Information Message Processors or IMPs. This initial design conceived by an inspired group in a furious 100 days was the beginning of the Internet. I arrived at BBN in 1984 when the Arpanet had just passed 1000 connected computers. By the time I left BBN in 1990 the Internet had surpassed 100,000 connected computers and was on its way to reach the 100 million computers connected today. The critical knowledge of the Internet was still mostly resident on a few corridors in Cambridge, Massachusetts. Error messages during this period were always amusing. They were terse, baffling remarks used by programmers to place blame on users for a program’s shortcomings. They were likely to contain for the recipient the phone number of a bearded PHD that might offer some help. The technical staff driving this innovation formed a unique culture. They could do whatever they wanted and they did very good things. And no, I did not run into Al Gore during this period. Al used the word “invent” rather than “promote” when describing his role in the early development of the Internet. He was an advocate of the information superhighway and promoted Department of Defense funding for research at a time when it was much needed. But his choice of the word “invent” gave the impression of sitting with the “wizards” and writing software. The Republican PR machine and the media were then able to maximize his gaffe.

Our Tax Dollars Well Spent It is not everyday that the requirements of a government funded effort so perfectly match societies long-term needs. The primary requirement of the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


197

Arpanet was survivability so that military communications during hostile times could not be interrupted. The new network had to allow entire command centers and switching nodes to be destroyed without interrupting service. A decentralized design would be the only one that would survive such an attack. To meet this requirement, all communication “nodes” would have knowledge of available paths in the network. In the event one was destroyed, the network would automatically reconfigure itself, creating new paths to get the message through. Messages would be divided into individual packets to allow them to be broken up and routed over different the different paths. In addition, Host computers would need to be connected rapidly and without central administration in times of crisis. The decentralized design was exactly what was needed for future growth. The Internet has grown independently and exponentially from this initial design and continues unabashed. A recent patent was awarded to Lucent Technologies, the companies 30,000th to date. This patent was for a protocol that allows voice packets to have priority over other less real-time traffic, that is, data. The protocol receives information about bandwidth and capacity and allows voice data from conversations, to get very high priority. This clears the way for reliable phone calls over the Internet. We may soon have inexpensive ubiquitous voice communication around the world (Technology Review, 2004).

The First E-Mail Goes Unanswered In late 1971, Ray Tomlinson of BBN sent messages between two machines that were side-by-side in his Cambridge, Mass., lab. He sent messages back and forth from one machine to the other until he was satisfied that the program worked. The first e-mail message Ray sent was to the rest of his group announcing that network e-mail existed. He explained how to use it, including the use of the @ sign. Ray needed a way to separate the user’s name from the host computer name and stared at his keyboard until he spotted the perfect solution. The @ sign did not appear in anyone’s name and therefore it would be clear where the host computer and the individual’s name separated. Even better, the symbol meaning “at” had certain logic and wit about it. It was a brilliant solution and one that Tomlinson calls obvious. Now there was nothing to prevent the sending of messages out to the wider network. Tomlinson says he invented e-mail, “Mostly because it seemed like a neat idea”.


198 Le Clair

Ray wrote the first e-mail program in two or three weeks. He combined the internal messaging program of the host computer he was working on with an experimental File Transfer Protocol that he had written called CYYNET. This e-mail program became the “killer app” that led to the initial expansion of the Internet. Historically the first e-mail may be viewed along side the first phone call or the first telegraph message. BBN contributed to development of the Internet in many ways including: • •

In 1976 the first Internet router was developed and connected to the Arpanet. In 1977, the first version of TCP/IP was developed for a UNIX machine (BBN Web site, 2003)

BBN’s Strategic Meltdown It would be hard to blame anyone in particular. There were people plugged into the “wizards” and market trends to see the meltdown coming. They were drawing pictures that showed local area networks connected to gateways or “routers” as they would be called. These routers bypassed BBN’s X.25 networking products that were derived from the original Arpanet IMPs. They were too slow for LAN-to-LAN traffic that operated at Ethernet speeds. Accelerating the obsolescence, the telecommunications infrastructure was upgrading rapidly to digital services. These were more reliable. No longer needed were the sophisticated routing and recovery features in BBN products. These features were useful with unreliable communications circuits, but were a legacy of designing the Arpanet for a potential hostile military environment. But the few who understood were not in power. Highly successful executives with little grounding in the core expertise of the company now were in charge. They had no defense against strong presentations on alternate directions and strategies.

Ignoring Value Drivers No company was better positioned for the impending telecommunications and Internet boom then BBN in the early 1990s. Yet, during the critical phase of the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


199

telecommunications boom they were distracted. They pursued two initiatives that did not connect with their value drivers. The first major distraction was circuit-switching technology. BBN purchased a circuit- switching product line at the height of the “T-1” market. The killer application for these switches was connecting corporate telephone systems together, in effect creating private voice networks, and bypassing the traditional phone network. The ROI for installing a private circuit switched network was a short number of months. Those of you familiar with the telecommunications industry will know that circuit-switching technology has its roots in telephony or voice communications not computer connectivity or data communications. BBN had no value drivers in telephony, and while the market was large it would not have made it into the strategic filter, and proved to be a major distraction for the company. The second major distraction was a strong push towards IBM SNA data communications solutions brought in by newly recruited industry executives. Not only were there no value drivers in IBM mainframe solutions or the SNA networking protocols at BBN at the time, there was almost zero knowledge. In fact, the key engineers were threatening to quit if they were asked to learn or develop in what was perceived as legacy architecture. The attitude towards anything IBM at that time is best characterized by the following, What’s the difference between IBM and Jurassic Park? One is a fantasy theme park populated with dinosaurs, and the other is a movie.

What were the Value Drivers? At BBN’s core were technologies like UNIX systems, the Internet protocols, packet switching, artificial intelligence, computer simulation and distributed systems. It had built and put into production the first Internet router for connecting local and regional networks to the Arpanet. In various labs at the time it had next-generation routers in various stages of development. In other words, the strategic assessment model would have looked something like that of Figure 10.2., which shows the router technology as the most promising. As can be seen circuit switching technology and IBM networks ranked much lower. Even if the router market estimates were understated, as


200 Le Clair

Figure 10.2. Probable BBN strategic assessment (circa 1990)

Stronger

Router Market Airline Networks Network Management Systems

Relative Fit With Emerging Company Value Drivers

Circuit-Switching Technology IBM Networking

Weaker

Lower

Higher Revenue Opportunity

they generally were at the time, it would have rated higher than IBM networking or circuit switching on the basis of value drivers alone. The router market would later be the foundation of CISCO Systems growth to a multi-Billion-dollar company. BBN missed that market entirely and was out of the commercial data communication’s product business within two years (Le Clair, 1990).

Summary The Strategic Assessment model will help identify to senior management projects that otherwise may not surface. In this case study BBN had nextgeneration router technology in various stages of development but it was overlooked. The winning idea may be one of many ideas floating around the company. PowerBuilder is now part of Sybase, and produced a very successful development platform for the client/server architecture in the early 1990s. This product was not the major thrust of the company, but an internal tool used by the software team to make application development simpler. The company had limped along for years, before it happened to discover this internally developed application.



201

An entrepreneurial culture will allow some non-disruptive level of projects that result from individual initiative. The assessment model allows all projects to be reviewed by the management team and compared with all opportunities.

References Alfred, A. (2002). Jazz modernism: From Ellington and Armstrong to Matisse and Joyce. New York: Alfreda A. Knopf. AMR Research staff. (2000). Enterprise Applications Service Provider Report, 1999-2004. Boston: AMR Research. Eccles, R. (1992). Beyond the hype. Harvard Business School Press. BBN Company Web site. (2003). Internet time line. From the The Internet Time Line: BBN Home Page. Retrieved March 5, 2003 from: www.bbn.com Collins, C., & Porras, J. (1994). Built to last. New York: Harper Collins. Hafner, K. (1996). Where wizards stay up late: The origins of the Internet. New York: Simon and Schuster. Hargadon, A. (2003). How breakthroughs happen. Boston: Harvard Business School Press. Le Clair, C. (1990). Validation interviews. This case study draws from my own experience at the company. It was validated with references sited, and interviews with BBN employees. Staff. (2004). Five killer patents. Technology Review: MIT’s Magazine of Innovation, May, 67-69. Treacy, M., & Wiersema, F. (1995). The discipline of market leaders. Reading, MA: Addison-Wesley. Urban, G., & Hausen, J. (1980). Design and marketing of new products. New York: Prentice Hall.

Endnotes 1

The assessment model draws from the strategy discussion in The Discipline of Market Leaders (Treacy, 1997).


202 Le Clair

Part III Management Issues in Value Discovery


Organizational Issues of Emerging Companies

203

Chapter XI


“Computers are useless. They can only give you answers.” Pablo Picasso Your business is based on great ideas. You and a very talented team of engineers and business people are trying to figure out how to translate these ideas into products and a business. You know there’s a definite market for your product because you have already sold it. You’re starting to get some free press and more interest than you know what to do with. Now your company is on the brink of making the turn from emerging to mature. Most successful enterprise software companies have been at this stage of development at one time. How they handled the myriad of decisions that face them at this point determines if those firms go on to be the next Oracle Corporation or become one of the many hundreds of failed ventures. What exactly is this stage? It is too easily identifiable: •

It’s the one where everything is going on all at once and it all seems worthwhile to be doing.


204 Le Clair

• •

•

• • •

Software developers are frantically trying to support early customers. There are new people joining routinely who need to be trained, but there is not much information to train them with. The veteran employees can not get to their critical set of daily tasks and no one has had time to write down what needs to be taught. Business development activity is furious and just when you think you know what the business direction is, something comes out of left field as better, or one of the prime assumptions of your strategic logic is shattered. The strategic positioning that seemed right two months ago is only now being propagated in the press even though it has been greatly modified. The value proposition is not solid; the complete product required for a sale will not exist for months. The Chief Financial Officer (CFO) spends a lot of time behind closed doors.

Entrepreneurs are free spirits. Their companies try assorted projects, bring new solutions to market with pioneering customers and continually explore and validate their value. But because the goal of the emerging initiative is to become a mature one, a scaleable set of business processes is required. Varying degrees of process will need to be imposed in sales, marketing, product development, and administration, as the company grows. This chapter discusses what these processes are and outlines the primary tensions, and the changing roles of sales, marketing, and development. There has not been extensive research on how a small entrepreneurial organization should change on its way to maturity. This chapter is not intended to fill this void but rather to point out some patterns software companies in the enterprise market face as they attempt to scale. It highlights the blurring of standard roles and shifting responsibilities within them. Lets start by comparing the emerging initiative with a more established company.

What is an Emerging Initiative? The emerging company works in unknown markets, lacks history, organizational discipline, and faces uncertainty in the mission at hand. There is also a



205

Figure 11.1. Emerging company stages of growth Revenue

Scalability and Growth

50M – 200M Early Growth 10M – 50M

0 – 10M

Initial Funding

Maturity

strong sense of urgency, motive, and competitive sprit that are necessary to breed the culture required to innovate and succeed. However, the lack of discipline and instability can be managed much better than they are today. The first step is to recognize the conflicting tensions that exist. The principles described in this book apply to all companies in the enterprise software business, but they are perhaps the most relevant for software companies in the early growth stage developing enterprise software in a new market. This is the circled area of Figure 11.1. At $10 to $50 million in revenue, a company struggles with the balance of process and innovation. Before this point, process is unrealistic and beyond this point, if there is no process then there will be no after.

A Bias Toward Action Emerging initiatives require a strong bias towards action for success. With no history of mistakes to cloud ones thinking there is a “just do it” philosophy. Mature companies have a core of successful business behavior and an anecdotal archive of failures. These provide a strong “rudder” for company behavior and are a major component of the company’s value. Unfortunately, for exploiting new markets this creates a bias towards inaction. In the 1970s, Xerox’s Palo Alto Research Center (PARC) invented many of the central technologies of today’s personal computers including desktop computers, the client-server architecture, peer-to-peer networking, objectoriented programming, graphical interfaces, laser printing, and even the mouse. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

206 Le Clair

Xerox’s failure to capture value from the creation of personal computer and graphical user interface has been well documented (Smith, 2003). And in the end they failed because they were not hungry enough. Xerox was not frantically trying to find the next big thing, because it already had a very big thing. During the ’60s and ’70s it owned the copying market and was enormously profitable. Steve Jobs, the co-founder of Apple, visited Xerox PARC labs in 1979 with a team of engineers. As the story goes, Jobs saw the first graphical front end with exploding windows and user-controlled cursor and began to jump around, shouting, “This is revolutionary!” “Why aren’t you doing anything with this?” Of course these features became part of Apple’s successful line of Macintosh computers.

The Developing Country Like a developing country, emerging software companies have fragile infrastructures. Their leaders are entrepreneurial and inspired but are, by definition, new to the task at hand. They need financial, business development, and engineering support of all kinds and require access to risk-tolerant investors who provide venture or corporate funding. Scaling the organization properly is their biggest challenge, second only to breaking into the new market.

Scaling the Organization The role of sales, marketing and engineering will change as the company scales. As the firm moves from concept to validation and to maturity each specialty will contribute different skills. Understanding this pattern will help with organization and human resource decisions. Emerging companies go through phases on their way to maturity. They follow the pattern of Figure 11.2. This plots the organizations development against two primary areas of tension, that of entrepreneurship and scalability. As the firm passes through the three stages of development shown, it will gradually develop organizational discipline. This will be at the expense of being able to rapidly respond to new opportunities.



207

Figure 11.2. Primary tensions within the emerging company Entrepreneurial Behavior

Organizational Discipline Scalability One-Off Stage Re-Building Stage

Generalized Platform

One-Off Stage The one-off stage is the very beginning. It is when an opportunity presents itself to drive a particular endeavor into a business. At this time there are only visions, theories, and ideas. There is nothing that can be scaled and very little organizational discipline. Business plan development, investment, and organization will follow as the real work begins. This stage is when the primary value proposition is first developed and an anchor customer is found. Initial “one-off systems” are built, followed by roll out of an initial product or capability tailored to that first customer. The emerging company is at its most entrepreneurial stage in these early days. They can move quickly and have the ability to create hot, motivated teams and execute at high levels. New product ideas are formed in this stage by a small number of expert people who think not only “out of the box” but are able to conceive new boxes. In the “one-off” stage, the average person has greater effect on company performance then at any other time. They have no baggage and hence no hand wringing over protecting legacy revenue streams. From an employee perspective, it is the difference between flying a jet fighter and piloting an ocean liner.


208 Le Clair

In the former, your decisions and actions have very rapid and highly visible effect.

Rebuilding Stage During the rebuilding phase, the ideas from the first phase become early systems that are transformed and enhanced by initial customers. Decisions and actions in this phase are in a constant state of turmoil with management pulled in conflicting directions. There is a strong drive to show progress during, as defined by paying customers and improved cash flow. New opportunities and directions present themselves that deviate from the initial vision and perhaps any vision at all and grab the soul of key individuals. These forces compete with the understanding that a generalized product platform, standard development and business processes, are required to build a scaleable company.

Generalized Platform Stage The software company has reached this stage when the market has validated their product. It has been installed at a number of customers who are solid references. Development has finished the generalized product and is using a standard software development methodology. You now believe you can supply the product and make money. Now the goal is to scale the organization and this will require discipline in the core business functions. As the company expands during this period, the underlying processes and infrastructure begin to take shape. As shown in Figure 11.2, at this point, organizational discipline overtakes the entrepreneurial spirit. The company has matured.

Relationship of Marketing, Sales, and Engineering Before we discuss how these relationships need to shift on the way to maturity, lets look at the typical organization of the emerging company. This is shown in Figure 11.3. Notes are provided to give a flavor for the backgrounds of the senior individuals normally filling these positions.



209

Figure 11.3. Typical organization of emerging software company Board Venture Capitalist

CEO

Usually Involved in Usually Founder or Proven CEO Company Operations with other Startups

Contracts/Legal

Maintenance

Administration

Customer Service

Ideally has taken other Startups Public/Acquisition

Offshore Contracts Software Development Can Articulate Technical Vision of Company

Valued for Contacts and Industry Knowledge

Operations

CFO

Development

Industry Executives

Important for ASP Market Approach

Marketing Product Management PR, Events

Will Grow in Importance over Time

Sales Alliances Major Accounts

Most Frequently Replaced Senior Position

The relationship between sales, marketing, and development is one of the most difficult for the company to manage. These functions are in the lower part of Figure 11.3. The key to maturity and scalability for the emerging company is how the functions of these departments subtlety shift over time. In Phase One, the highly entrepreneurial stage, sales and development work closely together to innovate. As scalability becomes the goal, marketing pushes itself into the picture. As the firm leaves the “one-off” stage development must implement more discipline in the engineering practice. These shifts are essential for success to be achieved in enterprise software. Lets look at them in more detail. The functions of marketing are critical to long-term scalability and success of the company. These traditional marketing functions shown in Figure 11.3 include product management and marketing communications. The former includes the important task of product strategy. The later, marketing commu-


210 Le Clair

nications includes public relations, managing the Web-site content, and making sure the company’s message is consistent.

The Role of Marketing In a perfect world, marketing will create the initial vision for the product or enhancement, define the market, features, and design a marketing program. Stated another way, product marketing should precede the sales efforts for a given product in the following way. Once the product is conceived, designed, and built, marketing formerly introduces the product to the sales force with a full set of documentation, training and competitive analysis. They also make the target user population aware of the company and the product using marketing communications tools such as the Web, press releases, case studies, and through participation in industry events. To use a military metaphor, marketing is the equivalent of air support. Its job is to soften up the target (customers) for the foot soldiers (sales), to come over the hill. As described in Chapter IX, time to market concerns, the need for incremental development and the level of unknowns in creating new products makes the pure marketing-led approach ineffective in the early phases. In other words, the traditional marketing-led process is not flexible enough to accommodate initial product development for enterprise software.

The Technologists Role and the Product Champion As a result of this, the key players in the early stage of the software company are sales and key members of the technical staff. The initial products tend to be based on a technology breakthrough, and your top technologists will have a major role in shaping these early products. Engineers are great to work with. They care about what they are working on, care about the tools that they use, and the good ones are natural problem solvers and they possess a refreshing degree of intellectual honesty. In many cases they will come up with the key business innovation without realizing it. However, you always want a businessperson to accompany the engineer at a customer meeting (Anonymous, 2003).



211

A priest and an engineer are being led to the guillotine. They ask the priest if he wants to face up or down when he meets his fate. The priest says that he would like to face up so he will be looking toward Heaven when he dies. They raise the blade of the guillotine and release it. It speeds down and suddenly stops just inches from his neck. The authorities take this as divine intervention and release the priest. The engineer is next. And he too decides to die facing up. They slowly raise the blade of the guillotine, when suddenly the engineer says, “Hey, I see what the problem is...” Software development staff can provide insights to adapt the technology to the customer needs. They can provide the flexibility and responsiveness required to deliver rapid prototypes, respond to emergent requirements, and support delivery to beta-test customers. Simply put, development must be heroic in the early stages of company growth.

The Sales Role Sales will motivate the early-adopter customers and is often the perfect complement to development to create the initial product. Having sold the first product, they will know the most about and will be proud of this knowledge. Sales must manage the organization and the customer through the initial beta test period. Getting through the beta test period with the early customer takes great skill. This industry “tongue in cheek” definition of beta test hits pretty close to home. “To voluntarily entrust one’s data, one’s livelihood and one’s sanity to hardware or software intended to destroy all three. In earlier days, virgins were often selected to beta test volcanoes.” So why is sales more appropriate than marketing for this early stage? Professional sales staffs are trained to search out and validate value gaps. They are constantly looking for customers that are experiencing great pain. They can find companies who are growing at substantial rates and require new solutions. The likelihood of a sale is highly correlated with the gap and sales people are trained to exploit them.


212 Le Clair

The best marketing professionals provide a strategic filter around the discovery process without slowing it down. They maintain the larger view. It is a view of the market, not a customer. When development and sales are obsessed with a concept, marketing checks whether the concept has sustainable value. But in terms of finding value, and innovating around a theme, sales and development are better in the lead then marketing. They will be stronger in the early days at creating value. As the company matures it will more and more flip the relationship of marketing and sales. Marketing will get stronger and push in front of the selling activity. If solutions are created by sales in the field without the required checks and balances that product marketing provides, the company may quickly spin out of control. It is an important foundation for scalability required for a mature company. This is shown in Figure 11.4. Sales and marketing are not the only parts of the company that requires discipline and process. As we discussed in Chapter VIII and Chapter IX, there is a strong need to use standard software development methods. In addition, Finance and Administration must apply best practices to get firm control over operations, profitability and cash management. Sales administration will need a process to manage the sales funnel and provide reliable forecasting. To reach maturity, process must be added to all aspects of the software company. So far, we have looked at process issues for the software company. We end Figure 11.4. Relative contribution to VP discovery marketing and sales/ engineering Contribution to Product Discovery

Sales/Development Marketing

One-Off

Re-Building

Generalized Platform

Growth Phases



213

the chapter with a discussion of an emerging framework that provides process and control for a sophisticated IT environment that is the software company’s customer.

CobiT and the Increasing Governance of IT During the “technology” period companies made irrational and emotional purchases of enterprise software. These purchases were not often aligned with the firm’s business solutions or strategy. “Out of control” is a reasonable description of this period, as firm’s purchases were not aligned with strong business case frameworks, controlled implementations, or the level of behavioral change required by the human resources of the company. Conditions indeed are ripe for more structured processes in the management of IT resources. These abuses of the technology period are about to collide with the current trends in corporate governance and risk management stemming from recent corporate scandals. This focus has resulted from the Enron, WorldCom and scandals in the financial services industries and is affecting business around the world. The immediate focus is on financial risk as mandated by Sarbanes Oxley and similar legislation in other countries, but attention is increasingly being focused on the IT area. These trends are likely to result in increasing acceptance of an international standard called Control Objectives for Information and Related Technology (CobiT). It has developed as a standard for good IT security and control practices and a reference framework for management, users, IT audit and security practitioners. CobiT requires a lot of documentation, and over the next several years, IT may be documenting more than programming. They will understand what a “material system” is and like their accounting brethren, will identify risks and put more controls and testing in place. External and internal auditors will want to review these control documents. It may be time to buy that sandwich shop in Key West you always dreamed of.


214 Le Clair

The value proposition of the software company can be strengthened by alignment with CobiT. Many of the processes outlined in this book will help do this in that: • • •

Both CobiT and the concepts in this book reflect a strong trend towards customers gaining fundamental control of their IT expenditures. The framework provided has improved processes to gain stronger control of implementation, ROI, and behavioral change shortfalls. The proposed business case framework, like CobiT, helps align technology with strategic business objectives.

The starting point for CobiT is the business objective of the customer. Suppliers of technology need to have the same starting point. Business objectives are then aligned with detailed control objectives to provide management guidance for improvement. Thirty-four distinct IT processes are used in the framework to optimize information investments and provide a benchmark for governance (Anonymous, 2003). CobiT’s “good practices” are the consensus of the world’s experts. 1 It is a comprehensive and complicated control process and not appropriate for all organizations. But it reflects a strong trend towards customers gaining control of their IT expenditure and is consistent with the new attitude that will govern IT purchases. Stronger IT governance will change the attitude of your customer. They will be more risk averse and emphasize documentation and risk-mitigation strategies for new enterprise-level projects. They will shift some of the burden to their suppliers.

References Anonymous. (2003). Found in: Internet newsgroup. Retrieved January 7, 2004. Smith, D. (2003). Fumbling the future: How Xerox invented then ignored the first personal computer. Adapted from Knowledge@Wharton On Building Corporate Value. John Wiley & Sons.



215

Endnotes 1

CobiT was first published by the Information Systems Audit and Control Foundation in 1996. CobiT is now in its third edition.


216 Le Clair

Chapter XII

Creating Value through Alliances “What I need is a list of specific unknown problems we will encounter.” Anonymous Many emerging company’s products do not bridge from the old way of doing things to the new. The customer may be forced to use the Web and frustrated beyond belief because no human being is available. Or they are sent e-mail with a document link but cut off unexpectedly from paper. We can learn from tollbooths. They use wireless technology to move cars to “fast lanes” that do not require humans to collect the tolls. But wisely, they have not cut over to fast lanes all at once. They know only a few drivers would be ready with the rest bewildered and angry. Yet many companies in the enterprise software business push their customer off a cliff. The preceding chapters have tried to reduce its height. The behavioral change chapter forces us to examine off-line patterns of human interaction and incorporate these features into our products. The implementation chapter helps us respect and easily integrate with legacy systems. The assimilation chapter emphasizes the need to address the complete business process and recommends industry partnerships to create a bridge from the old system to the new. This chapter will help us create these industry partnerships. First, the two most common partnership paths are shown. The different distribution alternatives are Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Creating Value through Alliances

217

then described. How to create alliance maps that form the basis for the overall alliance strategy follows this. Then we look at execution, the most important part of successful partnering.

To Partner or Not? Forming partnerships with other companies can enhance value and promote assimilation. The partner’s product can fill a gap in the offering and complete the business process and in other cases, a partnership is required just to have a working solution. Successful partnerships will create value that each company would be unable to provide independently. Partnerships with large companies can also hurt an emerging company’s chance of becoming a mature one. The smaller company may give up access to critical markets. The larger firm may take a defensive strategy with no motive to sell the software company’s product. They may just be slow and ineffective and without malice put the little company to sleep. Or they may use the partnership to gain experience with the technology in the early days of the market only to build the capability in house as mainstream customers adopt the new solution. We will frame the debate in this chapter and use several new concepts to do so.

Alliance Paths for the Emerging Company Figure 12.1 shows the two paths that alliances may take. The high road is the good one while the low one is painful. It is unfortunate that the lower path is the more common. One Bain and Company study concluded that only two of 100 alliances last more then four years and that most alliance overtures fail to get past the negotiation stages. On the vertical axis of Figure 12.1 are the intangible requirements of a successful partnership. They include dependability, trust and commitment. These all grow or decline depending on which path the partnership takes. Along the horizontal axis are the four phases of partnerships.


218 Le Clair

Figure 12.1. Two most common alliance paths Merger/Acquisition

Relationship, Dependency, Trust & Commitment

Alliance Launch

Minority Investment

Begin Conflict Period

Joint Venture Market Exclusive Alliance Termination

Compete Seek Alternate Technology Build/Buy Alternate Solution

Joint Customers

Co-marketing

Channel Conflict

End Game

Phase One: Joint Customers Most alliances begin with a shared customer. This occurs when a customer independently installs both parties, or one of the parties is already there. Phase One is often driven by this one-off business opportunity, that is, when two technology companies randomly end up at the same customer. The customer may encourage the two solutions to integrate, thus creating a more complete and functional product. The partnership is then formed and the firms begin to collaborate. Many industry partnerships begin in this way and it is sometimes referred to as “the honeymoon” period.

Phase Two: Co-Marketing Phase Two is the joint or co-marketing period. This is where each firm finds it advantageous to promote the newly completed integration to the market. The larger software firms tend to form loose partnerships of shorter duration during this phase. A software company can become a SAP integration partner, for example, by filling out a few forms and achieving certification training. There is no shared technology or confidentially agreements. The more solution-oriented enterprise software providers will use a more tailored reseller agreement since there will be customization and potential distribution issues. Solution partnerships become more intertwined. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


219

Phase Three: The Conflict Period Conflict occurs when both companies try to sell the same product to the same customer, one being the reseller (usually the larger company) and the other being the owner of the technology. This is sometimes called channel conflict and it is inevitable except where the partnership has no value. In that case you will have no conflict but a failed partnership. But in most cases, even if you create careful partitions along vertical markets or application areas, as described in the next section, you will have some conflict to manage. This results from the tendency for the partner to expand outside of their traditional market. And with this expansion they will drag your solution and battle your direct sales force or another partner of yours. The software companies direct sales force, an impatient group, may also enter into a sales contest and compete with the partner to imitate conflict. At this critical point, the partnership can go in the two directions shown in Figure 12.1. The upper slope leads to a closer relationship perhaps ending in acquisition (the ultimate partnership). The lower slope leads to miss trust, direct competition and your partner’s search for an alternate solution. Finally, the partnership is terminated. Most alliances have some degree of chaos that results form channel conflict. The tradeoff to assess is whether the additional distribution from the alliance is worth managing the chaos. Some companies have been very successful with a blended or conflict-oriented approach.

Phase Four: The End Game Many alliances in the software industry are driven by fear. The software company may decide that the larger more mature company has too much market presence and may decide it is better to join them rather then compete. The larger company may be fearful of the emerging company breaking into their customer base with the latest technology. Or the alliance could be driven by the perceived need to create a new standard within an emerging market or by having a complete solution for the customer. Whatever the reasons and they may be a combination; the end game will take one of the two paths of Figure 12.1. The direction will depend on the importance (value) of the joint solution and the degree of trust and communication that exists between the companies. If the Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

220 Le Clair

solution has little value then the partnership will fizzle out and fail, that is, take the lower path. Where there is value, trust and the ability to communicate, the partnership will get through the conflict period. Channel conflicts are just part of doing business and can be dealt with if the parties communicate honestly with each other.

Avoiding Conflict A distribution matrix can help minimize conflict. Figure 12.2 shows one type of breakdown. Across the top of the matrix are the vertical markets that the company is focusing on. Along the side are the three possible distribution approaches (direct, channel or blend). Within each cell, the software company defines the distribution strategy. In this way the distribution strategy is clear and can be communicated to management and the sales force. Management often does not clearly explain the distribution strategy to the sales force, resulting in embarrassing conflicts that could be easily avoided. A simple matrix like in Figure 12.2 can help a company be aware of potential conflicts. As shown in Figure 12.2, the two-distribution methods open to the emerging company are direct and indirect. Three vertical markets are shown. For each vertical market, the software company selects a distribution approach. In this example, the Insurance market will be covered by the software company’s Figure 12.2. Distribution matrix

Vertical Market

Insurance

Banking

Brokerage

Channel Direct (Outside)

X

Direct (Inside)

X

Indirect (VAR)

X X

Indirect (ASP, Large Outsourcer)

X

Indirect (Systems Integrator)

X

Indirect (Enterprise SW Supplier)

X



221

direct sales force. They will use an outside sales force for the larger accounts and will use an inside sales force and modern communication tools for the small business market. A direct channel is where the supplier sells software directly to the end user and includes: •

•

Outside Sales Force: This is a channel through which products move directly from the software company to the end user, usually by a professionally trained field sales force. Inside Sales Force: This is a channel through which the software company sells their own products directly to end users through the use of the telephone, Web, or e-mail.

In Figure 12.2, an indirect channel is selected for the brokerage and banking sectors. A variety of indirect channels, where a third-party organization resells your product, are selected and include: •

• • •

Value Added Reseller (VAR): These companies act as a consultant to clients. They would integrate your software for a particular market or offer significant integration or domain expertise to the customer. Systems Integrators: These are professional service providers that migrate and integrate technology into business processes. Enterprise Software Suppliers: These include emerging or mature software companies. Hosting, ASPs and Large Outsourcers: These companies offer access to software over a network as a managed service offering. They include large service providers that outsource a significant business process.

Why Partner at All? In a perfect world, all companies would have a direct model. To any company, owning the business relationship is preferred, so why do so many emerging companies elect indirect or channel strategies? The reason is that the company can get to the market more quickly. They can do this with a lower investment in sales and marketing.


222 Le Clair

They will have a more complete and compelling product for the customer. Selection of a complete and working solution is a big advantage to any customer for reasons cited throughout the book. Mainly, they are buying a solution that can be implemented more quickly with lower risk. Many companies have done well by integrating their applications with the major ERP and CRM vendors for this reason. The difficult decision for the emerging company is when to make the R&D investment to integrate with the partner. This will be an expense without immediate revenue associated with it. It may take longer to build an effective distribution channel then it will take to integrate the product with the partner solution. Given the low percentage of partnerships that are successful, the question is when will this effort pay off?

Determining the Target Partners Once the general distribution strategy is agreed upon, the harder task is execution. How does the company begin to develop partnerships in those markets deemed appropriate? For this we start with the “whole product” concept enhanced by Geoffrey Moore in Crossing the Chasm, but defined before that by William H. Davidow in Marketing High Technology: “A product is the totality of what a customer buys. It is the physical device or service from which the customer gets direct utility plus a number of other factors, services, or perceptions, which make the product useful, desirable, and convenient. When a device is properly augmented so that it can easily be sold and used by a customer it becomes product.” (Moore, 1991, p. 55; Davidow, 1986, Ch. 2, p. 27) The partnership strategy starts by viewing the product is this broad sense. For enterprise software, the product includes the core software but also all required hardware and third-party software, documentation, training, pre-sale application support, maintenance and professional services. It also includes off-live processes to complete the business function. These are all needed to make our product complete.



223

Figure 12.3. Alliance map for an electronic billing provider Cellular Network

Billing Engine

Best Partner?

Printing and Mailing

Consulting and Integration

Electronic Billing

Customer Relationship Management

Drawing Alliance Maps: Telecommuincations Once the complete solution is understood we can break it into component parts. Then it is an easy task to identify the companies supplying the software and services for those parts. These companies are all potential partners. Figure 12.3 shows the level of detail required to develop a partnering strategy in telecommunications for a supplier of electronic billing software. Electronic billing software allows a consumer or another business to view their bills online and pay them. Each boxed area in Figure 12.3 represents an industry segment that makes up the complete industry solution. Each box may represent a distinct market space with ten or more suppliers in each. The alliance strategist should first plot the industry solution at this level of detail. This will show the companies that are potential partners. The list will be small. Some partners have aligned with others. Some are politically incorrect. Others may be just right. To make the required level of detail clear, let’s follow the process from start to finish. The billing process starts when a telephone call is made. The billing software captures important “call details” directly from the cellular phone network. Note that the billing system is the heart of the process. It accepts detail call records and organizes them via a series of database tables. The database structure can create bills, feed data to financial systems, and support various tax applications.


224 Le Clair

Once the bill is created it is sent via high-speed network to a printing and mailing house. From the printing data center, the bills are printed and mailed to customers. The same “print stream” used to create the bills is then sent via a high-speed connection to the electronic billing application. The e-billing supplier will present the bill electronically through the biller’s Web site, third-party Web site or e-mail the bill directly to the customer.

Which Partner to Target So of the four potential partner categories of Figure 12.3 which one is the best bet for the e-billing company? As shown in Figure 12.3, the billing software supplier, the consulting firm, and the CRM vendor are potential partners and are very strategic vendors in the customer’s eyes. The large consulting firms may implement the billing and customer service applications. They will be the first to know of the opportunity for the E-BPP solution. In addition, bundling the e-billing product with the billing software supplier is a possibility. But these partners may not care enough about the e-billing solution to be good partners. The large consulting firms, CRM suppliers and billing software suppliers have many products to work with. For the CRM and billing software vendors, E-BPP may be one of 30 different applications they need. The E-BPP application, while important, may not be central enough for them to develop an advocacy position. Going back to the basics, which of the above companies has electronic bill presentment as a more natural and required element in their sales motion? My guess would be the printer, as all paper technologies need paper replacement strategies. The slower, bigger, and established printing company probably needs the software company more. It probably cannot build internally the technology needed to be competitive. It cannot retain or develop that kind of staff. It will be more dependent, will have more customers, and probably be the safer bet. In addition, CRM and billing software are in relatively new markets. As a general rule, software companies in growing markets do not make the best partner. Being in emerging markets, they move too quickly and have similar core competencies. They are just too hard to keep in the box. The more mature printer in this case may be the longer and more stable partner. This framework provides only a starting point and gives a flavor for strategic discussions surrounding partner selection. It is early research in the process of defining alliance targets. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


225

Using the alliance map, you then need to go out and talk to the companies in each box. Based on those discussions, you can assess the potential value for your company, the potential partner, and for the market. Each of these meetings will leave the software supplier with valuable insight. Lets look at another example in a different vertical market.

Drawing Alliance Maps: Financial Services Almost all potential vertical markets or application areas can warrant their own alliance map, and place the software product with a different set of candidate partners. A single software product may generate five to ten potential maps. Figure 12.4 shows an example for the financial services vertical market. As in telecommunications, each of the boxes represents part of the complete solution. In this case the solution provides online financial advice to a 401K retirement plan participant. Each box represents companies in the business of providing that part of the solution. The data for modeling a retirement plan allocation comes from a “record keeping system”. So called because it maintains the official account information for the retirement plan. It includes data on the participants such as their investment holdings, name, and address. A retirement plan company or an independent service provider may supply the record-keeping system. In the case described here, an “advise engine” calculates new portfolio allocations for the retirement plan participant. The value of such a product is the ability to create a new investment recommendations for an individual based on a risk profile and other demographic information. But to do this without requiring an individual to enter a lot of data, the advise engine needs to have a link to the participant’s investment holdings and other data in the recordkeeping system. As shown in Figure 12.4, the advice application is provided to participants in the retirement plan through the sponsoring corporation’s Web site. A consulting firm specializing in the corporate benefit market may have built their Web site. If you supply the software for the 401K portfolio modeling application, called here an advise engine, and you are looking for market reach you may find the consulting company is the best partner. They can provide a better solution with Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

226 Le Clair

Figure 12.4. Alliance map (financial services) Record Keeping Administration

Enrollment Materials

Services Integration

Advice Engine

Corporate Benefits Web Site

Best Partner?

Corporate Benefits Consultant

your capability and add more value. They may also be skilled in integrating the model with the record-keeping system. More importantly they may receive the RFP to build the system. The best partner could also be the financial services firm providing the retirement plan. They may maintain the retirement section for the company’s Web site.

Alliance Execution Issues Unfortunately, some 70% of alliances fail and end up taking the lower path of Figure 12.1. Many fail even when the solution is technically successful. Failure is expensive to the companies involved and confusing to customers. The criteria below do not ensure success but in speaking with many companies that have had good and bad partnerships, they can help: A. B. C. D. E.

Whenever your alliance partner sells their product it creates a strong demand for yours. The functions of the products do not overlap. Your core competencies are very different. Your product enhances the partner’s revenue rather than reduces it. Your people get along and have similar views of acceptable behavior.

Understanding the likely issues that will be encountered in an alliance can improve the chance of success. Below are some of these. Partnerships take many forms and not all of these will apply. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


227

The Snuff Factor Larger companies can “snuff” smaller ones. This means that as a result of forming the partnership the progress of the software company is slowed. Often, the larger company forms partnerships when the emerging company threatens them. By distributing the software company’s product, the larger company can prevent the smaller one from going direct into the market and getting established. The partnership allows them to keep track of the upstart’s progress. By not selling the product effectively, they can put the smaller company to sleep over time. This is the most ruthless form of snuff So how does this happen? In many cases the larger company needs the emerging companies technology to compete against rivals but it can provide most of the required services without their help or product. This violates fundamentals A and B. In addition, the larger company may not need revenue from the software product to meet goals. As a result few sales are made, or the larger partner discounts the partners product significantly. These conditions often occur when the larger company as a “defensive” strategy forms the alliance. The larger company can differentiate its service with the emerging companies product. But it does not exert the energy to implement their solution in a timely fashion. This is true for many emerging Web-based solutions that reduce the larger companies revenue. The worst case is for the emerging company to give up the ability to go direct in a market to a partner that is ambivalent about delivering revenue to them. It also can be hard to get the large company to move as fast as emerging company requires. They are large and may be slow, and not as flexible and innovative as the software company needs them to be. They will struggle if the value proposition, pricing, and positioning are not cast in stone, and this is almost always the case. So the software company can get “snuffed” simply through “big company” inefficiency. There are ways to deal with the “snuff factor”. The easiest is to have a revenue guarantee for providing market rights. This is the best anti-snuff provision and will ensure that if you are being put to sleep, at least you will be compensated during the nap. Another is the compression approach described later.


228 Le Clair

Securing Mind Share It is critical to secure mind share from the partner. When they are out talking to prospects, you want them thinking and speaking about your product. You need it to be on the agenda. Your partner wakes up in the morning and thinks about a small set of things and your product should be one of them. But getting and keeping mind share is hard. Internal compensation plans and culture pressure a company to sell their own products. If they are like most companies, the sales force is not trained well enough in its own product line and has too many products to sell already. Your product is somewhere on the list, is probably more complicated to sell, and may drive less revenue. The software company with limited resources ends up competing for mind share with the product marketing teams of the larger company. Without a really strong pull from the market, it is a battle they often lose. These pressures all work against success of the alliance.

Jumping the Channel The snuff factor concerns the smaller technology company. The mature partner worries about introducing the upstart company to their clients. They fear the small company will go direct or “jump the channel”. After all, the mature company is the one with the clients and it will establish the smaller company into a market with those clients. They will end up very unhappy when competing with that company down the road. History will tell us that small companies will steal the larger companies customer base whenever they can. In speaking with several large companies you would think that upstart technology companies are the 21st century version of pirates. Unfortunately, there is some history to support this. Distributors of PCs did the missionary work for the initial local area network (LAN) operating system. They helped establish Novell in this business. Once Novell established a strong “brand” and momentum they “blew away” that channel. Wang did the same thing with its initial word processors. BBN communications agreed to distribute the initial communications router of an unknown west-coast company. BBN put their name on the cabinet and connected it to the Defense Data Network, the military side of the original Arpanet, which would later become the Internet. This little company was called CISCO systems. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


229

The mature company can deal with jumping the channel by obtaining exclusive distribution rights to the software company’s product, perhaps in exchange for a revenue guarantee. This often will require a revenues guarantee to the emerging company. But if it keeps the channels clean and lowers tension in the partnership, it may be worth it.

The Compression Approach Sometimes despite your partners best efforts there will not be strong enough sales for your product. The truth be told, this is almost always the case. We have touched on many factors that may contribute to this. The larger distributor is biased by their expertise in their core competency. They make higher margins on their own products than those distributed, and as discussed, may use your product as a defensive strategy. Compression is a legitimate approach that can help. With a compression approach, the emerging company markets its product directly to the end user. He does this even though he has signed up a distributor even if the prospect is a client of the partner. With this approach, the emerging company can test its value to the customer and generate interest. Once interest is generated, the emerging company will direct the sale to the distributor for closure. But in the process the smaller company is ensuring its interests are represented and is in effect, squeezing or compressing the distributor. It is keeping them honest.

A Dangerous Learning Curve Many partnerships are formed in the early stage of a new market. This is when excitement about the new product is the highest but there are few real customers. Established companies will partner with the emerging companies at this time. This keeps their investment in the new technology at a minimum and is a low-risk approach to an uncertain market. In the early days of the partnership, the mature company may bring on earlyadopter customers. The problem is that these early customers may not generate significant revenue for several years. As the market develops and larger customers begin to generate revenue, the mature company may decide to build the technology in house, or use a solution from another division. At some point,


230 Le Clair

this will be more cost effective than paying royalties to the emerging company. Of course, they may acquire the partner at this time. But too often, the unfortunate result for the partner is to have trained the larger company without getting to real revenue.

Summary Alliances are an excellent way to create value. If you can lock up the key distribution partners in a market, you will sustain value in that market. Some markets will have one dominant player and once integrated with them; your solution becomes the solution for that segment. Your competitor may have a solution equal to yours but he will be locked out of that segment and be forced to develop a direct model, which will take time to develop. And then they will compete with you and your alliance partner. As we discussed earlier, alliances are an important strategy discussion when evaluating distribution approaches. Whether to partner or not and who to partner with are difficult decisions and once you’ve decided what to do, then you must win the partnership.

References Davidow, D. (1986). Marketing high technology. New York: The Free Press. Moore, G. (1991). Crossing the chasm. New York: Harper Business.


Value Creation Using Offshore Resources

231

Chapter XIII


“The answers are always inside the problem, not outside.” Marshall Mcluhan Offshore development is no longer a trend, but a fact of life for building enterprise software. Programmers and operations staffs from the developed countries are under siege. A recent report from Forester Research predicts that over the next 15 years, 3.3 million U.S. services industry jobs and $136 billion in wages will move offshore to countries like India, Russia, China, and the Philippines. The IT industry will lead the initial overseas exodus (Macarty, Dash, Liddell et al., 2002). Today, investors in software companies expect an offshore strategy and view it almost as important as having a marketing strategy. The company without one will be considered uncompetitive. This chapter discusses the effect of offshoring on product development. It is based on interviews with several companies using offshore resources and my own experiences. To set the stage, we first look at product development issues faced by enterprise software companies. Offshoring adds complexity to a process that is already challenged. Primary issues with offshoring are then outlined including:


232 Le Clair

• • • • • •

Language and culture Control of intellectual property Security of sensitive data Lack of process Bias for substitution of labor for technology Use of proprietary versus off-the-shelf components

An approach to integrate offshoring with product development is outlined.

Getting Products Out the Door My first exposure to offshore development was more than four years ago. I worked for a company that subcontracted to several hundred personnel in New Delhi. In my previous software environments, a tremendous amount of energy was spent prioritizing features against scarce product development resources. New releases dribbled out every nine to twelve months. The available staff months for software development were well known, and the basic math ran something like Figure 13.1. To build the revenue required for success you absolutely needed to add product features quickly. As shown in Figure 13.1, the software development cost and length of time to build them was always higher than expected. The available product development was barely enough to cover needed bug fixes

Figure 13.1. Unfulfilled development needs (staff months) REQUIRED RESOURCES FOR NEW DEVELOPMENT

60

COMMITTED RESOURCES FOR CUSTOMER PROMISES AND MAINTENANCE

45

RESOURCES AVAILABLE FOR NEW DEVELOPMENT

15

PERCENTAGE OF UN FULFILLED NEEDS

75%



233

and custom features required for paying customers. At the end of the painful prioritization exercise the available resources would only allow a small number of new features to sneak into the next release. After about a month in my new position at a software company that used extensive offshore resources, I asked software development how long it would take to implement a particular feature requested by a customer. The head of the New Delhi-based operation looked at me sheepishly and said it would take at least four weeks. When I did not reply right away due to my surprise over the short duration, he quickly added, “but if the customer is really in a hurry we could do it in two”. Now this was indeed a new world, one that any marketing professional and entrepreneur should meet with enthusiasm and caution.

Use of Business Process Technology with Offshore Resources There are two main uses of offshore resources. The one concerned with here is offshore software development. The fastest growing however, is offshore operations that include call centers, data entry and paper-related processing of all kinds. About 1.6 of the 3.3 million projected jobs lost will be in the “office” services category (Macarty, Dash, Liddell et al., 2002). Many of these applications will combine the low-cost, high-quality labor with advanced business process technology. Countries like India are destined to become the “back office” for the western world. Advanced workflow technology is an important enabler of this trend. Workflow software has been given a new life. It is now called business process automation but has been around for a decade. Workflow moves work tasks from workstation to workstation under software control, whereby various work queues will “process the workload”. Besides getting rid of paper, this allows centralized management of the work process, as well as parallel routing of work activity. It was viewed in the 1990s as a significant transforming technology and had a large forecasted market, but is just now reaching it’s potential. The original workflow projects required too much organizational and behavioral change. Implementations were difficult. Projects lagged due to extensive integration with customer systems and product modifications due to process-


234 Le Clair

technology gaps. It was harder than anticipated to make workflow applications productive, but increasingly workflow has become focused on specific business processes and incorporated best practices. It has begun to help. It has also become an important enabler for offshore operations. With workflow, an operational process can be worked on around the globe. This expands the time to perform a task significantly.

It’s Not Just Cheap Labor Anymore Unfortunately for the developed countries IT worker, the offshore movement is not just about cheap labor. There are a growing number of senior, well educated IT and business professionals in the offshore community. The crown jewels of IT dominance are intellectual property embodied in higher-level design and system-engineering task. These are being siphoned away as well. After costs, the need to get products to market quickly is driving software companies to move development and operations off shore. Technology companies are some of the most competitive in the history of the business world. Firms’ race against milestones often keyed to their very survival. Product development cycles that used to be two years continue to decline. Now six months is a lifetime and the average is moving to four. If you include one month for testing, and one month for rapid design and discovery, this leaves the firm two months to build the product. The ability to use many developers in large teams at low cost has become almost a necessity under these conditions.

The Time Zone Advantage Before workflow technology and the Internet, time-zone differences were a negative. For many applications today, the time zone is now a plus. Companies are using the earth’s rotation to create round-the-clock operations, by extending the day to sixteen hours of productive work. This is a strong edge in trying to get product out the door or servicing that demanding customer. In some cases, the tasks require more then an eight-hour shift to be accomplished. NewRiver, Inc., for example, had 200 staff in New Delhi maintaining databases for the securities industry. There were more than 1000 changes a day Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


235

to their databases that come in as late as 11 p.m. They all had to be updated for SEC compliance by the opening bell of the US stock market the next morning. This industry solution would not exist without using more then one time zone (Dennison, 2002).

Offshore Issues High-speed data communications and reliable systems have made distant irrelevant. The fact that programmers are “there” versus “here” is workable and this has allowed the offshore approach to gain momentum. However, effective use of offshore resources is not easy. There are serious problems integrating these assets into the core development process of the “market company”. The “market company” is the lead company and the target market for the products. Lets examine some of these issues.

A: Language and Culture English has been the de facto language for the computer industry since the 1960s. It helps that the primary locations for off shoring are former British colonies. These have developed excellent English skills. Having said this, communication is difficult. Offshoring complicates the process of communication surrounding early product creation. The manager of offshore developers will have reasonable English skills but will communicate with a large staff that do not. The offshore team will also have little understanding of the product strategy. This puts tremendous pressure on that single point of communication, with little ability for market-company personnel to validate the correctness of the communication.

B: Control of Intellectual Property A significant issue for the market company is control over the intellectual property co-developed with the offshore resource. Most offshore developCopyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

236 Le Clair

ment is a subcontracted resource. To customers the resource may appear as the software development, testing, and professional services department of the market company but in fact in the majority of cases it is a separate legal entity performing subcontracted services. The more proprietary software developed offshore the less control over intellectual property the market company will have. This is less of a problem with customers than it is with the downstream public offering or acquisition strategy of the market company. The market company also runs the risk of being perceived as a mere reseller of offshore development services or worse yet a potential acquiring company may look at dealing directly with the offshore capability. Strong exclusive contracts and a carefully executed product management process, as shown in this chapter, can help mitigate this risk, but the fact remains that the offshore resource has significant leverage over the market company and may exploit this as the company becomes more valuable.

C: Security of Sensitive Data Customer perception often defines reality. Today, it is perceived that data housed in the U.S., for example, are more secure than data housed in Sri Lanka. It is also perceived that entering your credit card number during an online shopping session is more dangerous than handing your credit card to waiter in a restaurant who disappears for ten minutes. Neither of these perceptions may be true but as we have seen beliefs influence attitude, and attitude will influence behavior. These attitudes may prevent roadblocks to promising offshore solutions. Even though data can be compromised, resold, or modified anywhere, customers will continue to have issues with offshore applications that require the exporting of sensitive data. New applications required by the U.S. Patriot Act can serve as a good example. On October 26, 2001, President Bush signed this into law. The act provides a wide range of enforcement tools to combat money laundering and the financing of terrorists. It requires that financial institutions implement antimoney laundering compliance programs, prepare and file suspicious activity reports and follow new “know-your-customer” procedures. As part of this, institutions must check new customers against lists of suspected terrorists and terrorist organizations. Will U.S. clients be comfortable with Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


237

terrorist checks in Pakistan? I do not think so. Perception defines reality and foreign-based Patriot Act processing will be perceived badly by the public. The trend towards corporate governance will make data sensitivity greater as well. Sarbanes Oxley has created a frenzy of documentation. Companies will be required to document “material” systems, their vulnerabilities, define control points and testing strategies. This documentation needs to be certified by external auditors. Material systems operated with limited visibility in lessdeveloped countries will create compliance exposure for corporations.

D: Lack of Process in Offshoring As discussed in Chapter VIII, the first release of software for a new product is often tailored to the needs of the early adopter customer. Here the feature match to the customer is extremely high since it was built to the customer’s specification. Unfortunately, there was no standard software development process used that would allow a high percentage of the “code base” to be reused. Features were hard coded and no administrative tools were built. There was no APIs used to integrate with their internal applications and there was no formal architecture and design process. So how does this product development cycle change when you add offshore engineering? The above “one-off” stage may be lengthened by the use of offshore development. Offshore companies can rapidly place a lot of inexpensive talent at a task. This is one of their great strengths. In cases, this leads to ignoring SDLC or other development process. In addition, software development methodologies require strong communication and conceptual skill. For the reasons discussed of language and distance, these are not the strength of offshore resources. It may be difficult to work out that object-oriented design approach via e-mail with your partner in New Delhi. This difficulty may bias the market company to short cut formal processes and may lead to ignoring the rebuilding stage of Chapter VIII completely. On the positive side, over time off shoring may encourage market company firms to apply formal processes to software development. The desire for control and visibility will require formal methods to be applied more rigorously


238 Le Clair

than they are today. Specifications will have to be tighter. User Interfaces must be carefully scripted. Controlling the versions of software is more important then ever due to concerns over IP.

E: Bias Toward Substitution of Labor for Technology Offshore companies are biased towards labor-oriented processes. By contrast, the high cost of labor in the U.S. promotes the substitution of technology for labor. This means your offshore partner is not always motivated towards the most efficient process. It makes sense. Why invest in an expensive software development environment and process when you have programmers costing $500 a month? Why invest in technology for your operational process when you are getting paid by the hour. What does this mean for the market company? It may mean that your U.S. competitors are using advanced development environments and will have a higher rate of software reusability in the future. It may mean that the cost of your foreign workflow process will scale linearly with additional volume and at some point will be less efficient than the U.S., solution.

F: Use of Proprietary versus Off-the-Shelf Technologies Cost and time to market are the normal variables used in the software company’s decision on whether to build a technology in house or buy it (partner) from the outside. These variables are distorted when offshore resources are involved. With offshoring, labor is so inexpensive; it makes sense for the software company to build almost everything from scratch. So what’s the problem? Why nor build everything from scratch? Partnering for software introduces licensing and intellectually property issues discussed in Chapter XII such as channel conflicts and a loss of control over that feature set. There are several reasons why partnering for a software component is better than building it in house that go beyond cost and speed. For one, customers are Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


239

more comfortable with more open systems. They prefer Oracle to a proprietary database. And then there’s scalability. The off-the-shelf product will have more features, more testing, and in theory would have gone through the rebuilding stage to become a more generalized platform. The offshore-developed software will no-doubt initially be something of a “hack”. It will do what it needs to do, but not much else. Software maintenance will be higher since a lot of recoding to make enhancements will be required, but again with costs so low, it may not be such an issue. For all of these reasons, the decisions concerning development platforms and build versus buy for software components should be made with strong input by the market company. Sales and marketing, maintenance, and long-term control issues should be considered in addition to speed to market and cost. Offshore software development should stay focused on the truly proprietary intellectual property the company is building without compromising an open solution that can benefit from best of breed components. IP leverage can also be improved by insisting the technology components used by your offshore contractor is made up of off-the-shelf components. Generalized industry platforms are more easily taken over by another subcontracted development company or by the market company itself.

An Offshore Development Approach The model shown in Figure 13.3 has proven effective in merging the IP creation of the market company with the raw development power from off shore. Figure 13.2 shows an ideal division of work when using offshore resources. As shown, the development of critical IP task remains largely in the U.S. Product vision, design activities, and initial prototype creation also remain in the U.S. The offshore model breaks the development task into presentation, business rules, and integration layers (Fowler, 2003). The presentation layer handles the interaction between the user and the software. This includes the provision of services, the display of information, and navigation of user requests. This function requires the deepest understanding of HCI and Human Factors and has the highest interaction with the customer. The Market Company best does it. The business rules are the primary work the application needs to do, such as calculations, validation of any data, and can be effectively developed off shore.


240 Le Clair

Figure 13.2. Model for offshore development Market Company

Offshore

US-Based Prototype

Product Vision

Customer Refinement

Presentation

Architecture Validation of customer fit

Final QA

Source Code Control

Coding and Initial Testing

Updates and Maintenance

Business Rules

Integration Layers and Services

The integration layer includes building the Application Program Interface (API) and making sure integration commitments are met.

User Interface Deficiency It is dangerous to generalize, but off shore development’s strength is in software development and not in the user interface (UI) design. UI design is not the strength of programmer’s anywhere, so this is not surprising. In any case, the UI design should be resident in the market country both for its proximity to the customer, availability of best practices in HCI and human factors, and the obvious connection to the prototyping function. The prototype is the best way to communicate requirements to the off shore counterpart, and makes life easier for developers, testing engineers, writers and trainers.

Architecture Enterprise systems involve lots of data; hundreds of concurrent users, scores of user interface screens, and have to integrate with other systems. These attributes make architecture critical to enterprise solutions. Most of the systems discussed in this book such as CRM, ERP, E-BPP and content management



241

all fall in this category. Enterprise systems differ from point solutions such as video game software that operate with a small number of users in a controlled or isolated environment. The enterprise solution’s architecture is therefore very important. Architecture conjures up a vision of senior technical staff looking at white boards and thinking about the big picture. It starts with the highest-level breakdown of a system into parts and then reviews design tradeoffs for each. These tradeoffs include the selection of underlying software and hardware platforms, the degree and scope of system interfaces, product adoption strategies, and which components should be purchased from the outside or built internally. Decisions on architecture affect the system under development for many years and should be driven by the market country as shown in Figure 13.2. Basically do not let your offshore development team make architectural-level decisions.

Quality Assurance Routine testing activities are leaving the high-cost economies. This trend results from cost and as well as quality. In many cases, there is a more disciplined and detail-oriented work practice available off shore. This is obviously important for quality in repetitive testing and operational tasks. It is possible that the solution to the software quality crisis was discovered in Korea in the 15th century. The following is from Daniel J. Boorstin’s The Discoverers, quoting, apparently, Kim Won-Yong from Early Movable Type in Korea (1954): “The supervisor and compositor shall be flogged 30 times for an error per chapter; the printer shall be flogged 30 times for bad impression, either too dark or too light, of one character per chapter.” (Minow, 1991, p. 1) Boorstin continues, “This helps explain both the reputation for accuracy earned by the earliest Korean imprints and the difficulty that Koreans found in recruiting printers.”


242 Le Clair

Whatever the method of software quality, final testing should reside in the market country. It should be independent of the off shore team that built the product. A U.S.–based product manager should oversee the final testing stage and help acquire and manage the beta test sites prior to the final release.

Getting the Specification Correct (Keep Increments Small) A significant challenge with offshore development is that they are not tightly linked to the market-company strategy. This makes it critical to get the specification correct and described unambiguously. In tightly linked homogeneous, co-located team, there is informal communication. “Doing the right thing” is often dependent on software development’s intuitive understanding of the market and strategy, as scary as that sounds. This intuitive understanding of what you are trying to do is just not there with off shore and there is little to keep the ship from veering off course. To make matters worse, once the train has left the station it is difficult to pull it back, that is, once begun it is difficult to correct a development. Once the prototype has been provided for off shore development, it is very difficult to provide changes that come up. It is important that an incremental approach be used to keep the “work module” short, so that off shore development does not force the company into a semi “waterfall approach”. In short, dole out the work in pieces; keep commitment small and specifications tight. It is important to initiate a new piece of work with the marketing requirements document (MRD) to accompany the prototype. This is important in any organization, but acquires added importance for a company with offsite development. The specific form or size of the document is less important than the requirement that it: • • •

Completely and clearly describe the desired functionality. State the target date for general availability of the product. Clearly define increments and keep them small.



243

Contingency Planning Always have an offshore contingency plan. This may be as simple as training local staff to be able to take over in an emergency. A second approach is to have a second offshore partner doing some work for you but ready to take over if a disruption in services occurs. The reasons for having a back up are sound. The countries that provide offshore support today are not the most politically stable. A back up will provide continued support in the event of a disruption of service. One of the keys for this is to maintain strict software “source code” control. This allows the alternate offshore group to be able to pick up quickly. It also provides essential control over the IP. Thirdly, a back-up plan may soon be required to support documentation requirements of emerging governance regulation. If the offshore service supports one of your customers “material” systems, they may require a back-up strategy. Fourthly, a back up capability will provide leverage with your offshore partner and help maintain good pricing. Offshore countries are beginning to “value price” their services. Prices in India were the first to start going up, and you may want to look at China. The back up capability would allow you to switch, or at least give that appearance, and will help keep your partner honest. And finally, depending on the size of the project, it may make sense to put someone over there.

Summary If a car is made with a defect, it will cost millions to fix. Consumers will be sent letters and repairs will have to be made at thousands of locations. A defect in software by comparison, is easy to fix. It can be repaired with a “patch”, provided on a CD or over the Web. Software defects have a low cost compared to other products. This low cost of defects in software has contributed to our casual development processes described earlier. But off shoring will force stronger process around software development for the following reasons:


244 Le Clair

•

•

•

The cost of errors in design will go up due to the difficulty of correcting an offshore development activity once it has started. This will cause more formal processes to evolve with tighter specifications. User interface design will be carefully scripted because the offshore programmers and designers will not understand what the user is trying to accomplish. Versions of software will be more tightly controlled due to concerns over intellectual property abuses.

Economics argues that a product or service should be produced wherever it can be done cost effectively, and since January of 2000, we have lost some 160,000 jobs to offshoring (Techsunite.org: OFFSHORE Tracker, 2005) with this logic. While this is a small fraction of the millions of jobs lost in the recent downturn, it has contributed to the jobless recovery we are seeing and created a major political issue. Governments around the world are beginning to reward firms that do not use off shoring even though it promotes free trade and improves the image of the more developed countries by sharing their wealth. As a result, we may force foreign call center operators to identify their locations. They will say, ‘speaking from China’ and thankfully, we will know the location of the person explaining our bill. These are important but short-term issues. The bigger danger long term is the loss of the infrastructure for creating intellectual property. As argued, it is not just about cheap labor anymore it is about smart labor. Once we stop inventing leading edge technology, the developed country becomes merely the market to sell to. Now, what do we do about that?

References Minow, M. (1991). An ancient method for assuring software quality. Email quote March 31 from W. Kim (1954). Early movable type in Korea. Seoul, Korea: Eulyu Publishing. Dennison, D. (2002). Boston Globe Article. Fowler, M. (2003). Patterns of enterprise application architecture. Reading, MA: Addison-Wesley. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


245

Macarty, J., Dash, A., & Liddell, H. et al. (2002). 3.3 million U.S. services jobs to go offshore. Cambridge, MA: Forrester Research. Techsunite.org (2005). Retrieved February 5, 2005: www.techunite.org


246 Le Clair

Chapter XIV

Company Valuation and Financing

Alice asks the Red Queen for directions, The Queen answers, “That depends on where you want to go.” And in another line, the Queen observes, “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” From Alice in Wonderland (Humes, 1997) There is been much written on the period between Netscape going public on August 9, 1995, and NASDAQ peaking at 5,048.62 on February 29, 2000. March 10 of that year, by the way, was the worst day to buy stocks in 70 years (Berenson, 2004). This was not a normal period and this chapter will not attempt to explain it. Our goal is to understand the effect of the financing process on the emerging company. Venture capitalists (VCs) and investment bankers are a big part of that process. They are in the background but affect the company’s behavior every day. “How to succeed” would not be complete without a basic understanding of their motive and behavior. For background, an overview of the venture capital and investment banking process is provided. What is the owner’s unique perspective and how does this Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


247

affect the company? How is the value of the emerging company determined? And finally, what are some important lessons from inside the boardroom?

The Venture Capital Process VCs receive money from investors and purchase shares of emerging companies. Like a mutual fund they diversify by investing in many companies. The typical VC portfolio may have 10 or more than 100 companies in it. In good days, you needed only one company to be a winner. It would provide an extraordinary return and make up for many failures. But during the Internet bust no level of diversifying could insulate VC portfolios from large losses. The public, by far, were the biggest losers and watched as over a trillion dollars of accumulated value disappeared. VCs and investment bankers set the stage for much of this loss, one of the greatest in the history of the stock market. Despite this period, the VC system remains an essential part of the innovation infrastructure that we are fortunate to have. Previously banks financed infrastructure changes like the railroad and provided this capital formation role. Today great universities, innovative minds and unrelenting sprit, combine with the VC system to create, nurture, and produce new technology.

On a Short Leash Contrary to what most people believe, the real client of the emerging company is not the customer, it’s the VC investors since it is there money being spent in the early days. As a result, managers in small companies are frequently less independent than their mature company counterparts. Management teams that do not satisfy the investors are quickly and easily replaced. On the positive side, senior board members can play a critical role in advising and guiding the emerging company. The well-connected VC can steer the company towards early customers and alliances. They do not just provide money; they provide “smart” money. As important, a prestigious VC firm lends credibility. They help overcome customer concerns over the financial stability of the emerging company. In the early days of the software company “anchor” customers are also highly visible and have great influence over the direction of the company. After all, they Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

248 Le Clair

are perhaps one of three customers, and they have money. The pressure is great to switch core development off the generalized product and build for their specific needs.

Investment Banking The role of the investment bank is to organize and market new shares of the companies stock. They sit as a middleman between the emerging company and the institutional and individual investors who purchase the new stock. They also serve as the broker for a merger or acquisition of the company. To understand how all these relationships tie together, lets review some of the primary abuses of the Internet boom period.

The Chinese Wall A Chinese Wall is a way to make sure that different parts of a firm are kept separate. Financial service and law firms, in particular, use this concept to avoid conflicts of interest. A Chinese wall was required to exist between the investment banking unit, who organizes the public offering, and their proprietary stock research units. The research group, that oftern is part of the same financial services firm as the Investment banking unit, should rate all stocks objectively and not favor new offerings being underwritten by their sister division. Unfortunately for the public, the Chinese wall was found to have structural problems during the Internet boom. During this period investment bankers competed aggressively for the emerging companies business. They touted their ability to distribute shares at the highest value through their institutional and retail business. In a blatant disregard for the sanctity of the wall, the competitive battleground became how porous the wall was. The investment banking firm would boast to the private company that their research analyst had great influence and would generate positive discussion about the young firm. The prestige of their analyst will obtain the highest possible share value. And of course they were correct. The investing public believed their analysts and took their advice. Credit Suisse First Boston (CSFB) was one of many firms’ singled out. They Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


249

promised to provide high-tech companies with positive stock ratings even in the event of bad news and withheld research reports until certain firms paid investment-banking fees. A “smoking gun” proposal listed stock charts and data points attesting to CSFB’s bias in “company analysis” for its banking customers (Healey, 2002). As indicated, this phase of history was unique, and these problems have been largely corrected through new compliance regulations. Lets now look at how new markets are formed.

New Market Creation Venture Capitalists constantly look for new companies to invest in. Most of these opportunities come with new markets. How are these markets formed and how are companies in that market valued? Most new markets are created by technological change. The client/server architecture shift of the early ’90s was one. Availability of reliable digital services created the data communications market in the mid ’90s, The Internet in the late ’90s, created demand for tools, middleware, and content management products. The first firms developing technologies for these applications created these markets. Figure 14.1 shows a simple model for understanding how this occurs.1

Phase One: Value Creation As shown in Figure 14.1 new markets begin with hopeful suppliers trying to find value. They focus on tactical solutions to a specific customer problem. As these companies begin to scale, the market begins to attract the interest of investors, the analyst community, trade associations, and media. The market begins to form.

Phase Two: Competitive Entrants In Phase Two, momentum begins to build in the new market as other software companies determine the product area is viable. They enter the market and invest in marketing communications and product development.


250 Le Clair

Figure 14.1. Model of new market creation Perceived Market Value

Analyst Validation

Mature Companies Enter Market Likely Transaction Post-Technology Era

Competitive Entrants Value Creation

Likely Transaction Technology era

One-offs One-offs

Mature Applications

Solution Productivity

These early applications are one offs and lack the scalability and features needed to meet industry requirements. But as shown in Figure 14.1, excitement about the new market is at the highest just at the time when solutions are the least productive.

Phase Three: Analyst Validation Industry analysts track these new markets as they are created. They advise purchasers of technology and suppliers on the new market, the best products, and the viability of new entrants. This is a big business. Gartner Group’s Dataquest’s software team tracks over seventy distinct markets for the enterprise software area alone (Grahm, 2004). Markets are very specific. In the data communications field, for example, a single diagram showing connected host computers and networks will contain specialized devices, interconnecting cables, and software applications to manage and control the network. Each figure on the diagram probably contains a distinct market covered by analysts, and where each day companies compete for market share. As discussed, analysts tend to be bullish on the potential size of new markets. The new market is immature with little empirical data to drive estimates. In fact, the very creation of the market being studied depends on the success of the emerging companies. In short, early projections of the size of new markets tend to be exaggerated.



251

Phase Four: Mature Companies Enter the Market As firms develop generalized platforms and emergent requirements are satisfied, true productivity is achieved during Phase Four. Also at this time, established companies enter the market. They will do this by developing a product internally or acquiring a company. Figure 14.1 shows when a transaction is likely to occur in the current period and contrasts this with a few years ago. In the technology period an IPO or acquisition was likely in Phase Two, when the perception of the market was very high. In the post technology period this would occur when mature companies enter the market and when emerging companies have achieved a strong financial model and proven the productivity of their solution. The cycle in Figure 14.1 shows that the highest market value is during the initial analyst validation. It is also one of the lowest points of real productivity for the solution in the industry. Not surprisingly, the value at this time is based on future market growth and not on real revenues in the market. With this in mind, let’s look at how this cycle for market creation affects strategy at the emerging company.

A Model to Position the Company The firm’s business plan formed the basis for the initial round of financing and positioned the company in a certain market. Yet, value creation is incremental, as we have seen, and the company will go through several strategy changes on the way to maturity. In speaking to CEOs of software companies, getting financing is easy. The hard part is in between financing and maturity where strategies are likely to change often (Duffy & Laracey, 2004). The VCs who own the emerging company continually assess its value for an IPO or for a direct sale. Their goal is to obtain the highest value in the shortest amount of time. New markets and changes in the value of existing markets influence how the VCs position the company. They will move it towards the highest value, which is usually the hottest perceived market. Value is determined by comparing the company with others in the same market. It is found by multiplying projected revenue or profit by the value assigned for


252 Le Clair

that market. For example, the value on a manufacturer of printer hardware components may be a multiple of only one times revenue. The manufacturer’s product may be a commodity and the market may be in decline. Each dollar of revenue projected by the manufacturer may be worth only one dollar of value. This value is lower than that of an enterprise software company. The software vendor has a large potential market with potentially high margins. It may have a value of three times revenue. The market space and the “comparables” are very important questions for the investors in the company. The positioning model in 14.2 can help focus on the right market. It shows all relevant markets for the company and estimates the potential size of each. Inside each market, it is useful to see the competitors that have emerged. On the horizontal access are the company’s core value drivers. The model maps these potential markets against the company’s value drivers as defined in Chapter X. The most logical market for the firm to attack is the one that combines the highest market value with the best match to its strength.

Overlapping Markets The overlapping diagrams are intentional and recognize that a software company could be positioned in more then one market. For example, call center staff may use the product, or it may collect important customer information, so it may be positioned in the CRM market. There may be a high degree of consulting prior to implementation so it may be a candidate for one of the professional services market. Or it may use business process automation and replace paper, and be in one of the document management or business process outsourcing markets. The product may have a powerful filtering and reporting feature that is useful for monitoring financial systems. As such, it could be positioned for the business intelligence market that is gaining in value. This framework tracks the development of obtainable markets and monitors their change in value. Where the company should go is a mixture of core value drivers and where it can maximize its value. This process will help the emerging company determine its true soul over time.



253

Issues from the Boardroom Understanding the market you are in can be difficult. Understanding the market you want to be in is also challenging. Once determined though, execution becomes the focus. Some of the tensions around execution are discussed next.

The Mind Set of Exponential Growth After many years in the technology business, you develop a feeling for how long a given initiative will take. Unfortunately, it is almost always longer than anyone wants to hear. This is because technologies are just a form of knowledge that evolves in a gradual and incremental way. You just do not go from inventing the wheel to a Porsche Boxer in one fast step. Initial technology ventures are at almost always at the wheel stage. As pointed out, the goal of the investors is a transaction, or a “liquidity event”. Their job is to get the highest possible value for the transaction to maximize returns for investors in their venture fund. In order to achieve this goal, the emerging company in their portfolio needs to show high growth in an emerging market. Growth is important because the value of the company is based largely on its potential revenue and profit at some point in the future. The owners will negotiate the firm’s price, whether it is during an IPO or acquisition, based on revenue projected in those out years,. and they will argue for the highest growth number supportable. With this logic, the pressure on short-term growth is intense. The emerging company needs to show a trend in revenue consistent with the out year revenue projections. In other words, history must support the projection of growth that is argued by the venture capitalists. For these reasons, the software company is often under pressure to achieve triple-digit growth rates and this pressure is likely to continue. Firms will continue to race against product delivery and revenue milestones. But hopefully, with the pressure to catch the market gone, firms can now grow more incrementally and at a pace consistent with their development. “First mover” and “market share” strategies can be used to accelerate growth are still viable. These remain part of the enterprise software vocabulary and are described in the Appendix A.


254 Le Clair

Meeting the Numbers As Bill Parcells, the very direct super bowl-winning football coach, says, “You are what your record is.” By this he means discussion of how much talent the team has or how many close games they could have won is meaningless. The only thing that counts is your won and loss record. In business this is even truer then in sports, you are what your numbers say you are. It is the way the company’s investors keep score and if you ever become public it is how the stock market will evaluate your worth. However, it is tempting to make the number more than what it is. It is really only an indicator of performance. This was clear at Enron, WorldCom and many others. Just because a company hits a number does not mean all is well, and conversely because a number is missed it does not mean the company is failing. Life in the software business is a battle with delayed contracts, last-minute customer reorganizations, and late software products. Accountability based on revenue forecasts is part of good management but revenue goals based on evolving and untested value propositions are best viewed in a broader context. For companies like WorldCom and Enron rapid and unprecedented growth became the only goal that mattered and it could only be achieved through acquisition and accounting strategies. Organic growth through superior value was too slow a path to meet objectives. These business lost site of the customer.

Scaling the Business Development Team A similar obsession with growth is characteristic of emerging companies. Unfortunately, once exponential growth is deemed essential it can lead to premature expansion of the sales force. The logic has a certain appeal to it. If you need to double the revenue over the next four quarters, simply double the sales force. In many cases, the firm ends up hiring a set of “gunslingers” to attack the market. But they do not have enough bullets to shoot, because the company has not yet developed a clear and viable value proposition. Without it, the market opportunities will not be in great enough number to meet the growth expectations. Often the management team can convince the board that they have the needed value proposition for expanding sales but in many cases they do not. One goal



255

Figure 14.2. Positioning model Market Value

E-CRM Outsource (14B) Competitor A….N Professional Services (10B) Competitor A….N Business Intelligence(250M) Competitor A….N Electronic Delivery (6 B) Competitor A….N Core Value Drivers

of this book is to provide a more systematic way to debate this very important point. Meanwhile the effect of the company can be severe. The ramped up business development activity will exacerbate the discipline problems discussed throughout this book. As a result, precious investment dollars may be spent unwisely. As we have shown, building value is an incremental endeavor. The sales force can be scaled in an incremental way as well.

Summary In the last ten years, we have had companies that made a fortune for investment bankers, VCs and entrepreneurs, and in many cases produced little of value. We also had companies that created sustaining technical and business innovation, while making little money for anyone. The same speculative environment, that produced this inconsistency, surrounded earlier infrastructure improvements such as the railroad, automobile, telegraph and the telephone. Hundreds of companies were formed and rushed into these new markets as well and many failed. Twenty years after the first automobile, there were more than 100 manufacturers in the U.S. Within 10


256 Le Clair

years the number was reduced to around 40. By the end of the ’50s it was down to eight and stands today at under three (Moore, 2003). Emerging companies are fighting through this current hangover. Investors who, only a few short years ago, threw money at companies with no chance now withhold money from promising ventures. The period we are entering now will hopefully do a better job of correlating value with contribution. In the current period we can expect waves of new and productive applications. The infrastructure at corporations and for consumers has reached a level that will allow technology to be applied like we have never seen before. We can all be successful. We just need a more fundamental view, one tempered by experience, and that takes a systematic view of the customer.

References Humes, J. (1997). Nixon’s ten commandments of statecraft. New York: James C. Humes Scribner. Berenson, A. (2004). The number: How the drive for quarterly earnings corrupted Wall Street and corporate America. New York: Random House. Healey, B. (2002, October 7). Credit Suisse tactics revealed. Boston Globe. Retrieved April 17, 2003 from: nl.newsbank.com/archives Grahm, C. et al. (2004, January 16). Software Market Research Methodology and Definitions, 2003-2004. Dataquest, Gartner Group. Duffy, M. & Laracey, K. (2004). Interview with Mike Duffy of OpenPages and Kevin Laracey edocs. Conducted between July - August 2003. Moore, M. (2003). Stupid white men. New York: Regan Books.

Endnotes 1

Figure 14.1 was influenced by the well-known Gartner Group “Hype” curve. Gartner’s Hype Cycle, introduced in 1995, characterizes the typical progression of an emerging technology from over enthusiasm



257

through a period of disillusionment to an eventual understanding of the technology’s relevance and role in a market or domain. Several technology life cycle models attempt to gauge the evolution of a technology. These include the performance S-curve, which shows the increase in a technology’s performance over time, and the adoption curve, which shows market adoption over time.


258 Le Clair

Appendix A: First Mover Advantages and Market Share Strategies “First movers” establish their product in a leadership position before the competition. They are able to sell without a strong competitor for a brief period of time. It is the lion roaming the plains filled with wallabies and zebra, and no other natural predators. Being a first mover will sustain higher margins for the emerging company and, allow the early entrant to establish standards and “set the bar” for firms that follow. Market share strategies hope to lead to first-mover advantages. In a market share approach, the firm will sacrifice margin and often lose money to gain market share. Firms do this to benefit from the “herd mentality” that exists in buying behavior, and for the overall respect paid by analyst, trade media, and investors. Businesses prefer buying a product from a market leader. This preference is stronger for enterprise solutions. A firm will not invest time in a company with low or insignificant market share that may not be there tomorrow. They do not want to be dependent on a firm that will be purchased, dissolved and present contractual issues down the road. This fear has gotten worse with the high rate of small technology company failures in the past few years. A market share strategy can pay off. It allows the firm to acquire customer leverage. Once your software is installed it is hard and painful to replace. An enterprise solution must be a significant failure to be replaced. Strong leverage accrues to the incumbent solution. A market-share strategy can help position a company in an early-stage market. Customers are trying to consolidate the number outside technology vendors. It is getting harder to break into a company as a result. Larger companies are getting better at adding to their product lines and bundling services. The smaller number of outside technology providers, the more simple their management, the better pricing, and the lower integration costs. As a result, firms are reducing the number of vendors, software and hardware platforms and the number of small third party software products. An established contract, however small, and an installed product with a company are very important in this environment. Your easiest next sale is always to the existing customer.



259

Market Share Estimates Market Share approaches can help build momentum. Because of this, emerging companies are obsessed with their “market share”. This obsession leads to a fair amount of license taken by companies in describing how much they have. It is hard to tell what the truth is, except that what the supplier is claiming is probably exaggerated. These early markets contain mostly private companies with no verifiable public information. And there are many ways to count market share with no standard. A vendor can count their share as a percentage of revenue, items shipped, and transaction’s processed. Or they can count server installations or the number of users. I once presented to a group of analysts. Our marketing department had prepared a market-share estimate that projected we had a fast growing 30% market share. An analyst raised their hand and said I was the fifth vendor they visited to have at least a 30% market share.


260 Glossary

Glossary

ADP: API: ARPA: ASP: ATM: BBN: BBN: BEA: BI: BPR: BSC: B-to-B: CD: CEO: CFO: COBIT: COBOL:

Automated Data Processing Application Program Interface Advanced Research Project Agency Application Service Provider Automated Teller Machine Bolt, Beranek, and Newman British Broadcasting Network Bill Coleman, Ed Scott, and Alfred Chauang (founders of BEA Systems) Business Intelligence Businesss Processing Re-engineering Balanced Score Card Business-to-Business Computer Desk Chief Executive Officer Chief Financial Officeer Control Objectives for Information and Related Technology Common Business-Oreiented Language


Glossary 261

COSO:

Committee of Sponsoring Organizations of the Treadway Commission CPU: Central Processing Unit CRM: Customer Relationship Management CSR: Customer Service Representative DBA: Database Administrator DMAIC: Define, Measure, Analyze, Improve, and Control DOI: Diffusion of Innovation E-BPP: Electronic Bill Presentment and Payment EDI: Electronic Data Interchange EDS: Electronic Data Systems EPM: Enterprise Performance Manager ERP: Enterprise Resource Planning GI: Genetics Institute GST: General Systems Theory HP: Hewlett Packard HTML: Hypertext Markup Language IBM: International Business Machines IBM/SNA: International Business Machines Systems Network Architechure IMP: Information Message Processors IP: Internet Protocol IP: Intellectual Property IQ: ISDN: ISO: IT: ITIL: JAD: KB: KM: KPI:

Intelligence Quotient Integrated Services Digital Network International Standards Organization Iinformation Technology Iinformation Technology Infrastructure Library Joint Application Development Kilobytes Knowledge Management Key Performace Indicator


262 Glossary

LA: Los Angeles LAN: Local Area Network MIT: Massachusetts Institute of Technolgy MRD: Marketing Requirements Document MY SAM: My Sprint Account Manager NPV: Net Present Value NT: New Technology PARC: Palo Alto Research Center PC: Personal Computer PDP: Peripheral Data Processor (Digital Equipment Corporation) PKI: Performance Key Indicators POD: Print on Demand POS: Point of Sale PR: Public Relations PSC: Progress Software Corporation R&D: Research & Development RAD: Rapid Application Development ROI: Return on Investment SAP: Systeme, Anwendungen Priduckte In Der Datenverarbeituns SCM: Supply Chain Management SDLC: System Development Life Cycle SEC: Securities Exchange Commission SFA: Sales Force Automation SIX SIGMA: Quality Control Technique SOAP: Simple Object Access Protocol SVP: Senior Vice President TAM: Technology Adoption Model TASC: The Analytical Sciences Corporation TCP: Transmission Control Protocol TRA: Theory of Reasoned Aciton UI: User Interface


Glossary 263

UK: VAR: VC: VP: XML: Y2K:

United Kingdom Value-Added-Reseller Venture Capitalist Vice President Extended Markup Language Year 2000


264 About the Author

About the Author Craig Le Clair is vice president of Automated Data Processing (ADP) Brokerage Services, where he is focused on next-generation solutions for the brokerage and financial services market. His career in enterprise systems spans 20 years and began with commercialization of early Internet technology at BBN Communications. BBN designed the initial data communications core for the Internet and pioneered other innovations such as developing the first Internet router and sending the first e-mail. Le Clair has held senior positions with several leading companies in the document management, content management and business process automations markets and has published more than 20 articles on technology and marketing. He holds a bachelor of science degree in economics from Georgetown University and an MBA from George Washington University. He has taught at George Washington University and Montgomery College.


Index 265

Index

A advice application 225 Al Gore 196 Alfred Einhorn 144 Alfred Korzybski 174 alliance execution issues 226 alliance maps 223 alliance partners 47 alliance Paths 217 alliances 216 Amazon 68, 99 attitude Checklist 25 anchor customer 171 anchor customers 247 anthropology 11 Apple 206 application development tools 2 application program interfaces (APIs) 50 application service provider (ASP) 102 application silos 70 applying socio-technical principles 169 architecture 240 Arpanet 195 Arpanet IMPs 198 artificial intelligence 199

as well 255 ASP 193 assemblers 32 assessment and validation 171 assessment map for implementation 134 assessment Model 189 assimilation 6, 40, 43, 130, 217 attitude 27, 35, 170 attitude profiles 25 automated data processing (ADP) 103 automated teller machines (ATMs) 112 avoiding Conflict 220

B back office 70 balanced scorecard 7, 118, 122, 134, 171 BBN Communications 144 behavior change map 16 behavior-centric 15 behavioral change 5, 10, 13, 29 behavioral change map 15 behavioral map 25 behaviorally-dependent business cases 114


266 Index

best practice 2, 19 bias towards substitution of labor for technolgy 238 Bill Gates in Business at the Speed of Thought 29 Bill Parcells 254 Boehm 148 Borland Software Corporation 78 branch locations 180 bread crumb trails 87 Bryce Ryan and Neal Gross 43 bubble period 48 build versus buy 99, 100 build versus buy zone 100 built to Last 187 business case 113 business development 204 business development Team 254 business intelligence (BI) 1, 135 business process automation 29 business process outsourcing 252 business process re-engineering (BPR) 11,12 business process technology 233 business processing outsourcing 2 business to-consumer (B-to-C) 35 business-to-business (B-to-B) 35 business-to-business technology 134

C C++ 32 call details 223 capability maturity models (CMM) 149 careers 27, 170 change 24 change management support 82 change-management process 71 Charles Darwin 34 check on analyst estimates 194 check usage 45 Chief Financial Officer (CFO) 204 Chinese Wall 248 Christensen 41 circuit- switching product line 199 CISCO 41, 187 co-marketing 218

CobiT 119, 126, 213 CobiT’s focus 119 code base 237 cognitive science 17 company valuation 246 compatibility 44 competitive intensity 46 complete business process 46 complexity 44 compliance fulfillment 57 computer literacy 87 computer simulation 199 conflict 220 conflict period 219 confusion 45 consent 56 contact network corporation 51 contingency planning 243 control objectives for information and related technologies 213 control of intellectual property 232, 235 controlling the sales process 173 core competency 103 COSO 119 creative pricing models 115 credit card 175 credit card company 176 credit card statement 178 Credit Suisse First Boston (CSFB) 248 CRM 252 crossing the chasm 222 culture 232 cusotmer relationship marketing (CRM) 46 customer 3, 14, 74, 129, 143 customer core competency 6, 98 customer interaction 164 customer relationship management (CRM) 1, 53, 109 customer self-service 114 customer service representative (CSR) 84 customer turnover 122 customer-focus 171 customer-focus variables 129 customer-focused categories 4 customer-focused implementations 11


Index 267

customer-focused view 4 customers 163 Cybernetics 11, 14 CYYNET 198

D dangerous learning curve 229 data collection 54 database administrators 32 database management systems 2 dataquest 250 David Norton 9 defense data network 228 Dell Computers 8 departmental silos 70 Descarte’s attitude 134 developing country 206 diffusion of innovation (DOI) 11, 42 diffusion of innovation theory 41 digital equipment corporation (DEC) 195 direct payment 35 discovery framework 162 disk operating system (DOS) 109 disorientation 30 disruption 3 disruptive 41 distributed systems 199 drag and drop 110 Duke University 108 dumb terminals 109

E e-billing 114 E-BPP 34, 85 e-business 70 e-business middleware 49 e-commerce 7, 98 e-mail 56, 35, 216 e-mail management 104 e-payment 116 e-sign 47 E.M. Rogers 43 early adopters 43 early customer involvement 178 early majority 43

ease of use 15 eBay 33 ecology 15 Edocs 114, 116 EDS 99 Einhorn, A. 144 electronic banking 35, 112 electronic bill payment market 28 electronic bill presentment 34, 84 electronic bill presentment and payment 84 electronic data interchange (EDI) 89 electronic signature 47 Elixir Technologies 115 emergent demand 59 emerging initiative 204 engineering 208 English 235 Enron 213, 254 enterprise resource planning (ERP) 1, 109 enterprise social networking 52 enterprise software 3, 41 enterprise software application 110 enterprise software installations 65 enterprise software suppliers 221 enterprise systems 12 entrepreneurs 204 ethnography 17 evolutionary (spiral) methods 148 eXcelon Corporation 33 exponential growth 253 Extended Markup Language (XML) 90 external analysts 193

F famous S-shaped diffusion curve 42 fast follower 60 fat clients 110 fidelity investments 99 first mover 253 flying too close to the sun 100 foot soldiers (sales) 210 Forester Research 231 formal requirements definition 169 framework overload 119


268 Index

front office 71 full behavior path 15

G Gabriel Tarde 42 Gartner Group survey 79 General Motors 99 general semantics 175 general systems theory (GST) 12, 14 generalized platform stage 152 Genetics Institute (GI) 165 Geoffrey Hyatt 53 Geoffrey Moore’s Crossing the Chasm 43 Google 53 Gordon Moore 106 gross margins 74 group functioning 170 growth value gap 50

H hard science 11 hard science approach 11 “hard” structural factor 13 HCI 5 healthcare 108 healthcare insurance 116 hemophiliacs 165 Hershey Corporation 68 high-speed scanners 30 hockey stick revenue growth 194 HP 8 HTML prototypes 87 human computer interaction (HCI) 16 human computer interface (HCI) 11, 164 human factors 5, 17 hybrid seeds 43

I IBM 41, 45 IBM SNA data communications 199 Imaginary X 107 information technology(ies) (IT) 1 infrastructure 66

infrastructure burnout 66 innovators 43 intangibles 118 integration gap 70 Intel corporation 106 intellectual property 58, 101, 232 intellectual property protection 58 interdependence 80 interdependence 71 International Standards Organization (ISO) 90 Internet 22, 49, 102, 115, 145, 179 Internet boom 248 Internet Protocols (IP) 41 investment banking 248 IP protection strategy 59 IPO 251 isolated mindset 143 issues from the boardroon 253 IT 81 IT governance 213 IT industry 108

J Jacob Moreno 52 JAD 11 jobless recovery 108 joint application development (JAD) 147 joint customers 218 jump the channel 228 jumping the channel 228

K Kaplan and Norton 118 Ken Olse 195 Ken Rugg 32 Kevin Laracey 114 key performance indicators (KPI) 120 knowledge management (KM) 53

L lack of process 237 laggards 43 LAN-to-LAN traffic 198 language 232


Index 269

language and culture 235 Larry Ellison of Oracle and Bill Gates of Microsoft 196 late majority 43 lead sheet 188 learning curve 229 legacy 70 legacy typesetting 37 legitimate use of “Vaporware” 168 liquidity event 253 locked in 46 longwall 12 longwall mining 12 Lotus Domino 54

M mainframes 109 management support 23 management theory 11 mapping of technology markets 134 market company 235 market share 250 marketing 208 marketing communications 209 marketing high technology 222 marketing requirements document (MRD) 169 material system 213 maturity 161 Merrill Lynch 99 meta data 92 meta Group 66 Michael Hammer 20 microfilm revenues 104 Microsoft 8 Microsoft Exchange 54 Microsoft NT 190 Mike Duffy 85 mind dhare 228 MIT 195 Moore, G. 43 multi threading 32 My Sprint Account Manager (MySAM) 122

N NASDAQ 246 NASDAQ peaking 246 National Coal Boards 12 net present value (NPV) 122 Netscape 246 new market creation 249 NewRiver 51 NewRiver, Inc. 51 Novocain 144 nuclear research 110 number of departments involved 94

O object-oriented database 31 object-oriented design 11 object-oriented design approaches 4 object-oriented design methods 148 object-oriented development 11 ObjectStore 5, 28, 31 observability 44 off-line behavior 19, 23 offshore development approach 239 offshore resources 231 office automation 17 offshore development 232 offshoring 237 on a short leash 247 one-off solutions 8 one-off stage 207 one-off stage 151 one-off syndrome 150 one-off systems 207 open 25 OpenPages 6, 85 Oracle 31, 41 Oracle Corporation 203 overlapping markets 252

P pain value gap 51 PARC 16 partnerships 217 patents 60 patterns of value gaps 168


270 Index

PDP 1 195 perceived ease of use 23 perceived ease of use 23 perceived usefulness 22 perceived usefulness 22 Pete Reiser 141 Peter Morgan 88 pockets of value 81 post-technology era 66 postscript commands 178 PowerBuilder 200 print on demand (POD) 57 process view 19, 71 process-technology 75 process-technology gaps 6 product adaptation strategies 71 product adaption strategy 94 product assessment grid 132 product champion 210 product design 10 product development 141, 143, 231 product view 19 product-centric 15 professional status 23 progress software corporation (PSC) 34 proprietary database 239 prospectus 56 Prospectus Express 56 protecting IP 59 prototype feedback 170 prototypes 175 public relations 210 pure marketing meetings 171

Q quality assurance 241

R RAD 11 RAND 147 Rand 11 random statement generator 177 rapid application development (RAD) 147 rapid market assessment 163 rapid prototyping 181

Ray Tomlinson 197 rebuilding stage 152 recipe 172 record keeping system 225 relational database 31 relationship of marketing, sales, and engineering 208 relative advantage 44 resistant 25 return on investment (ROI) 7, 108 revenue 232 Richard Bolt and Leo Beranek 195 Richard Lazarus (a senior scientist at BBN) 92 risk management models 118 risk profile 24 road rage 114 Rogers' model 50 roles 170 Ronald Reagan 153, 175

S Sabre 99 sales 208 sales cycle 65, 71, 94 sales force automation (SFA) 53 SAP 41 SAP integration partner 218 Sarbanes Oxley legislation 6 scaling the organization 206 scandals in the financial services industries 213 scattergun approach to business development 144 SDLC 11 SDLC model 3, 147 Section 302 of Sarbanes Oxley (SOX) 86 securing mind share 228 securities and exchange commission (SEC) 104 security 236 security of sensitive data 236 selling meeting 171 service-to-license ratio 6, 65, 93 Siebel Systems, Inc. 116


Index 271

simple object access protocol 90 Simula-67 148 Siral 11 Six Sigma 113 skills 170 smart money 247 smoking gun 249 Snuff Factor 227 social networking 51 social networking corporation 51 social psychology 11, 17 socio-technical library 170 socio-technical systems 11 socio-technical techniques 162 socio-technology theory 13 sociogram 52 “soft” human factor 13 soft science 11 soft science approach 11 software 74 software development process 8 Software Engineering Institute (SEI) 150 Sony 146 spiral 148 spiral model 148 dpirited 25 split-personality customers 99 stakeholders 13, 20 Stanley Milgram 52 Star Wars 153 Steve Jobs 206 Stovepipe Problem 113 strategic assessment 189 strategic frameworks 118 Sun workstation 178 sunk costs 112 supply chain management (SCM) 1, 45, 92 switching costs 92 Sybase 200 system components 14 systems administrations 32 systems development and life cycle (SDLC) 3 systems development life cycle (SDLC) 11, 147

systems engineering 11, 147 systems integrator 221 systems programmers 32 systems theory 11

T TAM 22 target partners 222 tasks 170 TCP/IP 90 technology 2 technology acceptance models 21 technology adoption 162 technology adoption curve 115 technology adoption model 11 technology era 67 technology leverage 48 technology markets 134 telecommuincations 116, 223 the @ sign 197 The Balanced Score Card 7 The Business Case 7 The Chinese Wall 248 The Compression Approach 229 The Council of Logistics Management 29 The Humongous Market 192 The Innovator’s Dilemma 41 The Integration Gap 70 The Mind Set of Exponential Growth 253 The “one-off” syndrome 150 The Origin of Species 34 The Role of Marketing 210 The Sales Role 211 The Snuff Factor 227 The Stovepipe Problem 113 The Time Zone Advantage 234 The Vision Thing 187 The Word is not the Object 175 Thelonius Monk 188 Theory of Reasoned Action 11, 21 thin clients 110 Thomas Edison 107 Thomas Siebel 80 thrill of the chase 143


272 Index

time-zone differences 234 tollbooth 216 TQM 11 training 65, 94 trends in service license ratios 72 trialability 44 Trist & Bamforth 12 trolls 111 typesetting services 36 typing pools 107

U U.S. Patriot Act 236 UNIX systems 199 Use of Proprietary Versus Off-the-Shelf Technologi 238 user 3 user attitudes 21 user behavior 15 user interface deficiency 240 using the assessment model 195

V

W waterfall 11 waterfall development 147 Web services 65, 89 Web-based typesetting service 36 wizards 196 work queue 31 workflow 30 workflow projects 233 WorldCom 213, 254

X X.25 198 Xerox 205, 206 Xerox Palo Alto Research Center (PARC) 11 XML 90 XML databases 49

Y Y2K 167 year 2000 preparations 66

value 1, 251 value 217 value added teseller (VAR) 221 value creation 231, 249 value discovery process 161 value drivers 187 value gap 50, 131 value gap discovery 164 value gaps 165 vaporware 168 VC portfolio 247 venture capital and investment banking 246 venture capitalists 40, 246 venture capitalists (VCs) and investment bankers 246 vertical applications 71, 76 vignette 85 viral scaling 40 virtual dressing rooms 19 visual basic 32


Instant access to the latest offerings of Idea Group, Inc. in the fields of I NFORMATION SCIENCE , T ECHNOLOGY AND MANAGEMENT!

InfoSci-Online Database BOOK CHAPTERS JOURNAL AR TICLES C ONFERENCE PROCEEDINGS C ASE STUDIES

“

The Bottom Line: With easy to use access to solid, current and in-demand information, InfoSci-Online, reasonably priced, is recommended for academic libraries.

The InfoSci-Online database is the most comprehensive collection of full-text literature published by Idea Group, Inc. in:

”

- Excerpted with permission from Library Journal, July 2003 Issue, Page 140

n n n n n n n n n

Distance Learning Knowledge Management Global Information Technology Data Mining & Warehousing E-Commerce & E-Government IT Engineering & Modeling Human Side of IT Multimedia Networking IT Virtual Organizations

BENEFITS n Instant Access n Full-Text n Affordable n Continuously Updated n Advanced Searching Capabilities

Start exploring at www.infosci-online.com

Recommend to your Library Today! Complimentary 30-Day Trial Access Available! A product of:

Information Science Publishing* Enhancing knowledge through information science

*A company of Idea Group, Inc. www.idea-group.com

RECENT RELEASE Enterprise Resource Planning Solutions and Management Fiona Fui-Hoon Nah University of Nebraska, USA Enterprise resource planning (ERP) refers to large commercial software packages that promise a seamless integration of information ﬂow through an organization by combining various sources of information into a single software application and a single database. The outcome of ERP itself is still a mystery, but the trends and issues it has created will be the enigma that future generations will have to solve. Traditionally, separate units were created within an organization to carry out various tasks, and these functional areas would create their own information systems thereby giving rise to systems that were not integrated. ERP strives to provide a solution to these problems. Enterprise Resource Planning Solutions and Management examines the issues that need to be further studied and better understood to ensure successful implementation and deployment of ERP systems. ISBN 1-931777-06-3 (s/c) • eISBN 1-931777-26-8 • US$59.95 306 pages • Copyright © 2002

“By addressing not only current situations but also future possibilities, Enterprise Resource Planning Solutions and Management provides a clear picture of the best methods and practices related to this application system.” Fiona Fui-Hoon Nah, University of Nebraska, USA It’s Easy to Order! Order online at www.idea-group.com or call 717/533-8845 x10! Mon-Fri 8:30 am-5:00 pm (est) or fax 24 hours a day 717/533-8661

IRM Press

Hershey • London • Melbourne • Singapore

An excellent addition to your library

New Releases from Idea Group Reference

Idea Group REFERENCE

The Premier Reference Source for Information Science and Technology Research ENCYCLOPEDIA OF

ENCYCLOPEDIA OF

DATA WAREHOUSING AND MINING

INFORMATION SCIENCE AND TECHNOLOGY AVAILABLE NOW!

Edited by: John Wang, Montclair State University, USA Two-Volume Set • April 2005 • 1700 pp ISBN: 1-59140-557-2; US $495.00 h/c Pre-Publication Price: US $425.00* *Pre-pub price is good through one month after the publication date

Provides a comprehensive, critical and descriptive examination of concepts, issues, trends, and challenges in this rapidly expanding field of data warehousing and mining A single source of knowledge and latest discoveries in the field, consisting of more than 350 contributors from 32 countries

Five-Volume Set • January 2005 • 3807 pp ISBN: 1-59140-553-X; US $1125.00 h/c

ENCYCLOPEDIA OF

DATABASE TECHNOLOGIES AND APPLICATIONS

Offers in-depth coverage of evolutions, theories, methodologies, functionalities, and applications of DWM in such interdisciplinary industries as healthcare informatics, artificial intelligence, financial modeling, and applied statistics Supplies over 1,300 terms and definitions, and more than 3,200 references

DISTANCE LEARNING

April 2005 • 650 pp ISBN: 1-59140-560-2; US $275.00 h/c Pre-Publication Price: US $235.00* *Pre-publication price good through one month after publication date

Four-Volume Set • April 2005 • 2500+ pp ISBN: 1-59140-555-6; US $995.00 h/c Pre-Pub Price: US $850.00* *Pre-pub price is good through one month after the publication date

MULTIMEDIA TECHNOLOGY AND NETWORKING

ENCYCLOPEDIA OF

ENCYCLOPEDIA OF

More than 450 international contributors provide extensive coverage of topics such as workforce training, accessing education, digital divide, and the evolution of distance and online education into a multibillion dollar enterprise Offers over 3,000 terms and definitions and more than 6,000 references in the field of distance learning Excellent source of comprehensive knowledge and literature on the topic of distance learning programs Provides the most comprehensive coverage of the issues, concepts, trends, and technologies of distance learning

April 2005 • 650 pp ISBN: 1-59140-561-0; US $275.00 h/c Pre-Publication Price: US $235.00* *Pre-pub price is good through one month after publication date

www.idea-group-ref.com

Idea Group Reference is pleased to offer complimentary access to the electronic version for the life of edition when your library purchases a print copy of an encyclopedia For a complete catalog of our new & upcoming encyclopedias, please contact: 701 E. Chocolate Ave., Suite 200 • Hershey PA 17033, USA • 1-866-342-6657 (toll free) • [email protected]

IT Solutions Series – New Releases! Humanizing Information Technology: Advice from Experts Authored by: Shannon Schelin, PhD, North Carolina State University, USA G. David Garson, PhD, North Carolina State University, USA With the alarming rate of information technology changes over the past two decades, it is not unexpected that there is an evolution of the human side of IT that has forced many organizations to rethink their strategies in dealing with the human side of IT. People, just like computers, are main components of any information systems. And just as successful organizations must be willing to upgrade their equipment and facilities, they must also be alert to changing their viewpoints on various aspects of human behavior. New and emerging technologies result in human behavior responses, which must be addressed with a view toward developing better theories about people and IT. This book brings out a variety of views expressed by practitioners from corporate and public settings offer their experiences in dealing with the human byproduct of IT.

ISBN 1-59140-245-X (s/c) • US$29.95 • eISBN 1-59140-246-8 • 186 pages • Copyright © 2004

Information Technology Security: Advice from Experts Edited by: Lawrence Oliva, PhD, Intelligent Decisions LLC, USA As the value of the information portfolio has increased, IT security has changed from a product focus to a business management process. Today, IT security is not just about controlling internal access to data and systems but managing a portfolio of services including wireless networks, cyberterrorism protection and business continuity planning in case of disaster. With this new perspective, the role of IT executives has changed from protecting against external threats to building trusted security infrastructures linked to business processes driving financial returns. As technology continues to expand in complexity, databases increase in value, and as information privacy liability broadens exponentially, security processes developed during the last century will not work. IT leaders must prepare their organizations for previously unimagined situations. IT security has become both a necessary service and a business revenue opportunity. Balancing both perspectives requires a business portfolio approach to managing investment with income, user access with control, and trust with authentication. This book is a collection of interviews of corporate IT security practitioners offering various viewpoint on successes and failures in managing IT security in organizations.

ISBN 1-59140-247-6 (s/c) • US$29.95 • eISBN 1-59140-248-4 • 182 pages • Copyright © 2004

Managing Data Mining: Advice from Experts Edited by: Stephan Kudyba, PhD, New Jersey Institute of Technology, USA Foreword by Dr. Jim Goodnight, SAS Inc, USA Managing Data Mining: Advice from Experts is a collection of leading business applications in the data mining and multivariate modeling spectrum provided by experts in the field at leading US corporations. Each contributor provides valued insights as to the importance quantitative modeling provides in helping their corresponding organizations manage risk, increase productivity and drive profits in the market in which they operate. Additionally, the expert contributors address other important areas which are involved in the utilization of data mining and multivariate modeling that include various aspects in the data management spectrum (e.g. data collection, cleansing and general organization).


E-Commerce Security: Advice from Experts Edited by: Mehdi Khosrow-Pour, D.B.A., Information Resources Management Association, USA The e-commerce revolution has allowed many organizations around the world to become more effective and efficient in managing their resources. Through the use of e-commerce many businesses can now cut the cost of doing business with their customers in a speed that could only be imagined a decade ago. However, doing business on the Internet has opened up business to additional vulnerabilities and misuse. It has been estimated that the cost of misuse and criminal activities related to e-commerce now exceeds 10 billion dollars per year, and many experts predict that this number will increase in the future. This book provides insight and practical knowledge obtained from industry leaders regarding the overall successful management of e-commerce practices and solutions.


Its Easy to Order! Order online at www.cybertech-pub.com, www.idea-group.com or call 717/533-8845 x10 Mon-Fri 8:30 am-5:00 pm (est) or fax 24 hours a day 717/533-8661

CyberTech Publishing Hershey • London • Melbourne • Singapore

Excellent additions to your library!

How To Succeed In The Enterprise Software Market

How to Succeed at the Medical Interview (HOW - How To)

How To Succeed as a Lifestyle Entrepreneur

Power Of Motivation - How To Succeed In All Circumstances

How and when to Invest in the Stock Market

Negotiate To Succeed

Software Fortresses: Modeling Enterprise Architectures

How to Invest in the Uk Property Market

Succeed: How We Can Reach Our Goals

How to Succeed at Interviews: Includes over 200 Interview Questions

How to Succeed at Interviews: Includes over 200 Interview Questions

Humanize: How People-Centric Organizations Succeed in a Social World

Humanize: How People-Centric Organizations Succeed in a Social World

Succeed: How We Can Reach Our Goals

Humanize: How People-Centric Organizations Succeed in a Social World

The Moral Advantage: How to Succeed in Business by Doing the Right Thing

Reengineering Software: How to Reuse Programming to Build New, State-of-the-Art Software

Enterprise-Scale Agile Software Development (Applied Software Engineering Series)

Against the Grain: How to Succeed in Business by Peddling Heresy

Mobilizing the Community to Help Students Succeed

Interoperability of Enterprise Software and Applications

The Visual Investor: How to Spot Market Trends (Wiley Trading)

Agile Project Management: How to Succeed in the Face of Changing Project Requirements

How to Succeed at Being Yourself - Finding the Confidence to Fulfill Your Destiny

Organizing the Disorganized Child: Simple Strategies to Succeed in School

JUNOS Enterprise Routing: A Practical Guide to JUNOS Software and Enterprise Certification

How To Succeed In The Enterprise Software Market

How to Succeed at the Medical Interview (HOW - How To)

How To Succeed as a Lifestyle Entrepreneur

Power Of Motivation - How To Succeed In All Circumstances

How and when to Invest in the Stock Market

Negotiate To Succeed

Software Fortresses: Modeling Enterprise Architectures

How to Invest in the Uk Property Market

Succeed: How We Can Reach Our Goals

How to Succeed at Interviews: Includes over 200 Interview Questions

How to Succeed at Interviews: Includes over 200 Interview Questions

Humanize: How People-Centric Organizations Succeed in a Social World

Humanize: How People-Centric Organizations Succeed in a Social World

Succeed: How We Can Reach Our Goals

Humanize: How People-Centric Organizations Succeed in a Social World

The Moral Advantage: How to Succeed in Business by Doing the Right Thing

Reengineering Software: How to Reuse Programming to Build New, State-of-the-Art Software

Enterprise-Scale Agile Software Development (Applied Software Engineering Series)

Against the Grain: How to Succeed in Business by Peddling Heresy

Mobilizing the Community to Help Students Succeed

Interoperability of Enterprise Software and Applications

The Visual Investor: How to Spot Market Trends (Wiley Trading)

Agile Project Management: How to Succeed in the Face of Changing Project Requirements

How to Succeed at Being Yourself - Finding the Confidence to Fulfill Your Destiny

Organizing the Disorganized Child: Simple Strategies to Succeed in School

JUNOS Enterprise Routing: A Practical Guide to JUNOS Software and Enterprise Certification

Recommend Documents