Business cases justify investment of capital, resources, and time for the delivery of something new or change (see Figure 7.1). They are a justification control mechanism for the project board with the potential to end a project or program lifecycle. Business cases are also a key information need of corporate and portfolio management as project or program benefits add value to the business of an organization and therefore its success and survival. In the context of projects or programs, the business case is essentially a tool to determine the viability of undertakings. In the context of the organization, the senior responsible owner (a term used by AXELOS) is responsible for initiating independent assurance reviews of business case viability (Brolsma and Kouwenhoven 2019). Based on the latter, corporate or portfolio management may intervene top-down and overrule that part of the project board, which represents corporate interests—a P3M process interface. In practice, the executive (who represents the company’s business case) then has to comply with such intervention. Note that the executive project role is one out of three PRINCE2 project board roles (next to senior user and senior supplier), but in reality project boards can be composed differently depending on stakeholder interests. It is no mystique that the business case of projects and programs needs to be tailored based on organizational needs. This is an exception in HybridP3M. Like explained in the Introduction, tailoring methods based on parameters like project characteristics is a mystique (or wishful thinking), but here tailoring is driven by company-specific requirements, often depending on financial systems. As a process, business case development comprises activities that add new information to the business case as a whole. It is a dynamic process as projects and programs unfold because assumptions need to be constantly tested, and in practice they change quite often. So the business case is dynamic. Note that the definition of the business case helps to define project or program success in the evaluation process. The contents proposed by HybridP3M are based on market knowledge and comply with our general understanding of business cases. The specific interpretation of the various elements however is unique to some extent.
Provide Background Information
A formal business case should always include background information, usually corresponding to the reasons or triggers behind the project or program. Essentially, background information captures the significance of a project or program in plain words, starting with the assessment of the general idea, including a description of its roots. Every project and program is rooted in an original idea, but it is not an assembly line. Furthermore, a statement on feasibility is required. For business case owners, background information also relates the project or program idea to the organizational core business. This means that the project or program should be aligned with corporate strategy. Background information should address the latter. Following Archibald’s (2004) classification of project-based organizations, either the project or program is a means to capitalize on capability (the primary business model of project-driven organizations) or supports other organizational goals (significant to project-dependent organizations).
Figure 7.1 Business case development PDD
Definition of the added value of the project or program stemming from expected outcomes is paramount for the business case. Without any objectively established, ideally measurable, defined added value, the business case looses its purpose. Added value provides the foundation for benefits management as from the description of added value benefits can be derived. In HybridP3M, it is important to distinguish between outcomes, capabilities, and benefits, an activity of realizing benefits. The quality of the described added value in the business case makes the latter activity easier in the context of the associated process strongly tied with business case development. It should be noted that the added value is not necessarily direct financial gain. There are plentiful of nonfinancial motives thinkable that are more of strategic and tactical nature. If, however, the link with economic benefits is poorly established, the corporate budgeting process may become an obstacle.
Identify Alternatives
Alternative in the context of a business case is ambiguous. An alternative may refer to an alternative project or program, competing from the same corporate pool of resources, with different outcomes but similarly, and importantly, aligned with corporate strategy. Or alternative may refer to the current conceptualized project or program with similar outcomes but a different approach. In case of the latter, input from project definition in the form of the project approach is essential. The chosen project approach co-shapes the business case. In identifying alternatives, both types of alternatives should be taken into account.
Calculate Return on Investment
There exists no more objective measure for the financial added value of projects than return on investment (ROI). The major limitation of using ROI, however, is that financial assumptions usually do not hold. Especially in case of complex situations and great uncertainty, the applicability of ROI is a utopia. It is up to corporate management or portfolio management to use this method as a reliable approach for business case evaluation. Hence, tailoring business case development may involve skipping this type of content. Arguably, ROI has more value in predictive situations as compared to agile.
Strategic Alignment
Strategic alignment involves as an activity mapping the project or program with corporate strategy as it is, and at the same time constructing a corporate strategy bottom-up within a framework of current capability (in a proactive manner). As vehicles of change thanks to anticipated and unexpected project outcomes, projects drive corporate strategy fueled by market dynamics and client engagement. A top-down, static strategy simply does not work well for project-based organizations. Therefore, the activity of strategic alignment involves selling projects or programs given the mission, vision, and blue park strategy thanks to eloquent business case development and individual leadership of key project members with decision-making authority.
Capture Risks
It is common knowledge that risks are part of a business case. The reason for this is that risk may jeopardize project outcomes as anticipated or expected. In other words, risk may lead to project failure in basic terms. The risk section of the business case is very dynamic and depends on feeds from risk management. How risks are embedded and described in a formal business case document, however, depends on corporate requirements. Risk management data can be very extensive and therefore may need to be compressed, summarized, or modified according to corporate business case needs.
Allocate Budget
The budget allocated for a project or program reflects expected costs related to overall investment. It is an important control mechanism in combination with budget tolerance. Every corporation has some kind of budgeting process interfacing with business case development in the context of starting up a project or later. While project approval is essentially a responsibility of the project board at the end of initiating a project, at least according to PRINCE2, actual approval in line with the budgeting process may be somewhere else in the organization at corporate or portfolio level. Hence, the link between business case development and corporate management is quite strong and evidence of integrated P3M. As stated in the Introduction, projects are never standalone. It should be noted, however, that fixed budgets have limitations in agile projects, that is, projects characterized by agile delivery. The scope in agile projects is simply too dynamic, and therefore, it is difficult to estimate the required investment. In case of predictive environments where budgets are more realistic, budget tolerance plays an important role in evaluating project success.
Set Timescales
Timescales should not be underestimated in the context of the business case. Timescales enable deadlines and a disciplined mindset. Just like budget, timescales are a control mechanism in combination with timescale tolerance. In case of predictive environments, efficiency thinking has positive impact on the time dimension. In case of agile environments, timescales support definition of stages (stage tolerance for allocated time) and help to control iterations based on priority thinking. On time completion of projects and programs is an indicator of success.
Interdependencies relevant in the context of business cases relate to a portfolio of projects and programs in which the success of one project or program depends on the success or performance of others. Dependency can be formed over a period of time as in sequential activity or relate to a fixed, particular, actual period of an evolving portfolio with diverse and simultaneous projects and programs. The most obvious interdependencies reside in the fact that available resources depend on overall allocation across a portfolio. As explained in Chapter 2, HybridP3M’s matrix approach optimizes resource usage thanks to a matrix project organization, in which one person can be member of multiple projects at the same time. This specific approach alleviates conflicting interdependencies. Other interdependencies depend more on actual project outcomes of other projects, representing a critical chain at a higher level of planning, namely that of the business case. With regard to external interdependencies, winning contracts is often critical. Another example are party obligations established in contracts.
Process Aspects
Figure 7.2 captures the knowledge nature of business case development.
Figure 7.2 Tacit–explicit continuum of business case development
While business case development assumes externalized knowledge captured in a standard format, the assessment of a business case depends on interpretation and tacit understanding. The explicit knowledge mainly serves as a tool in tacit understanding. What makes a good business case is rather a personal observation. Accordingly, a corporate standard helps to ensure consistency and rationalization but clearly has limitations. Gut feeling in the context of business case justification should not be underestimated.
Figure 7.3 captures the manageability of business case development.
Figure 7.3 Step-by-step process versus skilled activity continuum of business case development
Business case development is the best example of a step-by-step process in the context of project management. While it relies on tacit knowledge, it is not really a skilled activity from a process perspective. Understanding of the business case deliverable enables execution of business case development. However, the latter does not imply quality output or say anything about viability.
Figure 7.4 captures the specialization level of business case development.
Figure 7.4 Management–specialist continuum of business case development
Business case development is not a specialization. It is part of the project manager’s responsibility. The only nuance here is that the financial analyst is responsible for any financial assumptions, including the ROI analysis. Alternatively, the financial analyst from the matrix organization, positioned in a line function, is the one who tests the project manager’s financial assumptions.
Figure 7.5 captures IT support in relation to business case development.
Figure 7.5 Available IT support for business case development
Business case development does not rely on software. It mainly depends on a template according to corporate standards.
Figure 7.6 captures the complexity of business case development.
Figure 7.6 Task complexity scale of business case development
Business case development is neither very complex nor simple, but it is in the middle. As a template-driven process, it is perfectly clear what is expected. On the other hand, good business cases rely on experience and a wealth of knowledge.
MAIDEO Requirements
Table 7.1 presents MAIDEO requirements related to “business case development.”
Table 7.1 MAIDEO requirements related to business case development
Requirement |
Level |
Dimension |
Formal business cases are used for justification of projects and programs |
1 |
Organization and process |
Business cases address added value |
1 |
Organization and process |
Business cases identify alternatives |
2 |
Organization and process |
Business case includes financial assumptions such as return on investment |
2 |
Organization and process |
The business case holds information such as budget and time |
3 |
Organization and process |
The business case addresses risk |
3 |
Organization and process |
The business case addresses strategic alignment |
4 |
Organization and process |
The business case covers interdependencies such as project or program interfaces |
4 |
Organization and process |
The business case is used as a tool for strategic alignment |
5 |
Organization and process |
The business case is used effectively in the context of portfolio management |
5 |
Organization and process |