Found an old essay of mine dated at 8.1.2003. At that time, I remember being impressed by Eli Goldratt’s classic “The Goal”.  Today – I tend to agree with my younger self (at least in some degree). This definitely deserves to be published after all these years. Ahh… The nostalgy. どうぞ！

ABSTRACT

Information systems are too often built without a proper business case. The reasons for building the system must always be able to be traced back to making more money either by increased profits or reduced costs.

When evaluating the business case reduce the number of assumptions into minimum. Do not for example assume that customers will do this or do that if we just build the system – ask them.

Knowing how the intended information system helps the company to make more money is a critical success factor during the actual making of the system.

Your business as an IT professional is not to build information systems – your business is to help your customer to make more money.

INTRODUCTION

The strategic importance of information systems has been acknowledged for almost two decades now. During the eighties the changes in the consumer behaviour and tightening competition forced companies to develop more powerful and larger information systems. The realization of this strategic importance led companies to start up separate information technology (IT) management departments [Earl 89]. Their  responsibility was to manage the new and powerful strategic asset – and the development of house IT systems [Rockart et al 96].

This essay focuses on what I currently see as one of the main problems in systems development. Thinking (quite correctly) IT-systems as the key strategic asset for conducting succesfull business causes a risk of losing the actual goal in the IT-system development. This problem affects both parties in the development process: The ordering client (usually IT-management in larger organizations) and the software vendor.

The problem manifests itself in numerous ways: Sometimes is seems that we are making systems just because the technology is there (see appendix 1). Sometimes it seems that IT management is having systems built because it is their job to do so. The goal of this essay is to try to get the attention back to the goal itself – Why do we build information systems?

THE GOAL

The idea for this this essay originates in Eli Goldratt’s The Goal: A Process of Ongoing Improvement [Goldratt 98]. The Goal actually examines manufacturing industry’s problems by using Goldratt’s theory of constraints, but another key concept – the Goal – applies to IT development as well; Goldratt cleverly reminds us that the goal for any company is not to make products (or – to produce information systems), increase customer satisfaction or to get more customers. The only real goal for any company is to make money.

Let me say it again: 

The only goal for any company is to make money.

It is important to understand the distinction between the goal and the enablers which make reaching the goal possible. The two basic enablers are 1) increased revenues and 2) decreased production costs. The purpose of a software project can be the making of an enabler, but the purpose should always be traceable back to the actual goal. Figure 1 illustrates the difference between the enablers and the goal.

 

Figure  1: The goal and the enablers example [Rantanen 2000]

GOAL ORIENTED THINKING IN IT DEVELOPMENT

The job of IT-management or any respectful system provider is not to build information systems on request (or to have them built by someone else). IT systems are an ENABLER for making money, not the business case itself. Because of this distiction you should always start with question: ”Why are we making this system – How does it help us to make more money?”

The following chapters focus on how goal orientation affects typical system building process.

Implications on the feasibility study

System development usually starts with a feasibility study phase which should answer the question ”Why”. This phase is sometimes only seen as the enabling technology evaluation (the question in this case is ”Can it be done”), but in my opinion technical feasability should be only a part of the study content. The most important thing is to make clear if building the system is by name feasable – does it help the company to make more money.

The following questions can be used in rough evaluation of the business case:

Does building the system increase profits:

Does building the system decrease costs:

From system vendor’s point of view finding the real motive for building the system (and hence the evaluation of the business case) can sometimes be extremely difficult because of what I call as the ”hidden agenda”. The name refers for those reasons that are seldom or never said out loud. Appendix 2 contains a simple example of the concept.

Rule of the thumb on development projects should be:

Refuse to start the actual development work until you are convinced that there is a business case.

A fair warning for IT professionals though – be mindful on your limitations; IT  experts such as IT management or system vendors seldom have the knowledge of seasoned business domain experts. The use of common sense is encouraged. The role of the IT professional as I see it is to ask the right questions to help the domain experts evaluate the feasability of the project and the system.

Implications on the system analysis, design and implementation

Simply stated, if the system builders do notknow why the system is built, the result WILL NOT SATISFY the customer whoordered the system. No amount of work done in system analysis, functional specificationor user interface design can replace the knowledge on the reasons for buildingthe system. (See appendix 2)

COUNTERARGUMENTS

Critizism on goal orientation usually concerns 1) how goal orientation fits the non-profit organizations whose sole purpose is not to make money and 2) evaluating the system agaist the enablers chain and profit making propability. Lately there has been justified discussion on the 3) ethical side of pursuing profits.

Non-profit organizations

One of the key concepts in economics is the allocation resources based on scarcity [Parkin et al 98]. How well non-profit organizations like churches, universities and municipal schools can serve their interest groups depends solely on the available amount of their resources; that equals money. Money itself becomes the key enabler for reaching the organizations functional goal.

The enablers chain and making profit

How many enablers can there be in between the enabler we are aiming for and the actual goal? Goal orientation specifies no other rule but that the enabler chain must lead back to making more money. The two basic enablers are either increased profits or decreased costs.

Let’s take an example using figure 1 and the increased profits enabler. Quite often new systems or system features are built to ”increase customer satisfaction”. Customer satisfaction is an enabler for customer profitability – existing customers may be willing to pay more money for the services provided. Customer satisfaction may also lead to customer loyalty, which is also an enabler for more profitable customers.

There is no substitute for common sense. By counting the conditionals in the previous sentence (may lead, may be willing to pay) one can see that there is no guarantee that the features built would actually result into making more money.

The point is: Avoid making assumptions. Instead (if the basic enabler is increased profits) conduct a market research in the product’s target market segment. This gives you more accurate estimates on how the product would perform. An example could be: ”5% of our existing target market segment customers (error margin 0.2%) are willing to pay 1 € more per month for the new service”. There is no reason to guess – you can ask.

Market research is naturally only a part of the product development process but an excellent example for this case. In this example market research stands for using cold mathematics in business feasability evaluation of the system. Product development itself should be a part of company’s marketing process, and the decisions you are making during the system building is actually making adjustments to your marketing mix – price, product, placement, or promotion [Kotler et al 99].

The ethical side of pursuing profits

From sociological point of view the real world of course is not as black and white as goal orientation may make it seem. Stating that company’s only real goal is to make money is in a way a child’s naïf way of seeing the world in absolute opposites.

Criticism on how business is conducted is recently raised on especially very large companies; Lawsuits against Microsoft misuse of it’s dominant market position, Nike’s use of child labour in the production of goods, Shell and Ken Saro Wiwa etc. The critizism is quite often targeted to companies who have long ago stopped selling products and moved into selling images and emotions – or to put in another words – selling brands. From individual’s point of view brand thinking results to limited options: No competition, corporate originating censorship, ”McJobs”  (temporary job agreements, reduced safety, poor salaries etc.) [Klein 2000].

Customers are only one of the company’s interest groups. Other interest groups include the owners of the company, employees, subcontractors, the government etc. The point seems to be that making money should be done in a way that all the company’s interest groups are satisfied – conducting business and making money should be a win-win situation among all the company’s interest groups.

SUMMARY

Information systems are too often built without a proper business case. The reasons for building the system must always be able to be traced back to either one of the basic enablers for making more money: Increased profits or reduced costs.

When evaluating the business case with enablers chain reduce the number of assumptions into minimum. Do not for example assume that customers will do this or do that if we just build the system – ask them.

Knowing how the intended information system helps the company to make more money is a critical success factor during the actual making of the system.

Your business as an IT professional is not to build information systems – your business is to help your
customer to make more money. The making of more money should be done in a way that all the company’s interest groups are satisfied.

REFERENCES

[Earl 89] Earl Michael J.: Management Strategies for Information Techology. Prentice Hall 1989

[Goldratt 98] Goldratt Eliyahu M.: The Goal: A Process of Ongoing Improvement (2nd edition), Aldershot, Gower, 1998

[Klein 2000] Klein Naomi: No Logo – tähtäimessä brändivaltiaat (toinen painos), WSOY, 2001.

[Kotler et al 99] Kotler Philip, Armstrong Gary, Saunders John, Wong Veronica: Principles of Marketing,2nd European Edition, Prentice Hall Europe, 1999

[Rantanen 2000] Rantanen Marko: HIHA-malli. [MS Power Point Presentation], Tietoleonia, 2000

[Rockart et al 96] Rockart John F., Earl Michael J., Ross Jeanne W.: Eight Imperatives for the New IT Organization. Sloan Management Review, Vol 38, No 1, Fall 1996

[Parkin et al 98] Parkin Michael, Powell Melanie, Matthews Kent: Economics, 4th edition. Addison-Wesley, 1998

APPENDIX

Appendix 1: Because the technology is there…

A short example from recent history illustrates how sometimes it seems that systems are built just because it can be done.

Enabling technology for wireless mobile phone user interfaces emerged in Finland during 1999. Building new mobile WAP (wireless application protocol) interfaces for older systems was quite a common request for any software company at that time.

At that time it seemed that companies aiming for mobile software provider market were founded at least one every hour. From the newly founded company’s perspective it would have been stupid to ask reasons for building the system – The money was there, and there may be plenty more where it came from. So the vendor was usually not the one who would ask the question ”why”. Sadly, neither did the customer…

Thinking goal-orientedly, we already know what went wrong at that time. The reasoning chain (or enablers chain) went usually like this on the business side: Build corporate image with new high tech system → gain new customers → more money.

The problem was that none of the enablers succeeded as planned. The technology still (spring 2002) does not work as supposed. Because of this building corporate image failed on current general opinion that building WAP-interfaces is more like a sign of poor judgement. The customers simply don’t want to use the tiny screen and slow speed services –  no new customers – no increased revenues. Nobody even bothered to ask the customer if he/she wanted to use the new services provided – let alone pay for them

Appendix 2: Hidden agenda

A very interesting lecture during my computer sciences studies dealt with issues on building information systems for London city. The lecturer (whose name I have unfortunately forgotten) presented us a case on public health care.

The case in short was that the system vendor was asked to build a new hospital patient care information system to replace an existing system. The vendor was confused as they saw nothing wrong with the system currently in use. After a very long discussion the real motivation for building the system was revealed; Another department in the very same hospital had recently built a new patient care system. This new system on the ”competing department” was seen as a threat which gave competitive edge on fighting the budget money (and respect in general) inside the hospital. So actually – the vendor was not asked to build a patient information system, they were asked to build an instrument of war for budget fights.

Now think: How would the resulting system differ if you knew that you were building an instrument of war instead of the patient care information system? Would the functionality of the system be same? Or would we try to reduce functionality into minimum and maximize the ”sexiness” of the user interface, simplicity and user friendliness to get what we really need – satisfied users so we can boast on our systems glory and get more budget money and respect? This is what I mean when I say that no amount of work in systems analysis or design can replace the knowledge on the real reasons for building the system.

Thanks to Marko Rantanen, who was my best and closest colleague at that time. Marko had a very strong influence in writing this essay. Discussions and work with Marko were always the source of sanity on this crazy business of ours. Thx!