Problem investigated: The success of IT projects is measured based on the benefits they deliver; anecdotal evidence states that IT projects fail at an alarming rate. The benefits are promised in the business case and should be delivered. This study focuses on whether there is a gap between theory and practice with regard to the way that organisations use the business case to approve, manage and track the promised benefits throughout an IT project.

Methodology: This article reports on exploratory research that was initiated to establish the current practice of business case application. Four research questions were developed based on an extensive literature review to support or debunk the anecdotal evidence. Semi-structured interviews were used to gather evidence from organisations based on these research questions.

Findings: The results suggest that organisations make use of business cases for various reasons and mostly in line with theory. There are, however, aspects that need to be addressed, such as the linkage between the business case and the harvesting of promised benefits.

Value of research: This article confirms the theoretical aspects of the business case but highlights some deviations from practice. Organisations need to be more vigilant in the management of the business case to ensure the tracking and realisation of promised benefits.

IT projects are initiated based on the business case and it is important that everyone involved has the same view about the purpose and role that the business case plays within an organisation. Is the business case used just for authorisation or is it also used to manage and track the promised benefits of an IT investment? It is important that within organisations the business case is dealt with in the same way, irrespective of the standard or methodology being used.

A review of the current literature indicates that the business case is not attracting the attention that it deserves.

Research articles focus on how the business case is applied for various concepts such as social networking and Linux (Leibovitch 1999; Wilson 2009). Project management journals, such as the International Journal of Project Management as well as the Project Management Journal have not published any articles since 2010 on the business case and its intended usage. This raises the question as to whether project management practitioners and project sponsors are satisfied with the way in which the business case is dealt with in the project environment. This article suggests that organisations may not use the business case as it is intended to be used. The results from the interviews indicate that, most of the time, the business case is used for the authorisation and approval of projects. Realised benefits are also not necessarily related back to the promised benefits according to the business case during project implementation or after project close-out.

It is proposed that the business case be taken more seriously by organisations in order to achieve the promised benefits. If the business case is going to be used only for approval and authorisation purposes, organisations will never be able to track and realise the intended benefits. This begs the question as to how project sponsors continue to justify the existence of projects.

The article seeks to understand the purpose for which the business case is used in organisations. Is it used only for financial justification (content), can it be used for decisions during project implementation (usage) and who is responsible for the business case (owner)? Semi-structured interviews were conducted with C-level members as well as project and programme managers to address the three concepts of content, usage and owner.

The article is structured as follows: the first section covers the literature review, the second section deals with the research method that was followed and the third part focuses on the results and their analysis. The fourth section focuses on a discussion of the results and the implications for practice and theory. This article is concluded in the fifth section.

It is common practice in organisations to approve IT and business projects based on a business case. Yet, it is indicated through research done by Eckartz et al. (2009) that many organisations are not satisfied with their business cases for IT investments. Cooke-Davies (2005:5) shows that many organisations find it difficult to state that projects are ‘approved on the basis of a well-founded business case linking the benefits of the project to explicit organization goals (whether financial or not)’. Many other organisations are unable to state that they had a ‘means of measuring and reporting on the extent to which benefits have been realised at any point in time’.

Given this evidence, it is important to ask how and when IT projects are perceived as successful. The benefits promised in the business case need to be incorporated into the project success criteria. Project success criteria might include quality, cost, scope, time and meeting the requirements. In a recent study undertaken by five of the major universities in South Africa, it was clear that IT and business-related projects are still not as successful as they should be (Marnewick 2013). This underlines the concerns raised by Eckartz et al. (2009).

Figure 1 is a graphical display of the success rate of IT-related projects in South Africa.

FIGURE 1: Information technology related project success rates.

Some 45% of IT and business-related projects are still failing or are perceived as challenged and are thus not delivering on the anticipated benefits. This is in sharp contrast to the CHAOS figures of 2009 where it was reported that only 32% of projects are perceived as successful (Eveleens & Verhoef 2010). This difference is attributed to the fact that project success is measured differently in the South African study.

The success criteria as per Figure 2 were derived from various sources to provide as complete as possible a list to the respondents (Ahadzie, Proverbs & Olomolaiye 2008; Ika 2009; Khang & Moe 2008; Thomas & Bendoly 2009; Thomas & Fernández 2008). Figure 2 indicates the responses from the respondents.

FIGURE 2: Information technology related project success criteria.

This indicates that organisations are slowly but surely making progress from the original triple constraint to more business-related criteria. The success criteria can be divided into two groupings: the first grouping focuses on the traditional criteria (i.e. time, cost, scope and quality). A total of 45% of the respondents indicated that the quadruple constraint was still important and 23.1% indicated that the triple constraint was still important. This implies that project managers are still evaluated on delivering projects within the allocated time and cost estimates. This suggests that the success of a project can be determined from the perspective of the means (the project itself).

The second grouping focuses more on the perspective of the end of the project (i.e. what it was intended or expected to accomplish). Criteria that were listed are user satisfaction (45.3%), met project requirements (42.9%) and met business objectives (41.8%). Project success is thus measured at two levels: the project itself and also the deliverables and products of the project itself. The criteria as per the second grouping, business objectives and project requirements, need to be stipulated in the business case.

A business case exists to ensure that whenever resources are consumed, they support one or more business objectives. The implication is that a business case must be reviewed at various stages during the project life cycle. Business cases are developed but are used solely to obtain funding approval for the huge upfront financial investment and not to actively manage the project (Eckartz et al. 2009).

The business case’s origin should be the business. The person who decides to invest in the project is the person responsible for quantifying the expected costs and benefits (Robertson 2004). The business case might be used by business decision-makers, business analysts, project managers, IT service managers, software designers and product managers (Khajavinia 2009).

The business case is owned by what PRINCE2 has termed the ‘executive’, who is ultimately responsible for the project. The APM body of knowledge (APMBOK) goes further and states that the project sponsor is the owner of the business case and that the business case needs to be evaluated during the project life cycle. The PMBoK® Guide, on the other hand, does not indicate who the owner of the business case is apart from the vague statement that ‘the requesting organization or customer may write the business case’ (Project Management Institute 2013a:69).

The APMBOK explains that the business case ‘provides justification for undertaking a project in terms of evaluating the benefit, cost and risk of alternative options and rationale for the preferred solution’ (Association for Project Management 2006:68). The Office of Government Commerce (2003) maintains that the business case must drive the project. Any project should not be started if there is not a satisfactory business case. In the case of PRINCE2, the business case is defined as the reasons for the project and the justification for the project based on the costs, risks and expected benefits. According to the Project Management Institute (2013a), the business case determines whether the project is worth the investment from a business point of view. It is seen as an input to the project charter.

The content of the business case is important, since various significant decisions are based on the business case. The APM in PRINCE2 suggests 13 content areas that should be included in the business case. As with the APMBOK, various content areas are suggested for the business case and a description is provided on how to develop a business case. The PMBoK® Guide does not explicitly indicate what the contents of a business case should be.

Table 1 is a graphic comparison of the standards and methodologies. It is clear that the PMBoK® Guide does not place the same emphasis on the business case as the APMBOK or PRINCE2.

The basic content of the business case is provided by the APMBOK and PRINCE2. PRINCE2 goes even further by stating that the level and depth of the business case will vary from project to project, depending on the complexity and size of the project. The PMBoK® Guide makes no reference to the content of the business case. All three standards and methodologies mention that the business case is used upfront to justify the existence of the project. Within the APMBOK and PRINCE2, however, the project needs to be evaluated continuously against the business case.

The literature clearly states that the owner of the business case is either the project sponsor or someone important enough to initiate a project. The project manager is not necessarily the owner of the business case.

Ward et al. (2008) indicate that investments in IT do not deliver on the promised benefits. They also maintain that the expected benefits have been inflated from the construction of the business case and are never possible. This is only done to have the project approved. The business case should clearly state how the intended project will contribute to the achievement of the organisational strategy (Ward & Daniel 2008).

A total of 65% of respondents indicated that their organisations were not satisfied with their ability to identify all the available benefits, with 69% reporting that they did not adequately quantify and place a ‘value’ on the benefits for inclusion in the business case (Ward et al. 2008).

Figure 3 is a theoretical representation of the business case information flow, which was derived from literature. The organisational strategies guide projects and programmes. The project sponsor or business owner motivates the existence of an initiative and creates a business case. The business case is used to authorise and guide the project implementation. Once the project has been delivered, its benefits are measured against the business case. The benefits should enable the organisation to achieve its strategic goals.

FIGURE 3: Theoretical framework for the business case information flow.

The following four research questions were developed based on the literature review:

• Research question 1: Is the business case aligned with the strategic intent of the organisation?
• Research question 2: Who is the owner of the business case?
• Research question 3: What is the purpose of the business case in a project environment? In other words, is the business case used only for project approval or for continuous assessment of the project?
• Research question 4: Are the benefits related back to the business case?

The next section discusses the research methodology that was followed to answer the four research questions.

Within the qualitative research methodology, various research methods exist, such as interviews, case studies, observations and action research (Altrichter et al. 2002). Interviews were chosen as the research method, as they allow the researchers to fully understand the subjects’ experiences as well as to learn more about their answers to the questions posted (Cunningham 2008). The advantages of the interview research method are that it provides a broad range and depth of information, that researchers develop a relationship with the subjects and that the researchers can be flexible during the interview itself (Kwok & Ku 2008).

The second step in the process was to devise a semi-structured interview guide focusing on three aspects:

1. The interviewee’s role and responsibilities within the organisation. The purpose of this aspect was to ensure that the appropriate interviewee had been targeted. It also determined if the interviewee responded to the various questions from an authoritative perspective, based on the length of employment in the position itself as well as within the organisation.
2. The organisational strategies that were initiated and executed, the role of business cases as well as the way in which projects were initiated and linked to the organisational strategies through the use of business cases. This section is the essence of the research, and the various questions within this section were based on the findings of the literature survey. The aim was to determine if practice followed the theoretical best practices, as suggested by literature.
3. The summation of the business strategies of the organisation as well as the perception of the interviewee regarding organisational success. The aim of this section was to determine the interviewee’s perception of organisational success. Perception was based on personal belief rather than on factual evidence. It also focused on additional information that the interviewee felt would provide context to the interview.

The third step in the research process was to identify project managers, business divisional heads, chief operating officers (COOs) and chief information officers (CIOs) of organisations who could participate in interviews. Convenience sampling was used to identify participants in the various organisations. Thirty interviews in total were held in South Africa as well as in Europe. This was done to determine whether a difference exists between South African and European organisations. The aim was to target C-level managers within organisations, since they are the ones who would naturally have a need for a new product or service, and would build a business case. The business case is the responsibility of business and it made logical sense to invite the business people responsible for the business case. Project managers were invited to understand the perspective from an implementation point of view. The researchers felt that the two different views from project managers and C-level managers might provide some additional information regarding the business case.

Participation was voluntary and formal permission was obtained from participants to use the results of the interviews for this study. Assurance was given that all results would be anonymised for reasons of confidentiality.

The interviews were conducted and recorded using a digital voice recorder, and additional notes were taken. Some interviewees provided examples of their business cases as artefacts. These artefacts were analysed to investigate similarities and differences in the various processes.

All interviews were then transcribed directly from the digital voice recordings. The researchers checked the transcripts for accuracy and correctness by comparing them to the digital voice recordings. The transcripts were then sent back to the interviewees to verify that they were an accurate and authentic copy of what was said in the interview. Interviewees were given the opportunity to change or remove anything with which they did not feel comfortable.

The verified transcriptions were made anonymous and then loaded into a computer-assisted qualitative data analysis (CAQDAS) software package to analyse the interviews and any supporting documentation (Lewins & Silver 2008). The CAQDAS package that was used was ATLAS.ti.

The CAQDAS package enables the researchers to code the transcriptions for analysis purposes. Coding allows the researchers to test the relationship between issues, concepts and themes, and to develop broader or higher order categories (Lewins & Silver 2008). It also facilitates the development of a detailed understanding of the phenomena that the data is seen to be presenting (Atherton & Elsmore 2007). Coding is influenced by various factors, for example the research aims, the kind of data as well as the depth level of the analysis (Lewins & Silver 2008).

Codes can be generated inductively or deductively (Mangan, Lalwani & Gardner 2004). Inductive codes imply that salient aspects are defined within the data and deductive codes are done based on predefined areas of interest. The researchers used inductive codes to prevent bias towards any of these areas, which are normally guided by a literature survey (Atherton & Elsmore 2007; Mangan et al. 2004). In this study, the literature survey already guided the composition of the questionnaire, and inductive coding provided a richness that was not possible through deductive coding.

Inductive coding follows a three-step process (Lewins & Silver 2008; Von Seggern & Young 2003):

1. Perform open coding: small segments of data are considered in detail and compared with one another. This step generates large volumes of codes that encapsulate the notion of ‘what is going on’.
2. Perform axial coding: all the codes that were generated are analysed. Codes are rethought in terms of similarity and difference, and consolidated where appropriate.
3. Perform selective coding: the researchers revisit the codes. The instances in the data that pertinently illustrate themes and concepts are identified. The identification was done based on common recurring themes being grouped together to present a common theme. Conclusions are validated by illustrating instances represented by and grounded in the data.

Based on the inductive coding process, the data was analysed in order to develop a better understanding.

‘The next step is then a cascading down in the organisation [South African Mobile Operator], so we start with the high-level strategic objective. We then look at what we call business planning, but that is really taking a strategic objective and cascading it down per functional unit. So what does that mean for a functional unit and what do we need to do to achieve that? It then cascades down until it ends up on my personal performance agreement.’ (South African Mobile Operator)

Figure 4 provides a network view of the inductive codes that informed the first research question. There are ten codes in this family, consisting of 40 responses from the interviewees.

FIGURE 4: Network view: Inductive codes reflecting research question 1.

The respondents explained that the strategies were categorised in some instances. The business cases were aligned with the strategic themes within the organisation, which were ‘developed and launched for the following year’. The strategic themes were ‘very strong, limited down to six, seven key initiatives and each business case tied into those which then drove out the individual project’. It is clear from these responses that organisations are categorising their strategies, that the rest of the business and functional units must align with these themes or categories and that projects must ultimately be derived from and classified within them.

One respondent, however, stated that not all business cases were aligned with the strategy of the organisation:

‘It started off with an operational need and like everything needs get great, one thing along this is starting to see other potential benefits and there is one angle that we actually can link it to, a strategic initiative.’ (Respondent A, Male, CIO, Vehicle Tracking Company)

It is also clear from the interviews that organisations are still using either a top-down or bottom-up approach to derive and link the respective projects to the strategies of the organisation. One of the interviewees indicated that ‘it is very much not a top-down’ but that organisations realised that they had to transform to a more top-down approach.

It is also evident that the organisations reviewed the strategies on a regular basis. One organisation in the fast-moving consumer goods industry ‘[redid] it about every six months and we review it every month’. Some other organisations reviewed it on an annual basis: ‘Every year they look at the business planning processes, strategic thinking processes for the following year.’

This revision of the strategies has a direct impact on the validity of the various business cases that are derived from or linked to the business strategies. Responses varied from ‘should a project change its scope, timeline and its financial request so in other words the budgeting request the business case is reviewed’ to ‘and during the execution of the project, the business case is checked whether it’s still valid and sometimes it’s not valid and then we kill the project’. It is evident that organisations do revisit their business cases and benchmark them against the original and revised business strategies.

Given the analysis of the responses, the following conclusions can be drawn from the interviChanel Martinews:

• Business cases are aligned with the strategic initiatives of the organisation. The strategic initiatives inform the business case and projects are based on the business case. Organisations also use different approaches to derive the strategic initiatives: most use the top-down approach (60%) and the remainder use the bottom-up approach to link the business case to the strategic initiative.
• The business case must be positioned within the themes or key initiatives to ensure alignment.
• The strategies of the organisation are revised frequently to cater for environmental changes. This in turn has an impact on the business case. According to the results, the business case is updated and reviewed regularly to verify the validity of the business case.

One respondent summarised it, stating that ‘first of all you’ve got to come with the strategy and then you’ve actually got to implement’.

Given the fact that business cases are aligned with the strategic intent, the next research question explored who was the owner of the business case.

What differs amongst the respondents is the reason why business is the owner of the business case. The first aspect is that the business takes ownership for their decisions and that businesses ‘don’t just put things down to get approval and get it going and then walk away without ramifications’. A second aspect that emerged very clearly is that the business case and expected benefits are attached to a role and not an individual:

The other component to your question is the accountable person and that normally leads to a role rather than a person; so the role of general manager would sign up to certain benefits.

Only one respondent stated that it was the project manager’s responsibility to deliver the benefits. This goes against all theory which states that the project manager’s role is to deliver the project deliverables within the specified project success criteria. The delivered product or service should derive benefits, but it is the role of business to ensure the realisation of those benefits.

The following conclusions can be drawn from the results:

• Organisations use business cases to authorise projects. Although the interviewees stated that projects were authorised based on a business case, the actual results contradict these statements. Some interviewees confirmed that ‘about 99% of the projects’ or ‘I think all of them have been initiated on a business case’. However, there were some interviewees who stated ‘maybe even 25% – 30%, maybe on a high side’ or that even one in every three projects would have a business case.
• The responsibility and accountability of the business case per se lie with the business itself. The implication is that the project manager is not the owner of the business case, as is generally assumed.
• There are various reasons why the business owner or sponsor takes ownership of the business case, amongst which is accountability. The business owner cannot just approve a project based on a business case and then walk away without facing any consequences if it is a failure.
• The business case and its expected benefits are allocated to a role and the incumbent of that specific role takes accountability for delivering the benefits.

The next research question flowed logically from the previous two research questions. If the business case is strategically aligned and the business per se owns the business case, what then is the purpose of the business case?

FIGURE 5: Network view: Inductive codes reflecting the purpose of the business case.

The interviewees provided 13 purposes of the business case. The top purpose was that the business case was used for justification purposes: to ’justify the existence of a project’. The justification also implies that ‘you are going to be held accountable’. Some of the justifications also include compliance, as one interviewee from the Netherlands put it: ’There is a clear business case why we should do things or not. Most of the business cases are compliance driven.’

An important purpose is the financial aspect that the business case addresses. One respondent mentioned that the business case should ‘make financial sense’ to implement the project. This view was echoed by another respondent who stated that ‘CAPEX is approved and the money is released against the business case’.

Respondents also indicated that the business case was utilised for prioritisation: ‘Yes, so then we will take that business case to our prioritisation forum and the prioritisation forum will assess and debate.’ This view was shared by several of the respondents and the main reason was that resources were a scarce commodity: ‘Thirdly, it will say is there resources available to actually sit and help you. Not just project resources but also resources within the business.’

Another purpose of the business case mentioned was that it must define the expected benefits. This view was echoed by various respondents: ‘to state to see if there is any benefit, tangible benefit that we will get out of it’ and ‘it has to have a component of the benefits and how you can derive the benefit and how you can measure the benefits’.

A fifth purpose that was attributed to the business case was that it was used for the authorisation of projects. The business case was perceived as a bargaining tool that ‘you can actually use it for authorisation’ and ‘the answers are slightly different in that no project in the bank will be entertained without a business case’.

Another purpose was that organisations ‘look at it from a strategic driver perspective’. An important aspect of this strategic perspective is that a holistic view is needed. One respondent put this in perspective: ‘Whom does it impact in the bank? Is it just your division that it has touched throughout the organisation?’

An interesting aspect is that one interviewee specifically stated that the purpose of the business case was to:

‘make sure that at each stage of the project that we are still adhering to what the principles for the business case are, e.g. are costs still within tolerance, are revenues still going to be achieved etc.’ (Respondent B, Male, Programme Manager, Central Securities Depository Company)

The purpose was explicitly to continuously revisit the business case and to ensure that it was valid.

The following conclusions can be drawn from the interviews:

• The purpose of the business case varies from organisation to organisation. There is no golden rule that dictates this purpose.
• The business case has various purposes within an organisation and this varies from organisation to organisation.
• The first aspect is that a business case and its subsequent project must make financial sense. Business cases will not be approved if there is no financial indication that the project might deliver benefits to the organisation.
• The business case is also used to authorise projects. Even if a business case is approved, it does not imply that the subsequent project is automatically implemented. The authorisation aspect controls and allocates the limited resources within the organisation.
• Projects are prioritised, based on the business case. The better the business case is motivated, the higher the priority that will be allocated to the project.
• An important aspect is the benefits that need to be defined. The benefits go beyond financial implications and competitive advantage; they need to address long-term implications.

Irrespective of what the purpose of the business case is, the business owner or sponsor must apply their mind to ensure that the business case is well structured and meets the needs of the organisation. As one interviewee put it, ‘part of that is to get people to actually apply their minds’.

FIGURE 6: Network view: Inductive codes reflecting whether benefits are related back to the business case.

The first view was that there was no process in place: ‘That process in itself is not in place currently.’ Another respondent mentioned that ‘I do it informally but the business formally doesn’t do it’. One respondent admitted: ‘I don’t think there is a loop back. I haven’t seen that there is a loop back.’ This view was echoed by 17 of the interviewees.

The contrasting view was that some organisations actually did relate the benefits back to the business case. This process is called benefit harvesting and ‘that is where you revisit the benefit after a project goes live’. One respondent also mentioned that ‘yes, so the benefits, we track like measurements set if you like and we continue to track those’. This was also a continuous process:

‘we go back every month and check whether it still makes sense and we had in that specific project a market change which caused us to actually stop the project.’ (Respondent C, Male, CIO, FMCG Industry)

One interviewee cautioned that ‘you can’t double count benefits’. This was especially the case where projects were part of a programme and benefits were shared amongst the projects.

In the companies that did track the benefits back to the business case and eventually to the strategies, the tracking occurred at two levels. The first level was where the benefits were tracked after the completion of the project:

‘Post-implementation review [takes place] where my stakeholders sit around the table and we go through line item by line item and the objectives of the project have they been met.’ (Respondent D, Male, Project and Operations Manager, Retail Bank)

The second level was where the benefits are tracked regularly throughout the project life cycle. This was only practised by two of the organisations and the benefit of this can be reported as: ‘are we still on track to deliver your benefits and there is a whole stack of other nice things that happen if you actually define those benefits for them’.

It can be stated that:

‘into the business case we have to adhere to the strategic objectives so inherently if your business case carries the strategic objectives and the benefits predicted was realised come from your business case then there is a common threat there.’ (Respondent B, Male, Programme Manager, Central Securities Depository Company)

The following conclusions can be drawn from these interviews:

• The majority of the organisations (57%) have a formal process in place to relate the benefits to the business case. This is particularly the case where the methodology that is used prescribes the benefit management as part of the formal methodology.
• Other organisations (43%) do not have a process in place to relate the benefits back to the business case. This raises the question as to how project success and ultimately organisational success are measured.
• Although some organisations do not have a formal process in place, some individuals do this informally. This is very dependent on the maturity of the individual and not on the maturity of the organisation.

In summary, it can be mentioned that organisations realise that this process needs to be in place, as it was reported that ‘in the past it was not but there is a big drive in the bank to actually do exactly that’.

The following section concludes this article: the process as per Figure 3 is analysed, based on the interviews.

1. The organisational strategy is used to inform business of the way forward. This strategy is divided into different themes or initiatives and the business cases are aligned with them. The business case is thus directly guided and informed by the strategy and direction of the organisation. The significance is that theory is informing practice.

2. The second research question also confirms that theory is informing practice or that practice is adhering to best practices. It is clear from the interviews that the business case is owned by the business through the roles of business owner or project sponsor. This implies that this individual is accountable for delivering the benefits as promised. This accountability is grounded in the role and not allocated to the person occupying the position.

3. Although organisations use business cases for various reasons, the main purpose is to justify the existence of projects. This implies that projects implement the strategy of the organisation through the business case. The business case must make financial sense and this is in accordance with theory. Based on this justification, projects are then prioritised; this prioritisation is dependent on the expected benefits that are promised in the business case. This is very much in accordance with the APMBOK as well as PRINCE2, which stipulate that benefits must be part of the business case.

4. The fourth research question highlighted some anomalies. According to the theory, benefits must be related to the business case and the strategy of the organisation. This is not always the case in practice, though, and in some instances the benefits are never linked to the business case. Some organisations have this process in place, and benefits are actively tracked and related back to the business case. There are various reasons why the benefits are not actively tracked. One reason is that some organisations are not mature in the discipline of project management. A second reason is that the business owner and sponsor might not necessarily know that they are supposed to track and report on the benefits. This leaves the question of who is ultimately responsible for this last part of the process: is it the business or the project management environment? The results from the interviews as well as literature (Bradley 2010) suggest that the business is ultimately responsible for linking the benefits back to the business case and then to the organisational strategy.

Given the discussion above, a comparison between theory and practice resulted in the compilation of Figure 7.

FIGURE 7: Actual business case information flow measured against theoretical model.

As seen in Figure 7, all the processes are in place apart from the last process during which the benefits need to be measured against the business case and organisational strategy.

A synthesis of the literature suggests that research studies on business cases, and especially IT-related business cases, are few and far between. The major project management standards and research journals do not allocate space to the importance of the business case. The business case is perceived as an important input but that is as far the importance of the business case goes. A common thread from the literature is that the business case justifies the investment in a specific project and that benefits should be harvested from the project. The literature also suggests that organisations do not necessarily harvest the benefits of their IT investments and subsequent projects. This constitutes the research problem at hand: what is the business case used for in terms of IT investments and is the business case the link between organisational strategies and the promised benefits?

The study started with four research questions that were developed, based on a comprehensive literature survey. The research questions were then tested by means of semi-structured interviews with practitioners in the field. The trends were presented and gave an indication of the current state of business case practices. Based on the results, it can be seen that there is a small gap between theory and practice. Most of the interviewees were familiar with the theory and in support of its application in their respective environments.

The research indicates that the practice of business cases is generally adhered to and that interviewees applied the business case as indicated in theory. One aspect that needs to be addressed is reporting on the business case. There are some organisations that do not relate the benefits back to the business case and organisational strategy, though most indicated that it was a process that they had embarked upon.

Although most organisations understand the purpose and significance of the business case, it is important to close the final part of the loop. This is the linkage between the benefits, the business case and the organisational strategy. Various solutions exist and are available through project and programme management standards (Project Management Institute 2013a; 2013b) as well as books on the topic of benefits realisation management (Bradley 2010; Ward & Daniel 2008). What seems lacking is the political will of organisations to close the loop to ensure that what is promised is actually delivered. There must be accountability on the part of the owner of the business case.

Further research will continue to provide an understanding of the relationship between the business case and governance. This research indicates that organisations do not close the loop and this begs for some governance aspects to be brought into the business case. Research will also establish whether there is a difference in how organisations in the Netherlands and South Africa utilise the business case for maximum benefits realisation. This can be done through a mapping process to the best practices of benefits realisation management.

A final word:

And they have to write down what is the current situation, what do they want to achieve, why is it necessary to do something about the situation, what happens if we do nothing, how much will it cost, what benefits are expected.

Altrichter, H., Kemmis, S., McTaggart, R. & Zuber-Skerritt, O., 2002, ‘The concept of action research,’ The Learning Organization 9(3), 125–131. http://dx.doi.org/10.1108/09696470210428840

Association for Project Management, 2006, APM Body of Knowledge, 5th edn., Author, Buckinghamshire, England.

Atherton, A. & Elsmore, P., 2007, ‘Structuring qualitative enquiry in management and organization research: A dialogue on the merits of using software for qualitative data analysis’, Qualitative Research in Organizations and Management: An International Journal 2(1), 62–77. http://dx.doi.org/10.1108/17465640710749117

Balnaves, M. & Caputi, P., 2001, Introduction to quantitative research methods – an investigative approach, Sage, London, England.

Bell, J., 2007, Doing your research project: A guide for first-time researchers in education, health and social science, 4th edn., Open University Press, Berkshire.

Bradley, B., 2010, Benefit realisation management: A practical guide to achieving benefits through change, 2nd edn., Gower, Surrey.

Cooke-Davies, T.J., 2005, ‘The executive sponsor – the hinge upon which organisational project management maturity turns’, paper presented at the PMI Global Congress, Edinburgh, Scotland, 23–25 May

Cunningham, W.S., 2008, ‘Voices from the field: Practitioner reactions to collaborative research initiatives’, Action Research 6(4), 373–390. http://dx.doi.org/10.1177/1476750308097025

Eckartz, S., Daneva, M., Wieringa, R. & Hillegersberg, J., 2009, ‘Cross-organizational ERP management: How to create a successful business case, paper presented at the proceedings of the 2009 ACM Symposium on Applied Computing, Honolulu, Hawaii, 09–12 March. http://dx.doi.org/10.1145/1529282.1529641

Eveleens, J.L. & Verhoef, C., 2010, ‘The rise and fall of the Chaos report figures’, IEEE Software 27(1), 30–36. http://dx.doi.org/10.1109/MS.2009.154

Ika, L.A., 2009, ‘Project success as a topic in project management journals’, Project Management Journal 40(4), 6–19. http://dx.doi.org/10.1002/pmj.20137

International Institute of Business Analysis, 2009, A guide to the Business Analysis Body of Knowledge (BABOK Guide), 2nd edn., Author, Toronto, Canada.

Khajavinia, R., 2009, ‘The basis for building a business case in software development: A case study’, paper presented at the IEEE EUROCON 2009, St Petersburg, Russia, 18–23 May.

Khang, D.B. & Moe, T.L., 2008, ‘Success criteria and factors for international development projects: A life-cycle-based framework’, Project Management Journal 39(1), 72. http://dx.doi.org/10.1002/pmj.20034

Kwok, J.Y. & Ku, H.B., 2008, ‘Making habitable space together with female Chinese immigrants to Hong Kong: An interdisciplinary participatory action research project’, Action Research 6(3), 261–283. http://dx.doi.org/10.1177/1476750308094131

Leibovitch, E., 1999, ‘The business case for Linux’, IEEE Software 16(1), 40–44. http://dx.doi.org/10.1109/52.744567

Lewins, A. & Silver, C. 2008. Using software in qualitative research, Sage, London.

Mangan, J., Lalwani, C. & Gardner, B., 2004, ‘Combining quantitative and qualitative methodologies in logistics research’, International Journal of Physical Distribution & Logistics Management 34(7), 565–578. http://dx.doi.org/10.1108/09600030410552258

Marnewick, C. (ed.), 2013, Prosperus report − the African edition, Project Management South Africa, Johannesburg.

Office of Government Commerce, 2003, Managing successful projects with PRINCE2, Author, London.

Project Management Institute, 2013a, A guide to the Project Management Body of Knowledge (PMBOK Guide), 5th edn., Author, Newtown Square, PA.

Project Management Institute, 2013b, The standard for program management, 3rd edn., Author, Newtown Square, PA.

Robertson, S., 2004, ‘Requirements and the business case’, IEEE Software 21(5), 93–95. http://dx.doi.org/10.1109/MS.2004.1331310

Swanson, S.A., 2011, ‘Boosting the bottom line’, PM Network 25, 51–54.

Thomas, D. & Bendoly, E., 2009, ‘Limits to effective leadership style and tactics in critical incident interventions’, Project Management Journal 40(2), 70–80. http://dx.doi.org/10.1002/pmj.20118

Thomas, G. & Fernández, W., 2008, ‘Success in IT projects: A matter of definition?’, International Journal of Project Management 26(7), 733–742. http://dx.doi.org/10.1016/j.ijproman.2008.06.003

Von Seggern, M. & Young, N.J., 2003, ‘The focus group method in libraries: Issues relating to process and data analysis’, Reference Services Review 31(3), 272–284. http://dx.doi.org/10.1108/00907320310486872

Ward, J. & Daniel, E., 2008, Benefits management: Delivering value from IS & IT investment, John Wiley & Sons, West Sussex.

Ward, J., Daniel, E. & Peppard, J., 2008, ‘Building better business cases for IT investments’, MIS Quarterly Executive 7(1), 1–15.

Wilson, J., 2009, ‘Social networking: The business case’, Engineering & Technology 4(10), 54–56. http://dx.doi.org/10.1049/et.2009.1010