IMBOK - 401

For decades IT departments worked with rules for justifying the cost of new systems and the way in which systems development would be undertaken. Over time these rules became ever more onerous; one example is the "waterfall model" that was imposed on US Department of Defense contractors (US Military Standard DoD-Std-2167). It essentially set out one way in which work would be done, and insisted that the work be done in certain stages and with certain requirements before work could proceed from one stage to the next. This stifled innovation and denied the possibility to experiment. Further, it tended to load the cost of minor systems that were, perhaps, only of concern to a few people. Why apply the full set of justification and development requirements when it was just a holiday and sick recording system for the HR department? Just one example ...

One very effective way to break the log jam, and see the very different ways in which applications might be developed according to their nature is a portfolio model that distinguishes:

The notes that follow are taken from the book; there is an extended discussion about the applications portfolio in the book, starting on page 55. The discussion goes on to explain how the issues of funding, risk management, quality management and project management are so very different from one quadrant to the next.

High potential information systems: Applications that may be important in achieving future business strategy

A small proportion of high potential applications might ultimately provide strategic opportunities and help to secure the future of the company. A progressive organisation recognises this, and finds a way to encourage innovation by investing in the future. Laggardly organisations do not recognise this, and generally wait until competitors have established a new information system idea before making the move (by which time the system idea is no longer â€œhigh potentialâ€, nor even â€œstrategic, perhaps). An organisation that refuses to enable high potential activity will always lag, whereas one that nurtures and sustains experimentation will never be short of potentially useful systems ideas.

How does one go about systems development in this quadrant? Not with meticulous attention to standards, nor even with large teams of specialists drafted in to assist. Development in this part of the applications portfolio has to be done by (or in very close conjunction with) the user whose idea it is. The objective is not to change the world nor even to actually implement a working system, but to qualify an information system idea as a good one. Once this qualification is achieved, when everyone agrees that the idea is important, and when the rest of the company has agreed to take it on board, then the style of development will have to change. But until it is approved as a legitimate strategically relevant idea, development needs to be fluid, exploratory, and as rapid as possible. There is no benefit in protracted development; every effort should be directed towards the qualification of the idea, as quickly as possible. If the idea proves to be a good one then it can be progressed, but if it is not then it can be discarded. Survival in high potential systems development activity is as much about failure as it is about success.

Strategic information systems: Applications that are critical to sustaining future business strategy A strategic information system needs to have the support and commitment of business management and all involved staff. Changes to business practice will be involved and the management of change requires a high level of commitment. The specification of requirements must be done with the business in mind and with more attention to what might be done in the future than what is done now. Thus, we might say that business analysts are required, not systems analysts. Good business analysts are difficult to find because they must straddle the divide between the worlds of technology and business; some of the best examples of success can be attributed to talented people who acted in this role and did well, in other cases people have failed in this role and disaster has ensued. Even the best technical specialist will probably fail if given responsibility (by design or default) for the conception and specification of a strategic information system. Business analysis is difficult in the strategic context because of the need to explore new territory, where users will not be able to articulate their needs straightforwardly. A degree of experimentation will be required.

The tools that are used in these cases may be different. The challenge is to formulate and test new ideas about the business in order that they can be realised by means of new systems. The ideas may originate from the high potential quadrant of the portfolio or they may be seeded in corporate strategy: objectives, critical success factors, and the other stuff of strategic analysis. It is important therefore that the communication of business ideas (using appropriate models and possibly prototype systems) is not just encouraged but driven by means of energetic management activity and commitment. In this way all those involved will be able to assure themselves that the proposals are appropriate and stable. Strategic systems are demanding of management time, principally because of the effort that is required to grow an idea, test it, and then settle it down to the point where it can be incorporated into a new system design.

Then the construction of a strategic system needs a particular approach also. The trick is to work quickly because one is seeking competitive advantage and always working within a window of opportunity that might be usurped by competitors. Clearly a new strategic system must work at a functional level and to some extent it will have to integrate with existing systems, but one can not afford to let the IT team dwell upon fine points of detail. It is important that strategic systems are built quickly and competently, but in most cases they will be re-engineered in due course for efficiency of operation. At the start, efficiency in operation is not as important as simple functionality, but nevertheless the development team must try to forecast the workload levels and ensure that there is enough capacity in the infrastructure to sustain the system in use, even if it is planned to re-engineer it later to make it more efficient.

Web sites are a good example. Most large banks have been through the early stage where the critical objective was to get a web site up and running, knowing that the demand would actually be quite low but that the important thing (strategically) was to be able to say that a web site was up and running. Then, famously, a number of banks were embarrassed by the exceptional level of interest, leading to overloading of limited infrastructure and seriously unhappy customers. It is all a balancing act, and we are reminded perhaps that strategic information systems demand a culture and a context that is willing and able to deliver change. Without that, an organisation might be better advised not to even start, but to wait until the merit of a new idea has been adequately demonstrated by competitors (so as to be a laggard in these things, not a leader).

Key operational information systems: Applications on which the organisation currently depends for success Key operational systems are different again. There are fewer mysteries because the area of application is likely to be well known, it is probably already common to all the main players in a certain industry (and so not strategic), and there may well be packages available which provide a suitable vehicle for implementation (although they are not always cheap – when consultancy assistance, support and training are taken into account, six- and seven-figure US$ prices are common for the larger enterprise-wide software packages).

Clearly, there is a pattern here. Larger, more forward thinking companies often find themselves blazing a trail with new ideas that are, in the beginning strategic. They put the new strategic systems together the hard way because only they can afford the very high development and management costs involved. They can justify the expense on the basis of consolidating their dominance of a market. When the ideas begin to be adopted by the majority of players in that market then systems tend to become available from independent software suppliers (sometimes in the form of a modification of a system first developed by one of the main market players). At the same time, these systems can be replicated in competitor businesses more cheaply because the nature of the application has become well known and there will be people around who can be hired for their experience and knowledge of the information systems that deliver it.

Thus, the information systems that comprise the basis of key operational applications may be found as packages and not require bespoke (in-house) development. The requirement still needs to be specified, however, because a good package will provide many options and there will be work to do in setting it up and configuring it properly. Although a package is the primary vehicle for implementation, it still has to be evolved into the information system that the business requires. It is a mistake to confuse the two. If a business decides that using someone else’s system can solve their problems, then they will almost certainly have a hard time with it. Even the best packages require substantial implementation effort because it will have to co-exist with other key operational systems and interfaces will be needed. As many organisations have found, adapting an existing system can be much more difficult than building a new one from scratch.

On the other hand, acquiring a world-class package and then fitting the business around it can be a quick route to efficiency and effectiveness benefits, provided that all necessary changes to working practices are made. For example, for a period of time many large retailing companies around the world chose to use the same package for their core stock management and purchase order processing (a US-originated package called “World Wide Chain Stores”). This does not mean that the businesses have to be the same: the package just deals with the core information processing requirements at the operational level. Here competitive edge comes from the ability to implement such packages well, and to manage the adaptation of the business to make the best use of it. There is still plenty of scope for competitive differentiation with other application areas.

It follows that the key skills for the successful implementation of key operational systems tend to be technical (concerning the set up and configuration of the package) and managerial (for the implementation of operational changes); but senior management do not need to be heavily involved because we are not changing the world, we are merely optimising it. Efficiency and reliability in key operational systems are important, and that requires technical competencies. Depending upon the hardware and software environment, skilled database and teleprocessing specialists will be needed to set up the right infrastructure; with mainframes, system programmers are needed who can tune the environment to give the last percentage point in efficiency with the very expensive infrastructure that is involved.

Key operational systems are not merely advantageous (as a strategic system will be) – they are essential. Generally speaking, without the requisite key operational systems businesses will simply not be able to operate because they will not have the basic capabilities that are necessary to be a viable player in their chosen industry.

Support information systems: Applications that are valuable but not critical to success Support systems are the fourth and final category in our applications portfolio. In many ways they are the most difficult to characterise because this fourth quadrant tends to be something of a mixed bag.

Here we put systems that have little or no strategic relevance. As indicated by the definition (above, and in the figure) they are valuable for some reason but not critical to success. Examples are: local systems used by only one department, for example HR systems that deal with remuneration and sick pay; low level systems that might be widely used but are not critical to business operations, for example budget and expense management; systems that serve statutory needs such as import and export statistics reporting; even pervasive service systems such as email would be most appropriately categorised here when they are not being used for strategic or key operational purposes, which seems to be true in most cases.

The temptation with these systems is to invest a minimum of money and effort, and wherever possible to go for absolutely standard packages even if they do not fit well - the presumption being that we can change the way we do things to fit the package. Using a package obviates the need for any detailed design or analysis. A support system needs only a minimum of analysis, first to be certain that it is truly a support system and then to establish the basic fit to the business requirement. Interfaces with other systems must be investigated because any strong links to key operational or strategic systems might affect our view of things - perhaps if it generates operational data the support system is not a support system at all?

We will soon look in more detail at the different styles of management that are most appropriate for the different quadrants of the portfolio but it should be obvious that for support systems the management effort must come from the local management concerned. There is even a strong argument that the funding for support systems must come from local budgets: if the benefits are confined to one small part of the business, or one small area of the business activity, then why should central budgets be deployed? Hence, local commitment must be assessed to ensure that the system is really required, and that those concerned are willing to manage the implementation project and all that goes with it. Support systems do not justify the use of scarce, skilled systems development resources that are more usefully deployed in the other more valuable quadrants.

Having said this, we might note that there are classic examples where support systems were recognised to have strategic potential. The apocryphal American Hospital Supplies case study has been very widely quoted as a strategic example, but it started with a single buyer in a hospital who decided to go online only because his sales representative noticed they used the same kind of IBM terminal. A support project, surely, as it was originally conceived? Who is going to get excited about a buyer who sets up a link with one of his salesmen? But this was so clearly strategic when later seen in the competitive context.

Tools and techniques - The applications portfolio