Background: In recent years, much has been written about how to present a compelling business case. But, if just one critical piece of information is overlooked, it can lead to the wrong decision being taken. This article aims to minimise the risk. It stems from research conducted into how the business case can be used more effectively to improve the success rate of information technology (IT) or information technology or business (ITB) projects. The business case, usually a document, indicates whether the investment in money and resources is justified, prior to or at any time during the project. ‘Effective use’ involves using certain business case processes throughout the ITB project’s lifetime. Here, the life cycle refers only to the IT component of the project. The lifetime is longer, extending from initial proposal until all benefits have been realised. However, it is found that the processes are not easy to adhere to, a probable cause being the lack of relevant information.

Objectives: The aim of this study was to determine what information is needed to drive the business case processes before, during and after the IT deliverables are produced.

Method: The information types are derived from a structured review of literature related to the business case.

Results: Details of the information types to create the business case are presented and related back to the business case content elements. Further information types that only arise during planning and subsequent tracking of the business case are also presented.

Conclusion: For sound project governance, underpinned by effective use of the business case, it is essential to know what information needs to be gathered throughout the project’s lifetime. While knowing the processes and their relevant information is essential, further research is needed into the organisational factors that either facilitate, or inhibit such information gathering.

Introduction

Information technology or business (ITB) projects are those where business benefits are achieved through the use of IT deliverables. This article investigates how the business case can be used more effectively to underpin project governance, and hence lead to more successful ITB projects. Although there is no agreed definition of governance, it is considered to be the framework of policies and processes in the organisation to implement projects that will achieve objectives in the overall best interests of involved stakeholders (Musawir et al. 2017). Governance can relate to a single project or to multiple projects where selection and prioritisation are important (Müller, Pemsel & Shao 2014). This article then goes on to address a conclusion, drawn from Einhorn and Marnewick (2016), that lack of understanding of the information required is one of the reasons for the business case not being used effectively. Thus, the focus is on the information that is required to supply and interact with the various business case processes throughout the ITB project’s lifetime.

The literature review discusses the nature of the business case, and the processes needed to take full advantage of it. However, it concludes that the processes are not easy to follow, partly because of the amount of information required. This leads to the research question as to the information needed for the effective use of the business case.

A conceptual model is then presented showing the linkages between the business case processes and the information required at different stages of the project’s lifetime. A summary of the information is provided, showing how pre-project business case information remains relevant, but needs to be supplemented by further information during planning, execution and benefits realisation phases. Detail of the business case information is given in Appendix 1. Conclusions are then drawn as to whether understanding of business case processes and information is sufficient to enable the effective use of the business case.

Research methodology

Content analysis was used to explore the concept of the business case and to summarise the findings of the literature reviewed. The following processes were used:

A coding frame was used to categorise and analyse the results of the selected performance criteria adopted in this research, which were later used to conceptualise the various themes related to the business case. Figure 1 illustrates the themes, and shows that ‘business case processes’ and ‘business case information needs’ are close to the core.

Each theme is assigned a unique ‘theme tag’ in the reference manager tool, which is used to search for relevant papers during the writing on a particular topic. The main tags used for this article are ‘PROCCT’ – processes to create and track the business case – and ‘INFOCR, INFOTR’ – information to create and track the business case. Each tag may be used multiple times for a particular article. Thus, each selected idea has a tag, and article page number, in the ‘Research Notes’ section of the reference manager tool. When writing about business case information, it is possible to seek relevant ideas, even where articles cover several themes. Such references contribute to Tables 1–3, which outline business case information, and to corresponding Tables 1-A1–3-A1 in Appendix 1, which also give the source and use of each information type, as well as at least one reference.

Some judgement is used as to the level of detail, for example, ‘Enterprise Environmental Factors’ is treated as a single information type, even though it could potentially break down into multiple information types, depending on the project (PMI 2017).

Having extracted the information types, they are mapped, in Table 4, against the business case content elements derived from reference texts, to give some assurance that nothing important has been overlooked.

Literature review

Information technology or business projects and the business case

The following background on ITB projects offers a perspective on their unique aspects and success rate. Peppard, Ward and Daniel (2007) find that IT deliverables alone are insufficient, and that business changes are needed to take advantage of them, to produce business benefits. This means that an ITB project has two parts: developing the IT products and using them to create value (Ward, Daniel & Peppard 2008). Moreover, the two parts are carried out by ITB staff, respectively, who often have different backgrounds and use different terminology. Nevertheless, communication between them is essential as neither group knows all aspects of the project (Sauer & Reich 2009; Zwikael & Smyrk 2012). Information technology or business projects that arise in all industry sectors are known to be challenging, and surveys show that up to 20% of ITB projects fail, with a further 40% being challenged, resulting in considerable wasteful expenditure (Joseph, Erasmus & Marnewick 2014; Standish 2014).

An effectively used business case can do much to address such challenges. A business case is a formal document to set out the rationale for a project investment, justify it and hence to get management commitment and authorisation to proceed. As such, it summarises anticipated benefits while considering alternative options and recommending a preferred solution. It provides an overview of the scope of work, the costs, the time frame and the risks. The business case, owned by the project sponsor or business owner, is subject to review and ongoing viability testing throughout the project’s lifetime (Cooke-Davies 2005; Franken, Edwards & Lambert 2009; OGC 2009; PMI 2017).

The business case not only supports project governance from inception, through IT delivery and eventually to benefits realisation, but it also supports the governance of a portfolio of projects, where project selection and prioritisation are needed (Müller et al. 2014). Thus, the business case contributes to success and minimises the risk and impact of failure in the following ways (Einhorn & Marnewick 2016):

The business case processes

To achieve these benefits, a number of processes need to be followed to create and track the business case. The detail and purpose of each process, and their literature references, may be found in Einhorn and Marnewick (2016). The processes are grouped into ‘process groups’, illustrated in Figure 2, which are in broad chronological sequence. The process groups are described in the paragraphs that follow. Process groups 1–3, for creation of the business case, are generally done pre-project. In process group 4, approved projects are prioritised and resourced, while process groups 5–8 are done after project initiation. If a project happens to be initiated without a business case, then process groups 2 and 3 should be done early in the immediately following project planning phase.

Process group 1 covers preparation for the business case. A high-level project proposal is submitted to the decision-making authority, which might be responsible for the portfolio of projects in the organisation. It states the business drivers, and sometimes a mapping is done of proposed benefits, to the business processes changes, and IT deliverables, on which they depend. The proposal is evaluated in terms of business priorities. If it is selected, the project sponsor is confirmed and authorisation given to expand the proposal into a business case; if not, the proposal is rejected and archived.

Process group 2 covers the groundwork for the business case. It might involve considerable investigation, involving the main stakeholders, whose requirements and decision criteria need to be understood. The expected business benefits are detailed with their estimated value over time, and intangible benefits noted. Responsibility for achieving each benefit is assigned to a person, indicating how it will be measured. The main implementation alternatives are considered, and the preferred one stated. The initial scope definition is then done for the preferred alternative, which includes the business process changes, and any organisational changes, required to enable the benefits. An initial risk assessment is conducted, and costs are estimated with a contingency amount to cover risk.

Process group 3 covers assembly, review and presentation of the business case. Based on the groundwork, explanations and estimation methods are documented with necessary evidence, while the underlying assumptions, dependencies and constraints are set out. Where appropriate, the overall financial benefit is calculated, and recommendations are stated, emphasising the key themes. Quality assurance is performed to ensure that content is sound, relevant and clear, preferably involving an independent reviewer for major initiatives. Finally, the business case is presented to key stakeholders, leading to a decision or a request for further investigation. Once again, if the business case is rejected, it is archived for future reference.

Process group 4 covers prioritisation of projects that have been approved. It could involve several processes, depending on the governance mechanisms in the organisation. The outcome is a decision whether and when the project will be initiated, based on resource availability.

Process group 5 involves integrating information from the business case into the project plan and benefits realisation plan. At the end of planning it is important to ensure that the business case still aligns to the plan, and remains viable. Future reviews involving the business case should form part of the plan.

Process group 6 covers regular monitoring and reporting of project scope, schedule, costs and risks.

Process group 7 involves ad hoc or planned reviews. During the reviews the business case should be updated and checked for ongoing viability.

Process group 8, the last group, involves measurement and assessment of outcomes. Realised benefits are compared with those in the business case and action taken where there is a significant shortfall. After the final assessment, lessons learned are documented to inform future projects.

The eight process groups, which cover the ITB project’s lifetime, should ideally be followed in the sequence given, but in practice there is usually iteration. For example, assumptions may be revisited during later project stages, and constant reprioritisation is done during projects that follow an agile methodology. Processes within the groups are often omitted, sometimes justifiably and sometimes to the detriment of the project.

The research problem

It emerges from Maes, De Haes and Van Grembergen (2014) that even where the process groups, and their processes, are well understood, following them is not easy. An inhibitor is the difficulty of gathering relevant information, in sufficient detail, at the appropriate times, throughout the project’s lifetime (Einhorn & Marnewick 2016). Therefore, the research problem is: ‘There is a lack of understanding of the information required for the business case, resulting in its ineffective use’.

The goal of this article is to understand what information may need to be gathered, depending on the context of the project, and to confirm that it covers the main content elements of the business case.

The relationship between business case processes and information

Figure 3 provides a model that shows the linkages between the business case process groups and the business case information categories. The information types that make up the information categories are described in subsequent sections. The need for the model arose, when it became apparent that much of the information required during tracking, is different from information that is available when the business case is first presented (Brandon 1998; OGC 2009; Samset & Volden 2015). So, additional information is generated during planning, and still more during execution and benefits realisation. The model, constructed from the process groups in Figure 2 and the points at which information becomes available, is referred to when introducing the information categories, setting the stage for detailing the information types within the categories.

One purpose of gathering information is to inform governance decisions. As suggested in the earlier subsection on processes, governance decisions can be taken at any time, but the points, at which they are typically needed, are denoted by diamonds marked ‘D’. Decisions could be to continue the project, make changes or stop the project (Larson & Gray 2014). The figure illustrates the case where all decisions are to continue the project.

To address the research problem, it is essential to understand what information to seek at different times in the project’s lifetime. Such information is categorised into the yellow, green and pink categories in Figure 3, and their interaction with the business case process groups is as follows:

As indicated by the double-ended arrows, all business case process groups, after project start, both use and generate information. Also, because the business case is updated regularly, the ‘to create’ and ‘from-planning’ information is effectively used in all subsequent processes (shown by fainter arrows in the figure).

Information required by the business case processes

In this section, the information identified earlier is expanded on using colours corresponding to information categories in Figure 3. Further detail of each information category is given in Appendix 1.

Information to create the business case

There is a fine distinction between business case information and domain information, where ‘domain’ refers to the business, design or technical aspects. Some high-level domain information might be included to ensure effective communication with stakeholders, but detail would be contained in specifications and designs that are usually done after the business case has been created.

Some of the ‘to-create’ information types may appear in earlier project proposal or concept documents (Larson & Gray 2014). Most of the information would subsequently inform the project plan and benefits realisation plan (OGC 2009). The information needs to be checked for validity throughout the project’s lifetime.

Some metadata could apply to all business case information. For example, the project name may already have been proposed by stakeholders and approved by the sponsor (OGC 2009). Likewise the project number or code may have been assigned by portfolio management. Such metadata, including author and date, would be placed in all documents, often in header or footer text, to give context to the document’s contents. Refer to Table 1-A1 for detailed information on the ‘to-create’ information category.

Information, from project planning, used in business case processes

Information that arises during project planning and is used in business case processes is itemised in Table 2. OGC (2009) recognises that planning gives considerable detail that was not available earlier, and that the business case is likely to change as a result. Therefore, OGC (2009) refers to an ‘outline’ business case when approval is given to start the project, accepting that information, at this point, is approximate and subject to change.

‘From-planning’ information also sets up baselines, like planned values, that are used to monitor the project, and review the business case, during and after project execution. Some information types only affect the business case indirectly. For example, schedule risk analysis might show that the schedule is overoptimistic, which, in turn, affects risk, and hence the business case. Refer to Table 2-A1 for detailed information on the ‘from planning’ information category.

Information, for project review, used by business case processes

Information generated during project execution, which is used to monitor progress and to review the business case, is itemised in Table 3.

Herman and Siegelaub (2009) assert that every aspect of the business case can change over time, with the acquisition of additional information. Therefore, the business case must be reviewed periodically to check that it is still viable and justified, using the additional information types from execution. Information would be generated regularly, when required or at defined milestones, and is collectively referred to here as ‘for‑review’ information types (colour-coded pink). They should be used to monitor project progress by comparing them to the project plan which is, in turn, derived from the business case. Information to monitor the project (numbers 43–51) is relevant because any significant deviation from plan, or new issue or risk, might trigger a review of the business case if it causes a key stakeholder to expresses doubts as to the project’s ongoing justification. The ‘for-review’ information types would also be used for gate reviews and other reviews, where the business case is updated and validated (Larson & Gray 2014). An important benefit of tracking is that it allows the business case to be used to guide the project throughout ongoing decision-making. Refer to Table 3-A1 for detailed information on the ‘for review’ information category.

Mapping of ‘to create’ information, to business case content elements

In Table 4, the ‘to-create’ information types are mapped to the business case content elements derived from reference texts (APM 2006; ISACA 2012; ITGI 2008; Messner 2013; OGC 2009; PMI 2017; Vidal, Marle & Bocquet 2011). The fact that each content element is fed by at least one information type serves as a crosscheck that types are not obviously missing. It indicates the more important relationships, but not every possible one, as business cases are contextual, and what applies to one project may not apply to another. Table 4 is created by considering each business case content element (horizontal axis) in turn, and indicating with a ‘Y’ the likely ‘to-create’ business case information types (vertical axis) that might be needed to inform it. Thus, to determine which information should be sought to inform one content element, the reader would go vertically down from the content element, and left from every ‘Y’ to find the likely information types.

Some content elements, like ‘evaluation of options’, may require many information types for each option considered. Other content elements, like ‘funding sources’, may require only a few information types. Thus, the mapping shows that there are ‘many-to-many’ relationships, where one business case information type maps to multiple business content elements and vice versa. The number of relationships, in turn, demonstrates the complexity of the business case, and that judgement is needed to select the most relevant information.

Conclusions and the requirement for future research

From the literature it is concluded that ITB projects, which have unique challenges, have an unsatisfactory success rate. This situation can be improved through project governance, underpinned by business cases, which, if used effectively, ensure the ongoing justification for investments in ITB projects. Business cases, in turn, need well-understood processes and information, for them to be effective. These processes and information types are summarised in the conceptual model given in Figure 3.

The processes from Einhorn and Marnewick (2016) and the information types presented in this article can be put to immediate use to guide project sponsors, other executives and also project management practitioners, who all play key roles in project governance. The information types underline the importance of establishing relationships with stakeholders who must provide the information, as well as the judgement to determine what is relevant. Although the information types covered are in the context of traditional or agile ITB projects, most information types would apply to any project.

Nevertheless, there are avenues for further research. Although it is necessary to understand the business case process groups, and the information that feeds and arises from them, such understanding on its own may be insufficient to engender effective use of the business case. There are many organisational factors that facilitate or inhibit the gathering of information and the business case processes themselves. An example might be the attitude of business users towards providing information, and being fully involved in many aspects of the project. Research into these business case effectiveness factors is therefore a future objective.

Acknowledgements

The authors declare that they have no financial or personal relationships that may have inappropriately influenced them in writing this article.

F.E. was responsible for the conceptualisation, literature review and drafting of the article. C.M. was responsible for the final review and quality review.

References

APM, 2006, APM body of knowledge, 5th edn., Association for Project Management, Buckinghamshire, UK.

Brandon, D.M., 1998, ‘Implementing earned value easily and effectively’, Project Management Journal 29(2), 11–18. https://doi.org/10.1177/875697289802900204

Cadle, J., Paul, D. & Turner, P., 2010, Business analysis techniques - 72 Essential tools for success, BCS the Chartered Institute for IT, London.

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

Coombs, C.R., 2015, ‘When planned IS/IT project benefits are not realized: A study of inhibitors and facilitators to benefits realization’, International Journal of Project Management 33(2), 363–379. https://doi.org/10.1016/j.ijproman.2014.06.012

Crawford, L., Hobbs, J.B. & Turner, J.R., 2005, Project categorization systems - Aligning capability and strategy for better results, PMI, Pennsylvania, PA.

Denolf, J.M., Trienekens, J.H., Wognum, P.M., Van der Vorst, J.G.A.J. & Omta, S.W.F., 2015, ‘Towards a framework of critical success factors for implementing supply chain information systems’, Computers in Industry 68, 16–26. https://doi.org/10.1016/j.compind.2014.12.012

Disterer, G., 2002, ‘Management of project knowledge and experiences’, Journal of Knowledge Management 6(5), 512–520. https://doi.org/10.1108/13673270210450450

Einhorn, F. & Marnewick, C., 2016, ‘A practical model for the effective use of the business case in IT Projects’, Paper presented at the PMSA Conference 2016, Johannesburg, 9–11 November.

Flyvbjerg, B. & Budzier, A., 2011, ‘Why your IT project may be riskier than you think’, Harvard Business Review 89(9), 23–25. https://doi.org/10.2139/ssrn.2229735

Franken, A., Edwards, C. & Lambert, R., 2009, ‘Executing strategic change: Understanding the critical management elements that lead to success’, California Management Review 51(3), 49–73 (Spring 2009). https://doi.org/10.2307/41166493

Herman, B. & Siegelaub, J., 2009, ‘Is this really worth the effort? The need for a business case’, Paper presented at the PMI Global Congress, Orlando, FL, October.

Hornstein, H.A., 2015, ‘The integration of project management and organizational change management is now a necessity’, International Journal of Project Management 33(2), 291–298. https://doi.org/10.1016/j.ijproman.2014.08.005

IPMA, 2009, PM Baseline Version 3.0, IPMA - Projekt Management Austria, Austria.

ISACA, 2012, COBIT 5: Enabling processes, IL.

ITGI, 2008, Enterprise value governance of IT investments - the Val IT Framework 2.0 extract, viewed 13 January 2018, from https://www.isaca.org/…/Val-IT…/Val-IT-Framework-2.0-Extract-Jul-2008.

Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and communication technology project management’, Journal of African Business 15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641

Keen, J.M., 2011, Making technology investments profitable: ROI road map from business case to value realization, Wiley, Hoboken, NJ.

Larson, E.W. & Gray, C.F., 2014, Project management: The managerial process, International edition, 6th edn., McGraw-Hill Education, New York.

Maes, K., De Haes, S. & Van Grembergen, W., 2014, ‘The business case as an operational management instrument—A process view’, ISACA Journal 4, 29–36.

Marnewick, C., 2014, ‘The business case: The missing link between information technology benefits and organisational strategies’, Acta Commercii 1, article # 208.

Messner, W., 2013, Making the compelling business case, Palgrave Macmillan, Gordonsville, VA.

Meyer, W.G., 2014, ‘The effect of optimism bias on the decision to terminate failing projects’, Project Management Journal 45(4), 7–20. https://doi.org/10.1002/pmj.21435

Müller, R., Pemsel, S. & Shao, J., 2014, ‘Organizational enablers for governance and governmentality of projects: A literature review’, International Journal of Project Management 32(8), 1309–1320. https://doi.org/10.1016/j.ijproman.2014.03.007

Musawir, A.U., Serra, C.E.M., Zwikael, O. & Ali, I., 2017, ‘Project governance, benefit management, and project success: Towards a framework for supporting organizational strategy implementation’, International Journal of Project Management 35(8), 1658–1672. https://doi.org/10.1016/j.ijproman.2017.07.007

Nelson, R.R. & Morris, M., 2014, ‘IT project estimation: Contemporary practices and management guidelines’, MIS Quarterly Executive 13(1), 15–31.

OGC, 2009, Managing successful projects with PRINCE2, 5th edn., in A. Murray (ed.), TSO (The Stationery Office) on behalf of Office of Government Commerce, Norwich.

Peppard, J., Ward, J. & Daniel, E., 2007, ‘Managing the realization of business benefits from IT investments’, MIS Quarterly Executive 6(1), 1–11.

PMI, 2013, PMBOK - Guide to the project management body of knowledge, 5th edn., Project Management Institute, Pennsylvania, PA.

PMI, 2017, PMBOK - Guide to the project management body of knowledge, 6th edn., Project Management Institute, Pennsylvania, PA.

Ross, J. & Beath, C., 2002, ‘Beyond the business case: New approaches to IT investment’, MIT Sloane Management Review 43(2), 51–59.

Samset, K. & Volden, G.H., 2015, ‘Front-end definition of projects: Ten paradoxes and some reflections regarding project management and project governance’, International Journal of Project Management 34(2), 297–313. https://doi.org/10.1016/j.ijproman.2015.01.014

Sauer, C. & Reich, B.H., 2009, ‘Rethinking IT project management: Evidence of a new mindset and its implications’, International Journal of Project Management 27(2), 182–193. https://doi.org/10.1016/j.ijproman.2008.08.003

Silvius, A.J.G. & Schipper, R.P.J., 2014, ‘Sustainability in project management: A literature review and impact analysis’, Social Business 4(1), 63–96. https://doi.org/10.1362/204440814X13948909253866

Standish, 2014,. Chaos Report, viewed 01 February 2018, from https://www.projectsmart.co.uk/white-papers/chaos-report.pdf.

Thamhain, H., 2013, ‘Managing risks in complex projects’, Project Management Journal 44(2), 20–35. https://doi.org/10.1002/pmj.21325

Uzzafer, M., 2013, ‘A contingency estimation model for software projects’, International Journal of Project Management 31, 981–993. https://doi.org/10.1016/j.ijproman.2012.12.002

Vanhoucke, M., 2010, ‘On the dynamic use of project performance and schedule risk information during projecttracking’, Omega 39(4), 416–426. https://doi.org/10.1016/j.omega.2010.09.006

Vidal, L.-A., Marle, F. & Bocquet, J.-C., 2011, ‘Measuring project complexity using the analytic hierarchy process’, International Journal of Project Management 29(6), 718–727. https://doi.org/10.1016/j.ijproman.2010.07.005

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

Zwikael, O. & Smyrk, J., 2012, ‘A general framework for gauging the performance of initiatives to enhance organizational value’, British Journal of Management 23, S6–S22. https://doi.org/10.1111/j.1467-8551.2012.00823.x

Appendix 1

Tabulation of information types by category

The following tables give the detail of the business case information types required to create the business case, to plan the project and for project review.

Tables are created by review of papers with theme tags (see ‘Literature Review’ above) related to business case information. It is not possible to cite all references as some information types, like project risk, are covered in numerous papers.

The column ‘Source of Information’ indicates the people or documents from which information is obtained. Where ‘business case team’ is mentioned, it means the person(s) tasked with creating the business case. The column ‘Use of Information’ illustrates where information adds value during the processes.

Original Research

The business case thrives on relevant information

Carl Marnewick, Frank Einhorn

Abstract

Introduction

Research methodology

Literature review

Information technology or business projects and the business case

The business case processes

The research problem

The relationship between business case processes and information

Information required by the business case processes

Information to create the business case

Information, from project planning, used in business case processes

Information, for project review, used by business case processes

Mapping of ‘to create’ information, to business case content elements

Conclusions and the requirement for future research

Acknowledgements

Competing interests

Authors’ contribution

References

Appendix 1

Tabulation of information types by category