2

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 1/8

2.4 Module 4: Building the Business Case by Levels Fitting the tool to the circumstances

Module 4—Objectives Discuss and explain that business case detail should be tailored according to potential impact to the business

Building by Levels

The nature of requirements

Foundational and strategic requirements come from the strategic plan and the balanced scorecard

Situational, customer-driven requirements are only revealed in the course of the project, and are therefore fuzzy for planning purposes

Getting Started on the Business Case To get started on the right path, answer these framing questions succinctly:

What is it that brings us all to the table to discuss a new project?

What is envisioned as the project’s mission and scope?

How will the enterprise and the customer constituencies be better off if the project is successful?

How will the end state be changed or what goal will be reached?

Add some detail where necessary for understanding and context:

Background and context: Describe what has led up to the opportunity at hand. A review of relevant historical performance is a helpful background. Current operating results are always welcome—examples: functional performance and process metrics, end-user evaluations and other voice-of-the-customer input, warranty or trouble reports, audit reports from across the balanced scorecard, supply chain metrics, and lessons learned from the relevant history of other projects.

The project proposal: Lay out both sides of the project balance sheet. Present the business description of the whole value proposition: outcomes, expected bene�its, quality �it, available investment, milestones with business importance, and customer needs. Describe the balance sheet project at a high level: scope, quality, cost, and schedule. The solution need not be too prescriptive but it has to be just enough to be credible. Identify any gaps necessary to balance the left side—include mitigations, if known.

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 2/8

Operational results: Propose a concept of operations to describe who does what, day-to-day, in post-project operations with the deliverables. If there are KPIs, list and explain them.

Business preparation: Address business preparation needs that lead up to operations. Any reasonably sized project will require proactive change management and executive buy in; training for users, support staff, and maintainers; sales and marketing plans; rollout and market adoption strategy; beta trials; legacy retirement; and supply chain readiness, among other readiness needs.

Ask for approval: Last, and perhaps most important, ask for an approval decision. An approved case is the project charter and authority to proceed.

Level 0, 1, and 2 Business Case The business case hierarchy is a three-level pyramid as shown pictorially in Figure 2.5 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#�ig2-5) —stacked, not by accuracy of the estimates, but by their impact to the enterprise.

Level 0 attributes:

The Level 0 business case is driven by a backlog of requirements developed either by the end user, customers, or system operators and maintainers. The backlog requires prioritization by a Level 0 governance process and must �it within a Level 0 funding limitation.

Items from the backlog need not be just bug �ixes, warranty repairs, or other trouble �ixes. Requirements could represent new features and functions, but at Level 0, their scope is limited in this way: new functionality or features approved at Level 0 do not materially alter the relationship with the supply chain, customer or user constituents, or other commitments and certi�ications that may have the force of contracts, compliance, and regulations.

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 3/8

Figure 2.5 Business case pyramid

Level 0 is typically approved by simple work�low at a �irst or second level of management. Level 0 requirements �it within the context of existing systems, processes, and business models.

Level 1 attributes:

The Level 1 business case is a step-up in complexity; not only of the solution, but also of the impact to the organization, its end users and customers, and perhaps to its regulators, suppliers, and other third-party associates.

There may be, and usually is, more than one business unit involved, thereby complicating the work�low for approval.

There may have to be approvals from outside auditors, regulators, and certi�ication authorities; supply chain units may need to consult. Technical feasibility may be in doubt. Business-to- business testing and certi�ication of both process and technology may be required.

Opportunities at Level 1 �it these limitations:

They are not bet-the-business in scope.

They do not materially alter the business model or the business values.

They do not cannibalize other business units.

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 4/8

In effect, at Level 1, projects are not a game-changer for the business. Level 2 attributes:

The Level 2 business case addresses opportunities of such scope that a project might threaten the business’s survival if it is not successful— Level 2 projects are business game changers.

At Level 2, opportunities may go so far as to introduce a new business model, alter culture in some material way, and affect relationships across a broad landscape.

Level 2 business cases are nearly always approved at the C level or by the governing board of the enterprise.

Building the Level 0 Business Case Level 0 is a �ill-in-the-form exercise. The information typically provided is given in Table 2.8 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#tab2-8) and is taken from the checklist in Table 2.7 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#tab2-7) . In the best of cases, the form is web-based and operates with a database. Work�low provides a means for managers to review the business case, attach comments, and render an approval. Sometimes only one approval is required.

Building the Level 1 Business Case Level 1 is a step up in impact from Level 0. Level 1 usually commands more resources, both in funds and in staff, but also perhaps in tools, environment, and support. The simple form for Level 0 is expanded to encompass Level 1 complexities. These may include impacts on the supply chain, customer or user constituents, or other commitments and certi�ications that may have the force of contracts, compliance, and regulation. These matters are consequential and require serious consideration and commitment by responsible managers.

Level 1 may affect variable compensation plans, pro�it and loss (P&L) commitments, and have balance sheet impacts that affect the capital structure of the business. Such impacts may draw in human resources and capital managers.

Table 2.9 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#tab2-9) is an extension of Table 2.8 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#tab2-8) .

Building the Level 2 Business Case The Level 2 business case handles all the situations that are not within the scope and authority of Level 0 and Level 1. The protocol for approval invariably involves the executive staff.

Table 2.7 Checklist of business case content

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 5/8

Level 2 projects are projects of scale—one small team rarely executes them. Large scale does not rule out agile methods; however, scale complicates all management and technical parameters, disproportionately adding risk. Chapter 11 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/secchapter011#secchapter011) addresses how to scale agile methods.

Table 2.10 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#tab2-10) is an extension of Table 2.9 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch45#tab2-9) .

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 6/8

Module 4—Discussion for Critical Thinking Can you imagine doing a project funded by other people’s money without �irst stabilizing the

conceptual objective and value proposition in a business case—no matter how informal the presentation of the business case to sponsors?

Table 2.8 Level 0 business case

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 7/8

Table 2.9 Level 1 business case—additions to level 0

12/15/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch45&content=content&clientToken=97f4e541-bb1f-8f09-62a6-e603f01e71ca&np=ch45 8/8

Table 2.10 Level 2 business case—addition to level 1