There are reasons for these cause-and-effect relationships, based on the way in which IS/IT evolves in organizations and the way in which the IS/ IT strategy has to respond and become more sophisticated and better balanced over time. This also implies that a number of different methods need to be in place at any one time to develop a relevant and complete portfolio. Most of the models address the need to accommodate both centralized and decentralized management approaches, the balance of which will depend on the degree of integration required in the business and organ- izational processes. Particular competitive opportunities and new uses of IT will tend to address singular or few applications and, initially at least, can be exploited most advantageously close to the business opportunity. Applications that produce benefits by business integration or sharing of assets require strong business coordination, competent IS/IT manage- ment and sustained investment in resources. The Sulli van model helps understanding of how the application portfolio will evolve by the effects of these forces within an organization. CLASSIFYING THE APPLICATIONS IN THE PORTFOLIO How to populate the portfolio with future IS/IT investments is described in the preceding chapters, and the basic rationale for a portfolio approach was discussed in Chapter 1. Describing the existing and future applications in this way helps the task of obtaining a consensus among executive managemen t, line managers and the IT management on the content of the IS strategy. Once the portfolio is understood and agreed, decisions on how best to manage each application, both existing and future, can be made, along with overall decisions on the use of resources across the portfolio and the selection of the most effec- tive sources for supply—which aspects should be managed in-house and which can and should be outsourced. While agreeing the contribution and, hence, portfolio positioning of future investments is important, so is understanding the role of and value to the organization of the existing application set. Some applications may be obsolete and no longer required, others may need significant invest- ment to avoid future business problems, some may be underexploited and others may be consuming undue amounts of resource in relation to their business value. Table 7.1 suggests a set of criteria that can be used as a basis for a strength, weaknesses, opportunities and threats (SWOT) analysis of the current applications, to determine the need for action, either to improve their contribution or enable other, related applications to be developed or used better. Classifying the Applications in the Portfolio 305 Merelyclassifyingcurrentandfutureapplicationsintoa2×2matrixis of no great value, unless it causes each application and the overall port- folio to be managed more effectively. The process of classifying the applications is as important as the end result, since the discussion involved will enable different perspectives to be unde rstood (and hope- fully reconciled!) and the implications of the decisions made to be appre- ciated by all parties. If a particular application is considered by one group of users as strategic, due to their uses of the output, and as support by another that provides the input, it is unlikely that the maximum benefits available will be delivered, due to the differing operational priorities and quality of information management in each group. A realistic and agreed assessment must be made. Each organization will have slightly different interpretations of the terms used for each segment. Hence, a decision-support tool that would fit every organization’s criteria for classification cannot be defined, but Box 7.1 contains a simple starting point for the process, by posing question s that can help the analysis. It should only be used to guide the assessment, not as a ‘rule book’. Normally, it is relatively easy to agree and classify most of the applications into the quadrants, although there are always some where discussion, based on different perceptions of their role and contribution is necessary. If agreement cannot be reached, it often means that the ‘system’ needs to be considered at a lower level, in terms of the main functions it performs. For example, an Accounts Receivable syst em may consist of 306 Managing the Applications Portfolio Table 7.1 SWOT analysis of existing portfolio Analysing the applications in the portfolio (SWOT) EXPLOIT STRENGTHS: . high future potential, currently underexploited; . can be extended, enhanced to be of more value; . could be more valuable if integrated more effectively or used more exten- sively; . critical to the business, but data quality is poor; . needs to be developed to meet current and future business needs; . must be enhanced to meet changed business requirements for future; . system required, but needs to be reimplemented to absorb less resources or overcome technology obsolescence; . system will be less important in future—needs to be simplified/reduced to real needs; . system is no longer of value—should be discontinued. OVERCOME WEAKNESSES Classifying the Applications in the Portfolio 307 Box 7.1 Classifying the applications in the portfolio Questions Ifthedevelopment * succeeds,willit: (a) Result in a clear competitive advantage for the Yes/No business? (b) Enable the achievement of specific business Yes/No objectivesand/orcriticalsuccessfactors? (c) Overcome known business disadvantages in relation Yes/No to competitors? (d)AvoidforeseeablebusinessrisksbecomingmajorYes/No problems in the near future? (e) Improve the productivity of the business and, hence, Yes/No reduce long-term costs? (f) Enable the organization to meet statutory Yes/No requirements? (g) Provide benefits not yet known, but may result in Yes/No (a) or (b) above? * For existing applications the question is, is the application deliver- ing benefits that ’ Interpretation In answering the questions above, the reasons for the judgement should be stated. The table below shows how the answers can be interpreted and the application classified, based on whether or not any Yes answers appear in a column. If more questions produce a Yes answer in any one column (i.e. the application appears to be in more than one category), then it should be reassessed by splitting it into its major components and considering each of them in the same way (i.e. the application should be broken down into subprojects). If this is not done, the risks of failure will increase dramatically due to the mixed objectives and the confusion that it can cause once the project proceeds. High potential Strategic Key operational Support (a) Yes (i) (b) Yes (i) (c) Yes (d) Yes (e) Yes (f) Yes (ii) Yes (ii) (g) Yes several business processes or subprocesses, some of which may be more business critical than others—bad-debt control may be key operational, whereas statement production is support. Although many applications are often provided via large packages (e.g. ERP and CRM software), the purpose of the analysis is still to classify the business activities that the package covers (e.g. order processing, purchasing), rather than the package itself. An ERP package can deliver applications in all quadrants, depending on the competitive positioning, the business strategy and the maturity of IS/IT development in the organization. It also follows that the portfolio is not a way of classifying tech- nologies—email, groupware, intranets, the Internet and a data warehouse can all be used for a variety of applications, making different co ntribu- tions to different business activities. And to reiterate a point made in Chapter 1, an application utilizing cutting-edge technology does not imply that it is automatically classified as strategic—classification must be based on business contribution. An example portfolio for a manufacturing company, produced using the question set in Box 7.1 and showing a simplified version of the SWOT analysis described above, is shown in Figure 7.3. Reconciling Demand and Supply Issues in the Applications Portfolio Before considering the best approaches to managing the applications in the different segments, it is important to understand the key differences in the rationale for the types of application and the resulting issues to be addressed in implementation. Discussion in Chapters 4–6 considered what might be described as the driving forces for applications in each segment of the portfolio (i.e. why they are being developed and how eventual success or failure will be determined). They can be translated into some critical requirements to be satisfied in the delivery of the application. These key issues are described in Table 7.2. 308 Managing the Applications Portfolio (i) If either applies, the supplementary question is Yes/No then, ‘Is it clear what the business benefits are and how they can be obtained?’ If Yes it is Strategic,if No it is High potential. (ii) To clarify which it is, the following que stion should Yes/No be asked, ‘Will failure to comply lead to significant business risks (be specific about the risk)?’ If Yes it is Key operational,ifNoitisSupport. To ensure overall success , it is important that decisions about how to implement the system (e.g. package or bespoke development) are directly related to decisions about what is required. Both of them have to derive as clearly as possible from the initial decision making on why the invest- ment is being made, in term s of the contribution required . Albeit somewhat simplistically, Figure 7.4 attempts to pose simple questions that the chosen implementation strategy should address. Understanding the management implications of these questions offers guidance on how best to manage each application through its life cycle. Figure 7.4 shows how the questions become more complex as we move around the matrix. For support applications, the general objective is clear (why=efficiency)andwhatneedstobeimprovedisdeterminedby existing tasks and activities. The main question is how to do that success- fully, in terms of the most cost-effective use of IT. For key operational applications, the how question still has to be addressed, but in addition Classifying the Applications in the Portfolio 309 Figure 7.3 Example portfolio for a manufacturing company 310 Managing the Applications Portfolio Table 7.2 Some key issues in the segments of the portfolio Driving forces Critical requirements High potential New business ideas or Rapid evaluation of technological opportunity prototypes and avoid Individual initiative—owned wasting effort/resources on by a ‘product champion’ failures Need to demonstrate the Understand the potential value or otherwise of the benefits (and the economics) idea in relation to business strategy Identify the best way to proceed—the next step Strategic Market requirements, Rapid development to meet competitive pressures or the business objective and other external forces realize benefits within the Business objectives, success window of opportunity factors and vision of how Flexible system that can be to achieve them adapted in the future as Obtaining an advantage and the business evolves then sustaining it Link to an associated business initiative to sustain commitment Key operational Improving the performance High-quality, long-life of existing activities (speed, solutions and effective data accuracy, economics) management Integration of data and Balancing costs with benefits systems to avoid and business risks—identify duplication, inconsistency, the best solution and misinformation Evaluation of options Avoiding a business available by objective disadvantage or allowing feasibility study a business risk to become critical/comply with industry legislation Support Improved productivity/ Low-cost, long-term efficiency of specific (often solutions—often packaged localized) business tasks software to satisfy most General legislation needs Most cost-effective use of Compromise the needs to IS/IT funds and resources the software available available Objective cost/benefit analysis to reduce financial risk and then control costs carefully considerable thought may be needed to define specifica lly what has to be done, and to which systems, to avoid potential disadvantage (why we need to do it). Again, both what and how questions need to be resolved in strategic applications, but in addition we need to clearly understand why we wish to do it in terms of the business strategy. Strategic applica- tions require creative thinking and will cause change, probably externally as well as internally, and the reasons for and intended benefits of such changes must be agreed on. By definition, the strategic systems cannot be copied from others (since we will already be potentially disadvantaged!), hence their rationale has to derive explicitly and coherently from the strategy of the organization. If one or two of the why, what or how questions is unanswered, it implies that the application is high potential, and appropriate evaluation is needed to answer the remaining questions before making a large-scale investment. GENERIC APPLICATION MANAGEMENT STRATEGIES Given the variety of factors affecting success in the different segmen ts and the business consequences of success or failure, no single implementation approach is likely to deal effectively with the range of issues involved. Equally, adopting a unique approach to each and every new development Generic Application Management Strategies 311 Figure 7.4 Key questions on the applications portfolio will lead to a degree of chaos and probably result in as many failures as successes. A limited set that meets the majority of requirements and is well understood throughout the organization is more likely to enable the best approach to be selected in each instance and increase the chances of success. Based on extens ive observation of the realities of IS/IT management processes in many organizations, Parsons 11 described five strategies that are prevalent as the means by which organizations link the management of IS/IT to the corporate or business management processes. These ‘linking strategies’ are ‘general frameworks which guide the opportunities for IT which are identified, the IT resources which are developed, the rate at which new technologies are adopted, the level of impact for IT within the firm, etc.’ They are ‘the central tendencies which firms use to guide IT within the business’. As they are ‘general frameworks,’ the term ‘generic strategies’ is used in the discussion below. They are essentially alternative strategies for the implementation of IS/IT, ensuring that the nature of the demand is matched by the appropriate means of supply. How these implementa- tion strategies can be aligned and reconciled with Earl’s planning ap- proaches will be considered on pages 321–323. Parsons described the characteristics and implications of each strategy in detail, and they are summ arized in Table 7.3. As can be seen from the table, the strategies define different roles and responsibilities for the three key parties involved in enabling successful implementation: . executive management; . line management: functional or process managers and users of the systems; . IS/IT specialists: whether or not they are internal to the organization (centrally located or in business areas) or external. As such, the strategies are behavioural and each set of behaviours will cause certain effects. The effects required are determ ined by the nature of the contribution of applications in the portfolio—the generic strategies, therefore, are ways of causing the right effects to occur. Parson’s strategies are: centrally planned, leading edge, free market, monopoly and scarce resource. They are well titled, since the very names evoke a basic understanding of the attitudes and behaviour that each is likely to produce. The key points of each, and their pros and cons, will be outlined at the same time as considering how they relate to the applica- tions portfolio. 312 Managing the Applications Portfolio Table 7.3 Rationale and requirements for generic strategies ( source: after Parsons) Centrally planned Leading edge Free market Monopoly Scarce resource Management Central coordination of Technology can create Market makes the best Information is a Inform ation is a limited rationale all requirements will business advantages decisions and users corporate good resou rce and its produce better decision and risks are worth are responsible for and an integrated development must making taking business results resource for users be clearly justified Integration is not critical to employ Organizational Knowledgeable and Commitment of funds Knowledgeable users User acceptance of Tight budgetary control requirements involved senior and resources Accountability for IS/IT the philosophy control of all management Innovative IS/IT at business or Policies to force IS/IT expenses Integrated planning management functional level through single Policies for controlling of IS/IT within Strong technical skills Willingness to duplicate sourcing IS/IT and users the business effort Good forecasting planning process Loose IT budget control of resource usage IT role Provide services to Push forward Competitive and To satisfy users’ Make b est use of a match the business boundaries of probably profit requirements as limited resource by demands by working technology use on centre —intended to they arise, but tight cost control of closely with business all fronts achieve a return on its non-directive in expenses and projects. managers resources terms of the uses Justify capital of IS/IT investment projects Line managers Identify the potential of Use the technology and Identify, source and Understand needs Identify and cost-justify and users role IS/IT to meet business identify the advantages control IS/IT and present them projects needs at all levels of it offers developments to central utility Passive unless benefits the organization to obtain are identified resources Centrally Planned This generic strategy implies that senior and executive management need to be fully aware of the development, due to its potential impact on the future business strategy. It is therefore most appropriate for strategic systems. Ensuring success in such circumstances demands the attention of senior management, to ensure that the objectives are met and that the necessary resources are applied to deliver the solution in the time required. Most strategic developments are likely to span a number of business areas, and, while the nature of the system can often be easily defined in outline, it will be its uniqueness and its close fit to the business strategy that will deliver the business advantages. To gain those advan- tages, it is almost inevitable that changes to business practices and even organization structure will be necessary. To meet all these requirements, a ‘task force’ approach is best suited. Led by a senior business manager, the team will need dedicated, prefer- ably full-time, high-quality business resources, which have excellent knowledge of the areas affected and the authori ty to agree to business changes. Equally, it will need good IS/IT skills and knowledge in the team to design the system and manage the technical aspects of its implementation. This dedicated team require direct access to top manage- ment to resolve issues that will undoubtedly arise during the develop- ment. Subject to this senior management agreement, the team has the authority to decide both what the syst em will do and how, in business and IT terms, that will be achieved. It is likely that the design and development will be iterative, comparing possible solutions with emerging or ch anging requirements. This requires very close working relationships among the members of the team, individuals’ contributions depending more on their knowledge than formally designated roles. Although the idea of a dedicated team is attractive, it is often difficult to achieve successfully in many organizations. The people it requires are often the most valuable in their existing jobs and are not readily given up by their functional management for the duration of the project. Even though it may not be the most efficient use of skilled and knowledgeable people, it is a very effective way of achieving clear objectives in a tight timescale. The need for key people dedicated to such teams may also limit the number of strategic developments that can be undertaken at any one time, since such key people are often in short supply. It is better to reschedule the projects based on the availability of key resources than to spread the resource too thinly or substitute lower-calibre or less ex- perienced people. This centrally plann ed strategy addresses the needs of strategic applications most effectively, but it could be used in certain circumstances to carry out a short, sharp evaluation of a high potential 314 Managing the Applications Portfolio TEAMFLY Team-Fly ® [...]... 14 F.W McFarlan, Information technology changes the way you compete’, Harvard Business Review, May–June 1984, 93–103 M.J Earl, Management Strategies for Information Technology, Prentice-Hall, Englewood Cliffs, New Jersey, 1989; M.J Earl, ‘Experiences in strategic information systems planning , MIS Quarterly, Vol 17, No 1, 1993, 1–24; M.J Earl, Information systems strategy why planning techniques... Business Strategy Review, Vol 7, No 1, 19 96, 54 67 J.M Ward, Information systems and technology: Application portfolio management—an assessment of matrix-based analysis’, Journal of Information Technology, Vol 3, No 3, 1988, 205–215 C.H Sullivan, Systems planning in the information age’, Sloan Management Review, Winter, 1985, 3–11 M.C Munro and S.L Huff, Information technology and corporate strategy’,... 1193–1201 R.D Galliers, Information systems and technology planning within a competitive strategy framework’, in P Griffiths, ed., The Role of Information Management in Competitive Success, Pergamon Infotech State of the Art Report, Maidenhead, UK, 1987 A Hartman and J Sifonis, Net Ready—Strategies for Success in the e-Economy, McGrawHill, New York, 2000 G.L Parsons, Fitting Information Systems Technology... and J Wyman, Information technology: A strategic opportunity’, Sloan Management Review, Spring, 1984, 3–10 R.D Galliers, Information technology planning within the corporate planning process’, in A Duling and D Berry, eds, Controlling Projects within an Integrated Management Framework, Pergamon Infotech State of the Art Report, Maidenhead, UK, 1987 B Ives and G.P Learmonth, ‘The information system... problem or failure occurred due to incorrect or out-of-date information content Only then was the key role that the ‘informal’ information system was now fulfilling realized and appropriate disciplines, procedures and support resources put in place In one example, salespeople were selling services to customers based on information from the (informal) Intranet catalogue The company no longer offered some... coherent and consistent strategic management These key strategy areas are: for managing investments in IS/IT, to deliver the maximum value in terms of benefits to the business; for managing the data, information and knowledge resources of the organization to ensure that its business value is fully exploited and protected; for managing the acquisition, deployment and utilization of information technologies,... key operational systems and databases as well as related processes and procedures Effective resource utilization—key operational systems cannot be afforded the dedication of resources given to strategic systems it is not justified This implies the integration of the support for the system with other systems sharing resources and expertise to reduce the costs This is a familiar lesson from systems development—transferring... were not strategic Therefore, they soon became support applications; they were still used, but the costs of support were minimized Over time, due to their ease of use, the applications were relied upon as a source of operational information, even though the ‘content’ was not managed in a disciplined way—there were no procedures for maintenance or clear ownership of the components of the information. .. needs, high quality, integrated, maintainable systems are procured or developed and then supported in an overall cost-effective way This is what is required for key operational systems, where a lowrisk, controlled approach to the development process is essential to avoid systems failure and consequent disadvantage The monopoly strategy can be adopted for support systems, but may produce relatively high-cost... ‘refinement’ of strategy during planning and implementation, and its continuing adaptation as achievements (or otherwise) occur or any environmental input changes As noted in Chapter 2, strategic management is a combination of formal planning, creativity, innovation, informal thinking and opportunism, all of which must be effectively exploited and integrated From establishing the strategic direction, through . resources Accountability for IS/IT the philosophy control of all management Innovative IS/IT at business or Policies to force IS/IT expenses Integrated planning management functional level through single Policies for. development, due to its potential impact on the future business strategy. It is therefore most appropriate for strategic systems. Ensuring success in such circumstances demands the attention of senior. critically—the business overall may be prevented from gaining strategic benefits from IS/IT, which largely arise from the integration of systems and information resources. Against that background, the free