An Analytical Approach to Business Cases

(1)

Master Thesis

Information Science, Business Information Systems University of Amsterdam

“The journey begins before the travelers depart.” (Kathy Charmaz)

Author: Kees Notenboom

Supervisor: Prof. T.M. Van Engers Version: 1.0

Date: 13 February 2016

https://www.linkedin.com/in/keesnotenboom kees.notenboom@xs4all.nl

(2)

List of Figures

Figure 1 The relation between the sub questions ... 8

Figure 2 Overview of the research ... 10

Figure 3 Interaction between portfolio management, business case and project management processes ... 20

Figure 4 Three phases in the creation of a business case according to the Treasury Board of Canada ... 23

Figure 5 Conceptual scheme ... 33

Figure 6 A business case scenario example ... 53

List of Tables

Table 1 Word associations for reporting on the interviews... 36

Table 2 Code scheme (initiated) ... 57

Abstract

This thesis analyses the most important aspects of the business case: the purposes, the associated

processes and the components. Based on a grounded theory approach and a literature study some qualitative semi-structured interviews have been conducted. The conclusions highlight four aspects that thus far have not received adequate attention in the literature. One, the rationale for a business change comprises two distinct parts: the need to change the current situation and the rationale for a specific solution. Two, a business case can be created in stages. Moreover, after an early stage business case substantiates this, terminating activities could save the organization money and could protect its credibility. Three, a systematic search for the consequences of an intended business change seems possible. Such a research could reveal costs and risks or discover latent tasks in an early stage of the implementation process instead of appearing as a late unpleasant surprise. Four, the life span of a business case is wider than that of the implementation project; especially the periods before and after the project could contain some lesser known aspects and activities. Finally, the article concludes with a definition of a business case: a continual justification of a business change addressed to a stakeholder who is responsible and accountable for the business processes to be changed. This is an exploratory research and therefore the conclusions are only indicative; it is recommended that further research on these topics will be conducted.

(4)

1 Introduction

In my career as an ICT professional over the last 25 years, I encountered a lot of projects where the business case sooner or later proved to be invalid, or at least weak. Stories of projects gone wrong, either partly or completely, sometimes wasting millions of euros, are well known in the ICT sector. It is needless to mention these here; any experienced ICT-professional will recognize these situations.

The cause of failure is not always a business case of lesser quality, but in many cases at least part of the failure seems to be related to defects in the business case, for instance wrong statistics, weak assumptions or a confirmation bias. The question arises whether improving the business case could help improving the project as a whole.

With this thesis I intend to contribute to scientific insights regarding the phenomenon ‘business case’. As a secondary result I will provide the creators, the decision makers and other parties involved with business cases with some reflective material; thus enabling – and challenging – them to create and maintain business cases that are more suitable to the intended business changes.

1.1 Elias committee

On October 14th of 2014, the Elias committee reported their findings to the Dutch Parliament. The Elias committee was a Dutch parliamentary enquiry committee with the assignment to investigate ICT projects within the Dutch government and governmental institutions.

One of the committee’s conclusions is that the Dutch government was not in control of ICT projects. The committee reported: “Het niet onder controle hebben van ICT-projecten komt tot uiting in

budgetoverschrijdingen, vertragingen in tijd, gebrekkige kwaliteit van ICT systemen en ontevreden stakeholders” (Elias committee, 2014c, p. 11). (Not being in control of ICT projects is expressed by cost overruns, time delays, poor quality of ICT systems and dissatisfied stakeholders, translation KN)

The Elias committee based its conclusions upon an analysis of 7 large governmental ICT projects and a public hearing of 32 specialists. A quote from one of the interviews conducted by the Elias committee, may illustrate one of the possible shortcomings of these business cases:

“Mevrouw Bruins Slot (…): Mevrouw Wildvank, (…). U kunt teruggrijpen op 30 jaar ervaring in de ICT. Welke problemen kwam u tegen bij de vele ICT-projecten bij de overheid waaraan u hebt meegewerkt?

“Mevrouw Wildvank: “Het niet goed definiëren van het doel. Dus het doel wel kennen, maar het niet goed definiëren. Het ontbreken van een architectuur. Dan bedoel ik niet van hoe een huis eruitziet, maar meer de ruimtelijke ordening. Je kunt ergens een huis neerzetten, maar je hebt ook een riool nodig en elektriciteit. Dat is dus het inpassen van wat je maakt in het geheel. En een enorm optimisme over dat bepaalde dingen heel makkelijk zijn, dat het allemaal wel op tijd afkomt. Dat gaat dus om het stellen van niet realistische deadlines.”

(5)

Translation (KN):

“Ms. Bruins Slot (…): Ms. Wildvank (...). You posess 30 years of experience in ICT. What problems did you encounter in the numerous governmental ICT projects you worked for?

“Ms. Wildvank: "Not clearly defining the goal. So, knowing the goal, but not defining it well. The absence of any architecture. I do not mean the appearance of a house, but the environmental planning. You can build a house somewhere, but you also need a sewer and electricity. That is the attuning of what you make within the entirety. And an enormous optimism about things being very easy, that everything will be finished in time. That means setting unrealistic deadlines."

One of the recommendations of the committee states: “Stel een zakelijke rechtvaardiging op waar alle belangrijke onderdelen om een besluit gedegen te kunnen nemen in voorkomen.” (Elias committee, 2014a, p. 10). This translates to: ‘Create a business case which comprises all key components in order to make a sound decision’ (translation KN).

This recommendation is the starting point of my thesis: how should this be done and what are these components?

1.2 Business case

Before introducing the research question, I briefly introduce the term ‘business case’.

As will be demonstrated in the next chapter (Literature: state of the art), a business case is a justification for a project or program to achieve specific organizational objectives. Usually this justification comprises a cost-benefit analysis. However, since the purpose and use of a business case can be much more than merely a financial one, other components can be incorporated within a business case as well. For example, the business case can be used to determine priorities and to assign staff to a project, in which case it will also include an overall project plan.

Usually – but not in all organizations – a business case will be created for each business change, unless it is considered a minor change with only a small impact on the organization. In general, a business case will be constructed prior to the start of the project, or in its first stage. The continued use of the business case may vary among organizations, but there may also be significant differences within an organization. Sometimes the business case will be adjusted or elaborated to a greater detail during the project, sometimes the business case is used to evaluate the project and in some cases, the business case is limited to the initial investment decision.

Next to a financial element, a business case can incorporate more specific components and these components can be more or less detailed. This depends on a few factors like the nature and scope of the project, the procedures within the organization, the legal rules, and the standards imposed by a market regulator.

(6)

1.3 Rational and non-rational factors related to business cases

As can be concluded from the report of the Elias committee, the way organizations deal with business cases should be improved. Though the Elias committee only investigated Dutch governmental ICT projects, there is no reason to assume other organizations would perform better. Why organizations fail in making, updating or evaluating business cases – or creating adequate business cases – remains unclear.

Within the scientific literature, numerous articles about the difficulties of the processes for decision making in general or, more specific, the creation of business cases, can be found. The literature deals with both rational and non-rational factors.

On the one hand, Pedersen (2012) states: “Within theory about organizational decision-making it is generally acknowledged that decision-making can never be 100% rational …” (Pedersen 2012, p. 58). He further mentions the factors uncertainty, politics, emotions and conflicts and finally personal preferences and beliefs. Remenyi & Sherwood-Smith also emphasize that the creation, presentation, as well as many other aspects of the business case are not a mere technical issue, but that these also depend on the corporate culture. On the other hand, the literature provides a broad range of concrete, rational elements and processes related to business cases. (A review of these analytical factors as mentioned in the scientific literature will be the subject of chapter 3 Literature: state of the art.) In this thesis I focus only on the theoretical analytical factors; only occasionally I will refer to these less rational factors. Even if all circumstances were ideal and all involved stakeholders would master all the non-rational factors and skills, the creation (and further use) of a good business case still would depend on these rational factors and the knowledge thereof.

With this thesis I intend to contribute to a scientific understanding of the phenomenon ‘Business Case’. A good theory about business cases at least comprises three main elements: the purposes and components of a business case and the processes affecting a business case or affected by a business case.

1.4 Research question

This preliminary analysis leads to the following research question and sub questions. 1.4.1 Research question

“What are the possible purposes, related processes and components of an adequate business case for ICT projects?”

Though several authors provide check lists or describe a possible creation process for business cases in their line of business, others – for instance Meijer – state that there is no standard for a business case. However, even if there is no standard, this does not exclude the possibility of a shared rationality concerning the

business case. Remenyi & Sherwood-Smith emphasize that a business case with all its details varies with the corporate culture. Purposes, processes and components and the degree of their elaboration, should be considered by every organization while setting the internal standards concerning business cases. Moreover, it is arguable that, despite these internal standards, in specific situations business cases necessarily deviate from these standards. This exploratory thesis aims to identify these possible purposes, processes and components including their rationales.

(7)

1.4.2 Sub question 1: purposes

“What are the possible purposes of an adequate business case for ICT projects?”

The Elias committee identified one goal for a business case: the making of a decision for investment in ICT projects (Elias committee, 2014a, p. 10). However, in their report they mention several other possible purposes, for instance the use of the business case as a means for evaluation while the project is executed (Elias committee, 2014a, p. 126). Apart from those ideas, the report of the Elias committee does not provide an exhaustive list of potential purposes of a business case, nor do any authors in the scientific literature. That is why we should try to make an inventory of possible purposes (or uses) and the related rationales.

1.4.3 Sub question 2: processes

“What are the processes related to an adequate business case for ICT projects?”

If one of the purposes is decision making, the decision making process needs a business case as input before it can deliver its own goals, irrespective of the exact nature of these goals. In general one can derive from each defined business case purpose at least one process that needs the business case or a part of it. Furthermore it is possible that next to the explicitly defined (or main) purposes, more processes use or can use the business case as input. The exact use of the business case by a process defines the requirements of the business case itself. And finally it is possible that a process (for instance portfolio or staffing processes) imposes time constraints on the creation process of the business case itself. Thus knowledge of the processes surrounding a business case can enhance the knowledge of the business case itself.

Note that there are other processes related to the business case, but with another kind of relationship. The intended change almost always includes a process (or more) as the subject of the change. These subject processes are not the subject in this thesis research.

1.4.4 Sub question 3: components

“What are the possible components of an adequate business case for ICT projects?”

The Elias committee recommends to provide for a business case comprising all key components in order to make a sound decision. However, though the Elias committee mentions some components at distinct places in its report, it does not provide an exhausted list of these components. Some of the components are listed as recommendation, for instance the study for organizational, governmental and technical feasibility (Elias committee, 2014a, p. 10). At other places the report either explicitly or implicitly mentions some possible components. But again, there is not a complete list in this report.

1.4.5 Elucidation

The research questions are connected. Though I didn’t find a reference for it, I suppose that within the theory of requirements analysis the following principle is true or at least it is generally accepted:

An information system at least contains the data to compose the required information that its users and / or using processes need or expect.

If for instance, the purpose is to decide upon a specific project budget, the anticipated budget needs to be a component. Or, if the business case is used to evaluate a business change, the evaluation process itself dictates the availability of certain detailed data in the business case. Generally stated: a specific purpose

(8)

could require the presence of a specific set of components with the specific level of detail. Processes which create, use or change a business case might be dependent on the presence or quality of certain components.

Figure 1 The relation between the sub questions

1.4.6 Expectations

Since this thesis is meant as exploratory, none of these questions will be answered exhaustively. Neither do I expect to discover breaking views. I will highlight some aspects of business cases which might have been neglected in some situations, some aspects which may be superfluous in certain situations, and some aspects which may also have been applied unconsciously already in business cases.

There is also a limitation. Though business cases are often associated with ICT, this is not the only line of business that uses business cases. Many aspects of business cases I expect to find might be valid or plausible for business changes that have no relation with ICT (or only a very limited relation). However, since my profession has been in the ICT branch and my research has focused on ICT projects, my statements cannot go beyond this branch.

1.5 This thesis

After this introduction, Chapter 2 Methodology deals with the methodology to approach the research question. Next, Chapter 3 Literature: state of the art provides the state of the art in both academic literature and the general project management literature; this chapter concludes with a conceptual model. The results of the interviews will be discussed in Chapter 4 Interview results. Chapter 5 Reflection discusses the method used and the lessons learned about it. The thesis concludes with Chapter 6 Conclusions & recommendations. After the References a few appendices are included (Appendix A Code scheme and Appendix B Index). There is a

Business case

Purposes Processes

Components

Purposes Processes

(9)

separate appendix, not available to the general public, containing the transcripts of the interviews, the identification of the interviewees and the characterization of their organizations.

(10)

2 Methodology

As stated in the introduction this is an exploratory research. I expect that the research questions will be answered sufficiently, but not exhaustively. This chapter deals with the research methodology, starting with an overview.

2.1 Introduction

For this thesis research a grounded theory approach was used. I started this thesis with the research question loosely formulated: “What are the relevant aspects of a business case?” Also the sub questions were not yet formulated.

In order to formulate the research question and sub questions I performed a literature study of both the scientific and the applied sciences literature. I also conducted an open qualitative interview with a chief information officer and one with a program manager. The literature study combined with these interviews helped me to reformulate the research question and to formulate the three sub questions. The conceptual model, mainly developed on the basis of the literature study, was extended after the preliminary interviews by adding the concept of stakeholder.

As a part of the research, interviews were conducted with 8 more persons. Together, these 10 respondents belong to 2 distinct categories. The first category consists of 7 executive representatives, involved with developing or reviewing business cases or taking decisions based on business cases. The purpose of these interviews was to get a deeper insight into the current practices around business cases. The second category consists of 3 ICT consultants and teachers, who have practical experience in the ICT profession as well as ample experience with teaching a variety of skills to other ICT professionals.

Figure 2 Overview of the research

After the first 5 interviews with executive professionals were conducted, Prof. T.M. van Engers, my mentor for this study, strongly recommended me to develop a grounded theory coding scheme based on the literature

Interview results Conceptual model

Literature study Interviews with executives Interviews with consultants

Coding scheme Subject

(11)

study and these 5 interviews. We both hoped this would provide a more solid base for conclusions. The rest of the interviews (with both executive and consulting professionals) was conducted based on the unaltered interview scheme, but with the code scheme in mind. However, this approach turned out to be too time-consuming and required too much effort to be continued. I decided not to pursue this approach any longer. To report the interview results I used the properties of the constructed conceptual model to detect identify

quantitative and qualitative results.

The literature study and the interview results led to the conclusions and the recommendations for further research. Chapter 5 Reflection is dedicated to some reflection about the used research method and contains an advice for the application of grounded theory for master theses.

2.2 Grounded theory

To execute a research project several methodologies are available. In case the research problem is more or less clear from the start of the research, the research method in general consists of a literature study, resulting in one or more tightly formulated research questions, followed by a qualitative or quantitative

research project to answer these research questions. If the research problem is not clear and the literature on the subject studied is poor, a grounded theory approach can be appropriate. This methodology was

developed by Barney G. Glaser and Anselm L. Strauss in the 1960s. Charmaz describes grounded theory as ‘a set of principles and practices, not as prescriptions or packages’ (Charmaz, 2006, p. 9) to apply to the researcher’s judgement of the situation. Charmaz advises that a typical project starts with data collection after a brief review of the research problem. Data, in the perspective of grounded theory, can be almost anything that can be analyzed in order to construct a theory covering the field of research. Examples are interview transcripts, gathered notes from observations or WhatsApp texts. Charmaz states: “… elicited texts work best when participants have a stake in the addressed topics, experience in the relevant areas, and view the questions as significant.” (Charmaz, 2006, p. 37). She describes a range of bottom-up methods (‘coding’) to analyze these texts and to construct theory, answer questions and draw conclusions. Grounded theory

provides the possibilities to discover new emerging theories while not deliberately searching for a specific one. Moreover, it provides the possibilities to add new lemmas, while the research is ongoing.

Classical grounded theory recommends to analyze the data before performing a literature review. Literature study leads to what Glaser & Straus call ‘preconceived’ ideas: imposed to the researcher by the literature or the researcher’s teachers. Charmaz writes: “The intended purpose of delaying the literature review is to avoid importing preconceived ideas and imposing them om your work. Delaying the review encourages you to articulate your ideas “(italics in original) (Charmaz, 2006, p. 165). However, she also reports that it is practically impossible to avoid literature in an early stage of the research. She concludes with the advice: “Consider treating extant concepts as problematic and then look for the extent to which their characteristics are lived and understood, not as given in textbooks.” (Charmaz, 2006, p. 166)

Though the availability of literature in the ICT field concerning business cases is sufficient, it is also not overwhelming. But more important is that, according to Levy & Ellis, its quality is debatable. Descriptions and

(12)

discussions “often appear in non-refereed work or in questionable sources. The problem is exacerbated by the presence of corporate sponsorship and its impact on research findings” (Levy & Ellis, 2006, p. 5).

Before deciding to follow a grounded theory approach, I already studied a part of the literature. This did not provide me with satisfying research questions, nor with a clear conceptual model. Together with the aforementioned considerations about the available literature I decided to conduct the research using a grounded theory approach. I used the first interviews and the literature study to construct the research questions and to complete the conceptual model.

2.3 Literature study

2.3.1 Literature selection

The literature used for this thesis can be divided into three categories: scientific literature (books and

published articles), applied practices literature (e.g., project management literature) and the publications of the Elias committee.

The scientific literature was primarily found by using the library search mechanisms of the University of Amsterdam, the Free University of Amsterdam and the Erasmus University Rotterdam. Additional scientific references found in Google Scholar were used. A first set of articles was found using keywords as ‘Business Case’, ‘Business change’, ‘project(s) justification’, ‘portfolio selection’. This set of articles and books was expanded by recurrently searching for:

1. other articles or books by the same author(s), preferably more recent, 2. articles or books mentioned in their references sections,

3. articles in proceedings or edited volumes in which earlier found articles had been published,

4. articles which used any previously found article as a reference (for this search Google Scholar was used), 5. articles suggested by the publisher of an already downloaded article (e.g., Elsevier provides this service),

and

6. new keywords found in articles (e.g., ‘stakeholder’, ‘ICT investment decision’).

While conducting the interviews and setting up the code scheme new literature was found using: 7. new keywords while reflecting on the code scheme (e.g., ‘urgency’),

8. articles or books suggested by one of the interview respondents (only the book of Kepner & Tregoe was used for this thesis), and

9. new keywords mentioned by interview respondents (e.g., ‘solution alternatives’, ‘organizational dimensions’).

Applied sciences literature was found via direct or indirect references of the Elias committee, suggestions by former colleagues, or the interview respondents. With the project management methods (Sub section 3.2.2 Project management processes) I was already familiar during my professional career; books or articles on these methods are not hard to find.

(13)

2.3.2 Literature validity

Though the Elias committee investigated the ICT projects in Dutch governmental organizations, the scientific literature deals with business cases for general business changes and is not specific to either governmental organizations or Dutch organizations.Literature was explicitly chosen both for ICT-related literature and non-ICT related. See however the remarks on validity in Chapter 5 Reflection.

2.4 Preliminary interviews

I conducted an open qualitative interview with a chief information officer (A) and one with a program manager (B). With one of them (A) I conducted, on his indication, a follow-up interview, which also took about 45 minutes. The literature study combined with these three preliminary interviews (total recorded time 164 minutes) helped me to reformulate the research question and to formulate the three sub questions. The conceptual model, mainly developed on the literature study, was extended on the interview results by adding the concept of stakeholder. I refrained from adding a fourth sub question (“What are the possible stakeholders related to an adequate business case for ICT projects?”), which would have fit in the pattern, but which would also have enlarged this thesis research. The interview scheme was set before the third interview.

2.5 Conceptual model

After the literature study and the first explorative interviews, a conceptual model was developed. The model will be elaborated upon in section 3.5 Conceptual model.

2.6 Qualitative research

2.6.1 Introduction to the interviews

On the basis of a preliminary literature study a provisional conceptual model of the business case could be developed. However, this provisional theoretical model needed to be questioned, enriched and refined. To investigate whether this theoretical image corresponds with the business case in every day practice of business engineering, I have also performed field research.

Since this thesis is an exploratory one, the qualitative research was performed with a broad perspective in mind. Details of discovered aspects as well as statistics (e.g., usage frequency) are at this point considered of lesser importance than the possible argumentations I could discover. For instance, the argument why a specific component would be important and in which situations was considered of a higher importance than the usage percentage of that component.

Remembering the statements of Charmaz about the best interview data, it was decided to conduct qualitative, semi-structured interviews with professionals dealing on a regular basis with business cases.

2.6.2 Qualitative interviews

Based on this conceptual model I conducted individual qualitative interviews with 10 professionals (identified by letters A to J.), including the two professionals who agreed on the preliminary interviews. I aimed to interview ICT professionals from a broad range of organizations in the governmental, financial and industrial sectors.

(14)

These interviews were held within two distinct groups: one group consists of executive professionals (A, B, C, E, G, H, J) and the other group consists of consulting and teaching professionals (D, F, I). The executive professionals are employed by the organization where they perform their work. They deal on a regular basis with business cases in their respective organizations, in a decision relation, a collaboration relation or both. The consulting professionals are or were employed by a consulting firm and are or were hired over time by other organizations for their specific skills. This group of persons experienced the business case from a consulting role in several organizations. Moreover, in their role as teacher and trainer, they were not only expected to possess specific experience and knowledge, but also to know the rationales involved and the capability to convey these.

The choice to interview professionals from these distinct groups was made to introduce triangulation into this research. Triangulation creates more certainty about the conclusions of this thesis report. I had in mind that the executive professionals could struggle with everyday reality and might not be fully aware of theoretical aspects, while the consulting teachers could tend to operate from their theoretical frame, while neglecting (whether purposely or unconsciously) the everyday struggle of executive professionals. The reporting of the results in Chapter 4 Interview results will be done by reporting both groups of respondents separately. Especially in exploratory research this is useful, as it creates a broad perspective, thus increasing the possibility of acquiring new insights.

The interview data appendix, which is not available to the general public, comprises the identification of the respondents as well as some characteristics of their organizations.

2.6.3 Respondent selection and representativeness

Executive respondents

In order to acquire a broad perspective on the business case phenomenon, I tried to interview respondents from a broad range of organizations in the governmental, financial and industrial sectors. Establishing contact through my personal network (family, neighbors, friends, teachers and former colleagues) I found 7 managers who agreed to an interview. These 7 executive respondents are working as a CIO, portfolio manager or product manager; one of the CIOs is female, the others are male. None of these persons were known to me before.

The average recorded time of the interviews is 42 minutes. One of the interviews was conducted in English since the CIO of the international company was a British citizen; the others were conducted in Dutch. All interviews were conducted at the respondent’s workplace (one of them in an open workspace, the six others in a closed office or meeting room). Three of the respondents demanded that the record of the interview would never become public. I explained that these were only meant for my mentor, prof. T.M. van Engers and the assessors of this thesis and I agreed on destruction of one of the recordings. In exchange the respondents felt free to express their opinion and to illustrate their opinion with their experiences from current or previous jobs.

Consulting respondents

In addition I asked 3 former colleagues also to express their views on the business case. This second group comprises 3 ICT consultants who also have a long time experience as teacher/trainer. This group of persons experienced the business case from a consulting role in several organizations. Moreover, in their role as

(15)

teacher and trainer, they were not only expected to possess specific experience and knowledge, but also to know the rationales involved and the capability to convey these. The main reason I interviewed them is that they used to teach courses in business problem analysis, solution design, business change management, and ICT analysis and design; all these courses comprise elements of business cases. I consider these consultants representative with respect to all the courses that deal with (parts of) business cases. The consulting

respondents, all male, currently or formerly employed by the Dutch part of Capgemini (an international consulting firm) have a longstanding career in both consulting roles within multiple organizations and teaching in a range of ICT courses at the Capgemini Academy.

The average recorded time of the interviews is 53 minutes. All three interviews were conducted in a private house setting.

Representativeness

As only a small research sample is constructed for this thesis, the outcome of this thesis cannot be representative for the whole range of situations where ICT business cases apply or could apply. Time available limited the number of conducted interviews to 10. Also it turned out that none of the respondents was employed within the industrial sector. The reactions of the respondents however, can be indicative of potential issues in the field of study of ICT business cases in general.

2.6.4 Interview scheme

At the start of each interview I emphasized that I was primarily interested in the respondent’s views and only secondary in their organization’s policies and practices. I interviewed the respondents by asking open and more closed questions about the aspects of the business case. The aspects are listed in the general interview pattern below, but the exact order and formulation varies by interview. Within the limited time of 45 min, some aspects were discussed with every respondent (the purpose of the business case), but most aspects were only discussed with a few respondents.

General pattern of the interview

1. Introduction 1.1. the interviewer 1.2. the respondent 1.3. the organization

1.4. some ICT related aspects: 1.4.1. portfolio management

1.4.2. project management method(s) 1.4.3. make/buy strategy

2. General aspects:

2.1. What is or should be the objective of a business case? 2.2. What is or should be the use of a business case?

2.3. Who are or should be the parties involved and in which role? 3. What are or should be the processes interacting with the business case? 4. What are or should be the components of the business cases?

(16)

5. Are there any other issues or remarks related to the business case not mentioned so far? Please elaborate.

2.6.5 Grounded theory coding scheme

In order to create a solid base for the rest of the research, I started to develop a grounded theory coding scheme after the first 5 interviews, based on the literature study and these interviews. The rest of the

interviews (with both executive and consulting professionals) was conducted based on the unaltered interview scheme, but with the code scheme at hand in mind. However, this approach turned out to be too

time-consuming and required too much effort to be continued. More importantly, as this thesis is an exploratory research coding didn’t add much value to this thesis; there is no need to quantify the data found. And, though the scientific literature could be supplemented, the combination of scientific and applied sciences literature suffices to form a conceptual model for this thesis. I decided not to pursue this approach any longer. The coding scheme I initiated is added as Appendix A Code scheme to this thesis report.

2.6.6 Reporting the interview results

A consequence of the semi-structured character of the interview is the difficulty of reporting certain aspects. Though I tried to quantify the things the respondents said, much depends on my own interpretation. Moreover, my interpretation has been colored by my own 30 years of working in the field. To reduce the risk of

subjectivity in the interpretation I only reported findings if certain concepts were explicitly mentioned by the respondents, though the respondents may have used different words. These word-associations are listed in Table 1 in Section 4.1 Reporting the interview results.

In order to get a balanced contribution of all respondents, I decided to use only the second interview conducted with respondent A (and I refrained from the first one) to report the interview results.

(17)

3 Literature: state of the art

In this section the state of the art concerning business cases will be discussed, as found in both scientific literature and in project management handbooks. Next to ICT related articles, this section will also refer to some literature on business cases in the health care, the green energy and the logistics branches.

This chapter discusses:

1. Purposes of a business case

2. Processes related to a business case 3. Components of a business case 4. Stakeholders

5. Conceptual model

3.1 Purposes

In the literature a wide variety of purposes for a business case can be found. This subsection deals with three objectives on which most authors agree. The business case is primarily a justification for a business change. Additional objectives are the evaluation of the implementation process and the guidance of the program or project which realizes this change1.

3.1.1 Justification

The primary purpose of a business case is the recommendation or justification of an intended business change to meet a specific business objective or goal. For ICT business cases this implies the justification for intended changes to the ICT aspects and related processes of an organization. The justification is needed to make a decision about realizing the changes and about their funding.

Various authors provide similar descriptions. According to Eckartz et al. (2010), who studied business cases for Enterprise Systems (ES) as software packages, a business case enables the decision-maker “to estimate the expected costs and benefits of an ES for the adopting organization” (Eckartz et al., 2010, p. 2). The Treasury Board of Canada, which developed a range of guidelines for business and ICT, defines a business case as “a presentation or a proposal to an authority by an organization seeking funding, approval, or both for an activity, initiative, or project” (Treasury Board of Canada, 2015a, p. 13). To Nielsen & Persson a business case is an “artifact in the form of a document specifying the main rationale behind the expected value and cost of an IT investment for the adopting organization” (Nielsen & Persson, 2012, p. 2). Remenyi & Sherwood-Smith state: “A business case is a justification for pursuing a course of action in an organizational context to meet stated organizational objectives or goals.” (Remenyi & Sherwood-Smith, 2012, par. 1.5). Gambles, a British governmental official, writes: “A business case is a recommendation to decision makers to take a particular course of action for the organisation, supported by an analysis of its benefits, costs and risks

1_{Business changes can be realized by a project, a set of interrelated projects, or a program. In order to abstract from these terminology, I}

prefer the more neutral term process. The majority of the authors use the term project; some of them note that their statements hold for programs as well.

(18)

compared to the realistic alternatives, with an explanation of how it can best be implemented.” (Gambles, 2009, p. 1).

3.1.2 Evaluation

A secondary purpose of the business case, as presented in various articles, is its evaluation. Generally, but not always, authors distinguish between the final evaluation and evaluations during the implementation process. In the latter variant it is possible to adapt the business case, the implementation process, or both. In the final evaluation other aspects may be evaluated. For instance, according to Ward et al. a business case should also enable the responsible persons to judge objectively the success of the investment. Moreover, they state that the business case should be reviewed at certain moments during the implementation process. Robinson & Dechant state that tracking mechanisms for assessing progress and financial impact should be incorporated. Shirey wants a foundation for “managerial control and accountability” (Shirey, 2011, p. 1) to be created. Hence, a business case should enable the organization to evaluate the business changes at certain moments, but certainly at the end of the implementation process. The next section will elaborate on these two forms of evaluation.

3.1.3 Implementation process framework

Next to the primary and secondary purposes of a business case, the justification and evaluation, many authors add other objectives to the concept. The most prominent of these is the inclusion of an

implementation process framework, a first high level plan for the implementation, sometimes presented with alternative implementation options. It can be argued that these components serve another purpose, or another aspect of the justification purpose: to establish or strengthen the confidence that the intended business change is achievable.

For instance, Gambles adds “an explanation of how it can best be implemented” (Gambles, 2009, p. 1) as a component of the business case, which should guide the implementation, or at least the start of it.

According to Robinson & Dechant, identifying what is required to achieve the objectives, means deciding about the nature and magnitude of the implementation process. Shirey incorporates a search for the viable options (including costs and benefits) as part of the creation process of a business case. This is to be followed by choosing the best option and creating an implementation plan. (Alternatives will be discussed in section 3.3 Components.)

3.1.4 Reflection upon business cases purposes

Reviewing the literature referred to above, some things need to be noted.

One Some authors define a business case as a ‘document’ or ‘presentation’ (or more generally ‘an artifact’) with certain objectives. When looking at the business case from the ontological and teleological

perspectives and thus abstracting from its physical form, it is clear that the business case as an argument or a mechanism is the prevailing concept. Documents or presentations (and even screen projections or verbal utterances) are only representations of the real business case. Moreover, it can be argued that a justification can exist in the mind of a person or in discussion between two or more persons without ever being noted down in any physical form.

Two The primary business case purpose, as can be concluded from the above mentioned references, is the recommendation and/or justification of an intended business change. However, this justification is not

(19)

only or not always a one-off justification prior to the intended business change. Since most authors recommend evaluating and, if necessary, adapting the business case during and after the implementation process, the business case itself must have a continual character lasting a longer period. Additionally, it seems reasonable to limit the term ‘recommendation’ to the ex-ante business case.

Three The implementation process of the business change will start (or continue) after an ex-ante justification (and a positive decision). This implies that a business case without an implementation component could exist; at least in an early stage in the creation process. This is also the case if the business case is rejected by the decision makers or in case the business case recommends to do nothing at all. However, part of the justification will be the financial component (for almost all organizations) or any other kind of investment needed. The only way to estimate the investment needed is to analyze the activities needed for realizing the intended business change. This implies that at least a high level plan of the business change must be incorporated.

Four The concept ‘justification’ seems clear at first sight; on closer look however, it could be related to at least two other notions: approval and funding. The Treasury Board of Canada mentions “… funding, approval, or both…” (Treasury Board of Canada, 2015a, p. 13).

Five There is a difference between the final evaluation of the business case and the intermediate evaluation. In the latter case the business case can be changed due to progressive insights. At the final evaluation after the implementation of the business change the organization this doesn’t make much sense anymore; the organization could consider to start a new business case for the new perceived business problem. In the remainder of this thesis this distinction will be continued.

Six The justification needs to be addressed to one or more persons. Who these persons are remains, at least in the aforementioned definition unclear. Most authors mention “the decision makers” or “an authority”. It can be argued that “a decision maker” does not always suffice. Apart from making the decision, the decision maker itself may need the business case to prove– or at least make it plausible – towards a higher authority that the decision was made correctly and conscientiously.

Seven There are more purposes, or at least ways of usage, that can be attributed to a business case. For instance, a business case should also deliver the information upon which the portfolio process can assign priorities to the whole set of programs and projects.Mostly it concerns purposes of lesser importance, which are not explicitly stated by literature, but rather implicitly. A thorough study of the purpose and use of a business case would take more time than was intended for this thesis.

3.2 Processes

Answering to sub question 2 and in preparation of answering sub question 3, the processes that create, need, use or otherwise are related to a business case during its lifetime must be studied. In the end, the

components of a business case need to support the purposes as well as the (stages in the) processes related to a business case during its life cycle. As many authors state, there is no standard business case, and there is no clear recipe for constructing a business case. However it is still possible to discuss the possible

(20)

Figure 3 illustrates the relations between the portfolio management processes, the business case processes and the project management processes. The portfolio management processes, which deal with multiple business cases, depend on information from these business cases. Hence, these portfolio management processes dictate at least some of the information that must be available in a business case. As a

consequence, the actual process of creating a business case depends on the organization’s policy on portfolio management.

Since the business case is supposed to set the goal, scope etc. for the project, it seems reasonable to suppose that the business case will be approved before the implementation project starts or ultimately before the end of the first phase of the project.

This section starts with a brief elaboration of the portfolio processes, related to the business case. Project management methods will be discussed briefly in the next subsection. After that the processes for creation, maintenance and final evaluation of the business case will be elaborated.

Figure 3 Interaction between portfolio management, business case and project management processes

3.2.1 Portfolio management

The literature on portfolio management indicates that within a portfolio priorities must be established. Whichever the criteria for a balanced portfolio might be, all data answering to these criteria for accepting the project, prioritizing the project, and allocating finance or other resources to the project, should be found in the business case. Ward et al., for instance, state that a business case enables these priorities for funds and resources.

Once the project has started, the portfolio management processes at certain points in time need at least the actual expenditures concerning finance and resources, but probably also the project’s forecast. On the other hand, if in that stage the portfolio management reallocates finance or other resources, the implementation process must be adapted, which could result in a change of the project or even a change in the business case.

3.2.2 Project management processes

Textbooks on ICT project management emphasize the need to update, or at least check, the business case at various moments during the project. Depending on the method the obvious moments for intermediate

evaluations are the ending of a project phase, especially the earlier phases. Usually the final evaluation takes place at the end of the project.

Portfolio management

Business case

(21)

In this subsection we discuss briefly four project management methodologies. 1. Prince2, a general project management method, is not necessarily ICT-related.

2. Linear ICT development methods are characterized by a phase-to-phase structure and by delivering the software near the end of the project; as an example we discuss shortly the SDM (System Development Methodology).

3. Iterative ICT methods are characterized by their adaptable character and by delivering software piece by piece at several moments in time. We discuss as an example briefly the RUP (Rational Unified Process). 4. Agile ICT methods are characterized by their frequent delivery of software produced by multidisciplinary

teams; Scrum is one of these, generally used for relatively short projects.

Many organizations claim to use one of these methods, or a combination of them. Since every method has been developed to manage a broad variety of situations, the complete method is too much for every

organization. Organizations usually – either purposely or unconsciously - fit their chosen methodology to their situation, something that all these methodologies themselves strongly advise.

Prince2

The project management method ‘Prince2’ (acronym for “projects in controlled environments”) has been developed and maintained by the British Office of Government Commerce (OCG). The method recommends updating the business case at key points in the project.

Prince2 identifies four distinct stages of a project:

1. the pre-project stage, in which the idea of the project will be elaborated until a project can be initiated, 2. the project start-up stage, in which the project will be structured and its goals will be set,

3. the execution stage, usually consisting of repeated delivering stages, and finally,

4. the project close stage, which includes activities around the ending of the project and the handing over of the deliveries to the organization.

Turley, an introduction handbook for Prince2, notes that the business case, or at least, the first outline, can be created at the very first idea of a project. At that stage the business case should describe the reasons for the project and more specifically, that it “addresses value for the business, company objectives, and funding & risk information” (Turley, 2010, p. 17). At the end of the 2nd

stage the business case should be complete; it should provide time and cost information.

Turley recommends updating the business case at the end of each stage and to “check if the project is still viable and worth doing” (Turley, 2010, p. 26). The project board must be informed whether the project will realize its goals within the agreed time, cost, quality, risk and scope. Additionally he remarks: “During the project lifetime, whenever a risk appears, the odds should be weighed against the Business Case to check if the benefits still exist within the expected time and cost constraints.” (Turley, 2010, p. 26).

System Development Methodology, a waterfall methodology

One of the first ICT specific development methodologies in the Netherlands was SDM. It was developed by a combination of three large Dutch organizations in the early 1970s. In later years it was adopted by Capgemini, which propagated and adapted the method until the late 1990s. Originally it was developed for making

(22)

SDM is a waterfall method, which means that usually the phases will be successively executed; the phases and their main activities are:

1. Information planning: Problem definition and initial plan 2. Definition study: Requirements analysis and revised plan 3. Basic Design: High level technical design and revised plan 4. Detailed Design: Building the system (and revised plan) 5. Realization: Testing and acceptance (and revised plan)

6. Implementation: Installation, data conversion, and cut-over to production 7. Operation and Support: Delivery to ICT support department

After completion of each phase, it will be decided whether to go on to the next phase or not (the “GO-NOGO” decision) and to adapt some of the projects objectives: finance, scope, limitations, etc. The next phase will not start until a 'Go' is given, while if there is a 'NO-GO', the project either stays in the current phase to be

improved or is canceled completely. Though Turner et al.(1990) did not mention the business case (the term business case became widespread at the same time the method became gradually obsolete), it is clear that important changes should be agreed upon between the project management and the decision makers.

Rational Unified Process, an iterative project management methodology

The Rational Unified Process (RUP), an IBM iterative ICT-project management method, recognizes four project phases:

1. Inception phase, where concurrence between the stakeholders about the project will be achieved (on project scope, function, costs, schedule, risks, etc.)

2. Elaboration phase, where the baseline on system architecture is set and agreement on the requirements will be achieved

3. Construction phase, where the main development of the system will be done

4. Transition phase, where the transition to the user environment – including user tests – will be done. The latter three phases can be split up in two or more iterations (ideally lasting 2 to 5 weeks) that will deliver pre-defined products: (milestone) documents, prototypes or executables.

Shuja & Krebs (2007) is an introductory guide to the RUP. They note that a business case includes a set of assumptions (as a basis for the investment decision). At least at the end of the elaboration phase when the scope and plan are defined with more accuracy the project manager checks these assumptions again.

Scrum, an agile project management methodology

Scrum is characterized by the multidisciplinary teams which work together in frequently delivering (weekly or even daily) new pieces of software. Important is the ‘backlog’: a list of functional and technical wishes and requirements for the software. It is the responsibility of the ‘product owner’ (both a business representative and a team member) to maintain this list. Hence, the product owner is responsible for the alignment of the business case and the implementation project.

(23)

3.2.3 Business case processes

This subsection discusses some aspects of the processes for creating, maintaining and evaluating the business case.

Inducement

One of the interesting aspects are the circumstances a business case should be started. Most authors do not specify this. In most situations the occasion to start a business case is rather clear: the moment a business problem or a business opportunity appears. However, Kepner & Tregoe also advise starting a potential problem analysis (or potential opportunity analysis) “whenever experience and intuition tells us” (Kepner & Tregoe, 2006, p. 159), to investigate possible future unwanted situations.

Creation process

Many authors describe the necessity of a business case, or its components, restrictions etc. Only a few deal with the actual creation process of a business case. On closer reading many authors highlight aspects or reflect on components of business cases while implicitly indicating possibilities to create a business case in stages. Pedersen for instance stated:

When deciding which problems to solve the major issues are the importance of the problems and the stakeholders that personally experience the problems, the level of risk that characterizes the solution and how the related risks can be reduced, and the timeframe within which the solution can be provided. (Pedersen, 2012, p. 68)

This implies the possibility to determine the importance of the business problem first (and maybe other characteristics of it) and then finding a solution with all its costs, benefits, implications, limitations etc. Hence this creation could comprise 2 or more stages.

Figure 4 Three phases in the creation of a business case according to the Treasury Board of Canada

Within the literature, the Treasury Board of Canada is the most explicit about the creation process of a business case. The idea is to develop a business case in three phases (see Figure 4). Phase 1 (Strategic context) deals with the need for a business change. Only if this first phase has been concluded, the possible solutions are identified and analyzed and a preferred option will be chosen in phase 2 (Analysis &

recommendation). The third and last phase (Management & capacity) concerns the prospected management of the change and the evaluation of project and business case both afterwards and while the project is executed. Kepner & Tregoe describe a systematic process for finding a solution; They describe a cause-and-effect analysis, which starts with a structured problem definition and which produces one or more possible solution alternatives. The next step is a decision analysis, which leads to a decision. A major part of the decision analysis is “the search for possible adverse consequences of all feasible alternatives” (Kepner & Tregoe, 2006, p. 84).

Strategic context Analysis & recommendation

Management & capacity

(24)

Maintenance

Many scientific authors indicate that once a business case has been created, it should be maintained. Eckartz et al. (2009) , for instance: “This implies that a BC should be reviewed at the various stages during the IT lifecycle.” (Eckartz et al. 2009, 1). However, hardly any scientific article is concerned with the actual change process in the course of a project. As discussed in the previous subsection, textbooks on ICT project

management emphasize the need to evaluate and if necessary update the business case at various moments during the project, usually at the end of a project phase.

Final evaluation

All project management methods mentioned recommend evaluating the project and the business case at the end of the project. Most project methodologies mention these evaluations very briefly or indirectly. Turley on the other hand is very explicit. At the end the project must be evaluated: “Confirm that the project has met the Business Case by comparing the current Business Case to the original one, comparing the Benefits, Cost, Risks, and Return on Investment.” (Turley, 2010, p. 26). All lessons learned should be written down in a ‘Lesson Report’ which must be available for future use.

3.2.4 Reflection upon the business case processes

Some remarks on the literature about the business case related processes can be made:

One Since the creation of a business case costs time, resources and money, following the protocol of the Treasury Board of Canada could be a rational decision. If in phase 1 the need for a specific business change appears to be low (expressed in financial or non-financial terms) or other business changes seem to have higher priorities the further development of a business case (and the implementation project) would be postponed or discommended.

Two For the same reason it might be considered to skip making a business case for small changes. Three Though often a business case is perceived as a one-time justification in order to acquire the funding

of a business change, it would make sense to perceive the business case as a continual justification. This view is supported by the project management methods. It could be argued that the business case

definition should be changed: “a business case is a continual justification of a business change”.

Four The final evaluation at the end of a project, among others propagated by Turley, is a suitable measure to raise the learning curve of the organization and thus to perform better on future projects.

Five Authors differ in opinion about the topics of the evaluation; some of them seem not to be aware that distinct evaluation topics exist. Possible evaluation topics could be the implementation process, the business change, the product(s) delivered by the implementation process and the business case itself. For all topics literature references can be found.

Six The creation of a business case could show that a suggested business change would be unwise. In that case, there will not be a project for the realization. It would be a good practice to add that business case to the lessons learned of the organization.

(25)

3.3 Components

In the literature there is a general consensus about the primary objective of a business case: the justification of a business change. There is also a general agreement on the financial benefits and costs as components of the business case. Additionally, Eckartz et al., for instance, state:

“A BC however, should contain more than just a financial analysis of an action to take. The (non-)financial benefits, alignment, costs and risks, should be complemented with information on the methods and rationale that were used to quantify the benefits and costs.” (Eckartz et al., 2010, p. 4).

This subsection deals with the components of a business case, which support the identified purposes and the related processes as discussed in the previous two subsections. All components are intertwined, for instance, most components add to the benefits and costs. Some components may not be recognized as individual, substantive elements but some information on them might be expected. For instance the relation of a business case to the business objectives may be part of the business problem, its solution (and alternatives) and the subject of the business change, but not perceived as a component in its own right. Other candidate components could be the problem statement (the nature and characteristics of the business problem), the subject process or the scope.

The following items will be discussed 1. Rationales

2. Solution & alternatives 3. Business objectives 4. Consequences 5. Benefits & costs 6. Risks & measures

7. Implementation process framework 3.3.1 Rationales

Unlike most of the literature, the Treasury Board of Canada makes a clear distinction between the rationale to want a change and the rationale for a specific solution. The board bases the phased creation of a business case on this distinction.

Concerning the change rationale, Kepner & Tregoe recommend to analyze the situation and to make an exact problem statement including its dimensions: seriousness (how large is the gap between current situation and the situation pursued?), growth (how is the gap developing in time?) and urgency (what are the moments in time that the problems change radically? What is the ultimate solution date?). A problem in this context means a business problem (there are some issues concerning effectiveness or efficiency of the current situation that are unwanted for, for instance a client registration process that takes too long) or a business opportunity (the

(26)

current situation is not unsettling, but there are possibilities to create a better one, for instance the development of a new product or consumer market).2

The second rationale describes the solution to the problem or opportunity at hand and the reason why this solution will solve the business problem. If, for instance, the business problem appears to be time-bound, the solution must also cover these time limits.

For Kepner & Tregoe, the aforementioned problem statement forms the start of their problem analysis and decision analysis (as described in subsection 3.2.3 Creation process). These steps together result in both the solution and its rationale.

Reviewing the literature with the existence of these two distinct rationales in mind, it turns out that some authors clearly state they expect the rationale for a specific solution, whereas others are less specific or might not even be aware of this distinction. Both kinds of rationale depend strongly on other elements of the

business case.

3.3.2 Solution & alternatives

The inclusion of at least a short description of the (proposed) solution is obvious; among others the benefits, costs, risks or consequences are based on this. Kepner & Tregoe describe a systematic process for finding a solution and alternatives (see subsection 3.2.3 Creation process). No other literature on the solution discovery process or on the description of the solution itself has been found.

Other authors mention the option to present alternatives to the proposed solution, including their benefits, costs and risks. It is arguable both to include and to exclude alternative solutions in the business case; this depends on the phase in the business case life-cycle and depending on the organization’s policies regarding alternatives.

The Treasury Board of Canada, for instance, explicitly states that in order to make an objective and transparent decision a business case must be used to “identify and explore options” (Treasury Board of Canada, 2015a, p. 13). Eckartz et al. (2010) states that a business case should present several

implementation options, including their costs, benefits and risks. One of these variants will be the actually proposed change. This directs the objective and the scope of the implementation process. Moreover, by presenting these alternatives, the business case provides the decision maker the opportunity to deviate from the proposed business solution and choose another alternative.

3.3.3 Business objectives

As stated earlier, some components may not be recognized as individual, substantive elements. This is certainly the case for the relation between a business case and one or more business objectives. The business objectives can be part of the stated business problem, its solution (or alternatives) or the subject processes of the business change. For instance, Kepner & Tregoe use an explicit problem statement and specification in their method; the problem statement implicitly refers to the business objectives.

(27)

Reiter et al., who describe the business case steps for quality-enhancing interventions in health care, note that for a business case only the perspective of the investing organization should be considered. Investments, for instance, for developing and implementing the intended changes as well as decreases in costs or

increases in revenues caused by the changes, should be considered from the organization’s perspective. This also holds for cooperating organizations. Eckartz et al. (2009), who wrote about cross-organizational ERP implementations, stress that the costs and revenues must be attributed to the business objectives. To do this Eckartz recommends using balanced score cards dimensions. (Balanced score card is a mechanism for evaluating the strategy performance of an organization; in its original form it is based on measurements on four factors or dimensions: financial results, customer satisfaction, internal efficiency and learning

capabilities.)

In Eckartz et al. (2010), about the inter-organizational business case developing (BCD), the business objective and scope is an explicit part of their research question. We cite:

An important aspect of BCD in inter-organizational settings is its linkage to the model that describes how the business network creates value for its clients and how the network distributes the value among the partner companies. This model (…) serves two different, but related purposes: (i) it helps each partner company do a profitability assessment for themselves based on the information provided in the partner company’s individual BC, and (ii) it helps assess if the entire network of cooperating organizations is profitable. If the network partners want to e.g. implement a shared ES, which is used by all partners, they need to make a shared investment decision, based on a joint BC for the entire network.” (Eckartz et al., 2010, p. 4).

This means that somehow a business case should refer to the objectives of the organization.

Ward et al. argue that a business case should show both business changes and ICT changes. He elaborates on the benefits (and costs) aspects, by developing a classification and some methods to quantify each type of benefit. Furthermore, he also classifies the benefits in relation to the organization’s products and services: develop new products or services, improve the current ones, or end them.

Eckartz et al. (2009) state that the business case not only serves to secure the funding, but secondary to that, the business case should serve as a basis for the ICT realization. The reason for this is that the funding decision maker should verify that the awarded funding not only is connected with the specified business objectives, but also that it remains connected with the business objectives. Hence the business case should at least refer to one or more business objectives.

3.3.4 Consequences

In order to be able to decide between a proposed solution and its alternatives, the consequences of each of those should be identified. A list of consequences provides the organization also with the option to

compensate or avoid the negative consequences together with implementation of the business change. These compensatory actions contribute to the costs of the implementation process. Negative consequences may occur in the form of risks or tasks (and costs). Positive consequences, on the other hand, may be added to the list of benefits.