Business final task 12 hrs

Vincent666

GuidetoWritingaBusinessCasev2.pdf

Home >Business & Finance homework help >Business final task 12 hrs

MGT 173 Project Management – Health Services

2020

Guide to Writing a Business Case

BASED ON YOUR PROGRAM LOGIC MODEL, version 2.0

DR ROB FULLER, RADY SCHOOL OF MANAGEMENT, UC SAN DIEGO

Contents CHAPTER 1 Know how to make a case.......................................................................................................... 2

INTRODUCTION ......................................................................................................................................... 2

PROGRAM LOGIC MODEL ......................................................................................................................... 3

CHAPTER 2 Think It Through at a High Level................................................................................................. 4

IMPACT ...................................................................................................................................................... 4

FEASIBILITY ................................................................................................................................................ 5

CHAPTER 3 Clarify the Need, Focus on Results ............................................................................................. 6

OUTCOMES TO OUTPUTS ......................................................................................................................... 6

OUTPUTS TO PROCESSES .......................................................................................................................... 9

CHAPTER 4 Account for the risks ................................................................................................................ 13

RISK ANALYSIS ......................................................................................................................................... 13

CHAPTER 5 Estimate Resources and Costs ................................................................................................. 15

ACTIVITIES TO RESOURCES ..................................................................................................................... 15

COSTS ...................................................................................................................................................... 15

10 Steps to Write a Business Case .............................................................................................................. 18

Guide to Writing a Business Case CHAPTER 1 Know how to make a case

INTRODUCTION

An effective business case is a multi-purpose document that generates the support and

participation needed to turn an idea into reality. It explains what the idea, problem, or

opportunity is about, how and who it will impact, what others are doing in terms of the

alternatives or substitutes currently available, the associated impacts, risks and cost/benefit of

the initiative, and makes recommendations for implementation. No matter where you work or

what type of idea you’re pitching, you should follow the same basic process for any business

case you develop. I’ll briefly outline it here to give you a sense of the whole before delving into

the individual steps in later chapters.

First, you need to think through the project at a high level. Imagine you are in a hot-air balloon

soaring over the landscape at an altitude of 10,000 feet. When you look down, you can see the

prominent features such as roads, houses, cars and even people. But because of the altitude,

you may not be able to make out details like faces on the people or even the make or model of

the cars. As a tradeoff, however, you will be able to see the relationships between things like

roads and buildings better than you can on the ground. You can see which roads connect,

which houses can be reached by multiple routes.

So, when thinking through your project, look at it from the perspective of 10,000 feet. What

are the relationships of the prominent features? How are things connected? This will allow

you to identify the impact of the project and its potential outcome or results. Is it feasible?

Given today’s technology and science, is it physically possible? Is there an economically realistic

solution that investors or stakeholders will support? A program logic model is often useful for

illustrating these relationships.

Next, you must clarify the need for the project. Why are you proposing this project? What is

the need or opportunity your project will address. Any initiative that will have a significant

impact on the way things are done or the delivery of services to clients, particularly if it requires

significant allocation or reallocation of resources, should be justified by means of a business

case. In order to achieve the health determinant outcome that you have identified, what

outputs will the project have to create first?

Then, you will need to estimate the amount and cost of resources you will need. Resources can

be machines or buildings, people on your team, or even information that is essential to your

project. You should also be thinking about risks the project will face. How can you either

mitigate, avoid or transfer those risks?

Finally, after you have identified the resources you need, you will cost out all the resources and

identify how much money you need – in other words, a budget.

PROGRAM LOGIC MODEL A program logic model (PLM) is a visual method of presenting an idea. It offers a way to

describe and share an understanding of relationships (or connections) among elements

necessary to plan and operate a program. The purpose of a logic model is to provide

stakeholders with a road map describing the sequence of related events connecting the need

for the planned program with the program’s desired results. Mapping a proposed program

helps you visualize and understand how human and financial investments can contribute to

achieving your intended program goals and can lead to program improvements. The logic

model describes a bounded project or initiative: both what is planned and what results are

expected. It provides a clear road map to a specified end. The development of a model provides

an opportunity to review the strength of connection between activities and outcomes. Through

the experience of critical review and development, a model can display your learning about

what works under what conditions. The PLM complements systems thinking as a tool and

technique for achieving valid but simplified representations of real-world complexities.

Common synonyms for logic models include idea maps, frameworks, rich pictures, action,

results or strategy maps, and mental models. For our purposes, the PLM contains these

elements:

Or:

Resources

(Inputs)

Activities

(Processes)

Outputs

(Results) Outcome(s) Impact

Impact

Outcome(s)

Results

Activities

Resources

But it may be displayed in different ways, such as:

CHAPTER 2 Think It Through at a High Level

IMPACT Impacts in the PLM are organizational, community, and/or system level changes expected to

result from program activities, which might include improved conditions, increased capacity,

and/or changes in the policy arena. Really major value ideas are those that are highly impactful

and highly feasible. Looking at impact there are three concepts that can help us distinguish

high impact ideas: a very strong customer situation, an excellent value proposition, and the

existence of substitutes or alternatives.

1. Customer. Even though we think of them as a group, customers are individual human

beings who do real things and need your offering to do them better. A high impact idea

has a well-defined customer that you can identify and talk about as a person. It should

be clear who the customer is and who the customer isn’t. The customer is reachable in

sufficient numbers to make the venture sustainable and as appropriate, scalable.

Among the customers, you have articulated the user/beneficiary and the buyer/decision

maker, if they are different people.

2. Value proposition. The idea, the product or service you are proposing, improves the

customer’s well-being by solving a big problem or creating a significant opportunity for

them. In other words, it creates value for the identified customer. The way in which it

does so is at the same time distinctive, measurable, and sustainable. The concept needs

to succinctly state the value proposition in a way that people can easily understand and

support it.

3. Substitutes/alternatives. If your idea solves a truly a big problem, it probably has

competitors. In other words, people are solving the problem in some way. It may be a

direct competitor or an indirect competitor. Substitutes are offerings in different forms

that have the same functionality, e.g. coffee, coca cola, and energy drinks are all

substitute offerings for someone seeking “a boost” when tired. They are usually direct

competitors. Indirect competitors may take the form of an alternative. Alternatives are

offerings with different functions that serve the same purpose, e.g. taking a nap is an

alternative to the offerings mentioned above. The ideal situation for a really big value

idea is that any substitutes and alternatives are few in number, or your value

proposition is unique among them in its potential to improve the customer’s well-being.

The customer benefits of an idea derive from its impact. In the program logic model (PLM) the

impact is the result the program outcomes. Outcomes are specific changes in attitudes,

behaviors, knowledge, skills, status, or level of functioning expected to result from program

activities and which are most often expressed at an individual level. The business case needs to

describe the mechanism(s) that translate outcomes into impact.

FEASIBILITY Feasibility refers to the likelihood that your idea can really be created. An excellent offering is

essential but not sufficient for ensuring your idea is feasible. Your offering is the product,

service, or experience (or mix thereof) you are proposing as the way you propose to create

value for your customer. It can be offered in a way that meets stated financial goals:

profitability; self-sustainability; or supported sustainability.

A feasible idea also relies on two other elements. First, a big value idea is supported by a strong

team of people. Your idea must demonstrate that the members of the team you identify have

relevant specific skills and experience or inspire confidence that these can be gained in a timely

fashion. The values, vision, mission, and strategic goals of the team and/or organization inspire

and fits with Individuals on the team.

Second, feasibility is greatly strengthened by a distinctive competency. A distinctive

competency is a capability you or your organization possesses that is hard for others to imitate,

is different from (or at least very rare among) the capabilities of substitute or alternative

offerings and is easily recognized by or visible to the customer as being superior to other

available offerings in the ability to improve his or her well-being. Distinctive competencies are

the most desirable. Core competencies are next - they are central to the value creation process

but not as distinctive among substitutes and alternatives. And common competencies provide

little advantage because everyone’s got them.

CHAPTER 3 Clarify the Need, Focus on Results

OUTCOMES TO OUTPUTS You can’t brainstorm solutions, propose a team, or crunch the numbers until the clinical and business

need is crystal clear. A comprehensive business case conveys the mission and objectives of the program

being proposed, and a great deal more. It covers all the components of the program, including its

intended effects or results. One way to think through your project is to try thinking of it as a pain point:

what keeps your beneficiaries up at night? Of course, some projects are driven by opportunities, not

urgent problems. You may identify the pain point or opportunity yourself—maybe you have an idea

about how to remedy a faulty process or make a process more efficient; maybe you have seen a failure

in action. But more often a stakeholder (beneficiary or customer for example) will hand you a problem.

They (or secondary research) will point out a failure of a system and say, “this needs to be fixed,” or

point to an opportunity and say, “Check this out.” Either way, research the business and clinical need so

you have a thorough understanding of it.

A useful way to organize the program description is to include the following information:

• Need. This section describes the problem or opportunity that the program is intended to

address. It presents a rationale for the existence of the program. The more thoroughly and

accurately the need for the program is described, the better. This section should leave no doubt

that the program needs to exist to respond to a real and significant problem or an important

opportunity.

Business Need—Opportunity/Problem Statement

The purpose of this section is to establish a sense of urgency for the opportunity or solution.

o Projects are initiated to solve problems or take advantage of opportunities. Describe why

you’re proposing the project—what is the business need?

o Articulate your understanding of the underlying issue(s) using data and analysis. If your

stakeholders don’t understand or don’t agree with your articulation of the problem, they’re

going to take issue with everything else in your business case. See the ABC MedTech Case

for an example of a business need analysis.

o Share data that conveys urgency.

In addition to the problem/opportunity statement you will need to lay out the clinical and/or

business objective(s) for the project. Explain how the project is connected to your company’s

objectives as outlined in the mission and goals.

o Explicitly connect the need to the company’s strategic goals or mission.

o What is the desired measurable outcome of this project? What outputs are required to

achieve this outcome?

o Whenever possible, list specific concrete (Specific Measurable Action-oriented Realistic

Time-bound) goals.

o Describe the situation in enough detail that it is clear to the reader why the project

objective(s) are desirable.

• Expected effects or desired results. This section describes what the program is expected to

accomplish. It is where the program’s mission and objectives are stated. Expected effects or

desired results should be described in terms of outputs. These will be based on the projected

impact and feasibility of the program. For most programs, effects or results will unfold over

time, and this progression should be addressed in this section. For example, expected short-,

middle-, and long-term effects or desired results can be described.

This is a good place to provide a Project Overview. The purpose of the project overview is to

help stakeholders understand the scope of your proposed project.

o Provide a high-level description of the solution(s), shown in terms of the needs (from the

previous section) that your solution will address.

o If it’s a new product or an upgrade to an existing product, lay out the general concept, and

explain how it fits in with existing offerings.

o For a productivity initiative (such as an IT project that allows a customer to handle a

situation faster), specify which business processes it will affect, and which costs it will

eliminate or reduce.

o If you’re including more than one option, highlight key differences so that stakeholders can

quickly compare. You should include a brief overview of the substitutes or alternatives that

were considered that could have also addressed the need, and why your recommended

solution is better.

• Context. This section describes the larger environment in which the program will exist. Because

the most important contextual variable is often the host organization in which the program is

embedded (if true), the description should include information about the host organization and

the program’s relationship to it. If it isn’t part of a host organization, the organization structure

should be detailed. In addition, numerous other environmental or contextual variables are

relevant. These include public policies relevant to the program, such as those having to do with

Medicare or Medicaid, health regulations, as well as general social and economic conditions that

might affect the program, demographics of the program’s service area, target markets and

target audiences, the public- and private-sector funding environment of the program, what

competitor programs (substitutes and alternatives) are doing or planning, and perhaps relevant

aspects of the history of the program or the need.

Critical Assumptions and Constraints

o Assumptions are those things that you believe are true today. They are not things you wish

were true or hope are true. They must be based on sound reasoning or judgment.

o Constraints are those things that constrain the project or hold it back. Most projects are

constrained by time, money, and people, but you can also have other constraints such as

facilities, equipment, strict quality requirements, government regulations, etc.

Talk to Beneficiaries and other Stakeholders

Ask the people who use the current system what they think is going on: When did the problem start?

How does it manifest itself? How often? Does the problem prevent them from receiving all the benefits

they expect? As you talk to people gather relevant data, reports, surveys—whatever evidence you can

access.

If possible, observe the issue firsthand. Your job is to listen and probe further. The beneficiaries may

not know the underlying reason for the problem. It is up to you to discover the cause and identify a

reasonable solution.

The beneficiaries may have a solution in mind. But sometimes what they want isn’t the best fix.

Certainly, you need to look at this option, but it might not be your final choice, especially if it is costly or

difficult to implement.

Some questions that might guide your discussions with beneficiaries:

• Where will the solution be used? In an office, in a clinic, in the field? In what country or

countries?

• Who will be affected by the solution? Individuals or organizations? A single department or the

entire organization?

• How quickly does the solution need to be in place? Can you roll it out over time, or must it be

all at once?

• How should the solution’s effectiveness be measured?

• Is this a stand-alone initiative, or should it be combined with another initiative or on-going

program?

Stakeholders and beneficiaries may not have the answers to all these questions, but they form the

basis for a very informative discussion.

Document, document, document

Record everything you learn: where the pain comes from, who’s experiencing it, and what the solution

needs to accomplish. This will save you a lot of time later as you prepare your final business case –

stakeholders will want to see what you’re basing your project on.

This documentation process can be as straightforward as jotting down notes or entering them in an

Excel or Word file. Use each section of the Program Logic Model (Outputs, Activities, Resources) as a

tool to organize your thoughts. Many companies use a project management system (like Microsoft

Project) to keep track of the development of new projects. Keep track of what you’re told. That way,

you can go back for clarification in the likely event that you receive conflicting or partial information

from beneficiaries. This will also help you refer stakeholder’s questions to the right people.

After doing all this work, what if you find out the business need isn’t strong? That’s OK. You’re still

helping your stakeholders make an informed decision about whether to invest, and how much. Even if

the return isn’t as impressive as you originally thought it would be, talk with your stakeholders about

whether it makes sense to proceed. In some cases, stakeholders will still want to go ahead if the new

project brings some non-monetary benefits.

Sitting on the review committee at a medical device company, we saw many projects that didn’t

immediately deliver huge revenues or cost savings. Still, they had to get done—sometimes to comply

with new FDA guidelines, sometimes to address concerns of key hospitals or doctors and gain their

support for new products.

Forego precision—and push beyond the obvious

Work quickly at this stage. You aren’t drafting project plans or identifying specific vendors or product

names. Instead, you’re coming up with a generic system, initiative, or product to recommend. Don’t

get hung up on particulars. If you find yourself laying out specifications for a solution, pull them back to

the big picture. This is an appropriate time to begin building your Work Breakdown Structure (WBS).

The WBS is a deliverable-oriented grouping of the work involved in a project that defines the total

scope of the project. The WBS is a document that breaks all the work (100%) required for the project

into discrete deliverables, and groups those deliverables into a logical hierarchy.

You’ll gather basic specifications later, after you’ve narrowed down your options and begun assessing

them. Once you have received approval for your project, you’ll have time to sort out the nitty-gritty

details in a project plan. The goal right now is to sketch out several directions you might take, not to

pave the actual path.

If you are struggling to come up with other options, try these techniques to broaden your perspective:

• Start with the desired end state. How have other types of businesses achieved the performance

you are aiming for (faster time to market or improved quality). Would those approaches work

for your project?

• Think about how individual departments would address the issue. What would the project look

like if IT took the lead? How about Sales? Engineering? Supply chain? Often, we get hung up

based on our perspective of the issue and can benefit from a new perspective.

• Consider how you could accomplish the project with different constraints. What if you had

twice the time to complete the project? Or half the time? What would change if you had to

scale the solution to do the same thing by 100 times?

Narrow down your possibilities

When I review business cases, I don’t like being given a case where it is obvious that only one option was

considered and am being told that is the way it must be done. Nor do I want to see 25 alternatives.

Don’t offer an obviously unacceptable solution in contrast to your preferred choice. It will appear that

you are trying to manipulate the reviewers. The idea is to tell a credible story rather than a one-sided

one.

Sometimes one option will stand out as a clear winner. So, you’ll present it to the reviewers, but also

share other options you considered. If you looked at three alternatives but immediately saw that two

would generate no revenue growth, or they’d cost too much, or there would be compliance problems,

explain that in your business case. Stakeholders expect to see which viable choices you rejected and on

what grounds.

OUTPUTS TO PROCESSES To build a compelling case, you’ll need to paint a picture—in very broad strokes—of how the

organization would implement the solution you’re proposing. You not doing a detailed project plan at

this point. You are just sketching the basic outline of what the project will take so your estimates of

costs and benefits will be realistic.

Another area to consider is transition costs, which are easy to overlook. It is easy to get so excited about

your solution that you forget that you’ll need to help organizations stop doing things the “old” way to

implement your pet solution. Where will major costs be incurred before, during and after a switch?

What, and who, will the actual switch involve? What training will employees need? Will you roll out the

new solution organization-wide, or multiple times for different customers, departments or locations?

Make sure you’ve integrated beneficiaries’ perspective, so you’ll have their buy in when it’s time for

them to accept the project.

Make the plan feasible

Don’t go too far into the weeds. You’re still not at the point where you need a detailed project plan.

But you’ll want to figure out, for instance, whether you’ll use the new project in one country or three.

You can think later about which country you’ll do first, and so on, depending on what’s happening in

those markets. For now, just knowing the “where” at a high level will help you think about what kind of

work will go into getting the project ready (translating it into a new language, testing it with user groups

in each country, that kind of thing). You are not sorting out every task—just the types of tasks and the

resources involved.

When you have outlined the WBS, you can easily translate Outputs (which we can call Deliverables) into

the Activities (also called Processes) required to create that deliverable.

Example: Imagine the WBS looks like this:

Birthday Cake

Cake

Flour

Eggs

Oil

Baking Powder

Cocoa

Frosting

Powdered Sugar

Heavy Cream

Water

Vanilla

Toppings

Chocolate Sprinkles

Chocolate Shavings

Candles

Candle Holders

Numeric Candles

How would we convert the deliverables into activities? First, each of the outputs, which are shown as

second level deliverables on the WBS (cake, frosting, toppings, candles) require ingredients. So, one of

the activities would be to acquire those ingredients. Maybe that activity would be called “shopping.”

Once you have the ingredients, you need to combine them for the cake. So, another activity would be

“mixing.” Then “baking” and “icing” using the frosting. “Decorating” might be another activity that

would incorporate icing, but also adding the toppings and candles. The level of detail that you go into

depends on the audience for your business case.

This process of translating an outcome (“birthday cake”) into outputs (“cake”, “frosting”, “toppings”,

and “candles”) then to activities (or “processes”) mirrors the Program Logic Model process. Once you

have identified the activities required, you will be able to look at two more elements: resources (those

things required to make the activities happen) and risks (what could go wrong if we proceed with this

project).

Schedule

Once you have the WBS developed, you can lay out a high-level plan for implementing the project. The

key here is “high-level.” At this stage it is fine to make rough top-down estimates of the time required

for each process or activity that goes into creating a deliverable you have included in the WBS. To do

that, the following guidelines may help:

o Have people familiar with the tasks/activities/processes help you make the estimate.

o Use several people to make estimates.

o Base estimates on normal conditions, efficient methods, and a normal level of resources.

o Use consistent time units in estimating task times.

o Treat each task as independent, don’t aggregate.

o Don’t make allowances for contingencies (yet!).

Adding a risk assessment helps avoid surprises to stakeholders. There are almost always risks to a

project schedule. You can include them in your “Risks” section.

Explain how long the project will take (months, quarters or even years) and list all key milestones or

major deliverables. Be sure to include all deliverables from the Work Breakdown Structure (WBS).

Remember to include dependencies in your schedule. For example, you cannot put icing on the cake

until you first bake (and cool!) the cake. In other words, icing is dependent on first baking the cake.

Impact

This section highlights the benefits of the project.

• Describe the benefits. Benefits mainly consist of revenue and productivity savings (benefits

you’ll achieve through greater efficiency) but may also be from cost avoidance (such as

decreased healthcare costs).

• In this section, you only present the benefits. You’ll address costs in the Budget section

described below.

• Do not only include benefits that you can quantify. Define the impact as precisely as you can

(customer, value proposition, lack of substitutes/alternatives). You may mention intangible

benefits, such as improved morale or increased customer satisfaction, but stakeholders will

want to know the monetary impact, too.

• Be clear about where these numbers come from—did you get them from secondary research or

primary research? State the source. Stakeholders care about the sources for these assumptions

and are more likely to trust your numbers if the information comes from people/organizations

they trust.

Benefits mainly consist of revenue (money you bring in through sales or grants) and productivity savings

(costs you’ll avoid through greater efficiency). Revenues are a challenge to estimate. This is an area

where an outside subject matter expert can be very helpful. They can help you set realistic targets, both

how much to expect and when to expect it.

Productivity savings usually come from cutting current, ongoing expenses that stem from how you run

the business. Make sure that if you are claiming cost savings as a positive impact that you are actually

saving money, and not just moving expenses around to other parts of the organization. You might be

able to cut other types of operating expenses: eliminate the need for overtime or reduce costly errors by

giving people more time to focus on their tasks.

CHAPTER 4 Account for the risks The purpose of this section is to highlight the key risks to the project. Here you will explain what might

not go as planned—whether positive or negative. Most people focus on threats (e.g., What if the vendor

doesn’t deliver on time? What if the cost of raw materials goes through the roof?). But you need to

consider opportunities as well (How can you get a faster payback? Can you complete the project

sooner?).

If there are no major risks, say so. But make clear that you’ve thought through the possibilities! The

primary risks you’ll want to consider are to costs and schedule. But you may also want to think about

the following:

• Personnel: What if the person running this project leaves the company? What if you don’t get

all the team members you requested?

• Technology: What if you encounter bugs when testing? What if employees struggle to adapt to

the new system?

• Scope: What if the project needs to include more (or fewer) geographic regions, employees, or

customers? What if the stakeholders change requirements?

• Quality/performance: What if the product or solution doesn’t perform as you expect it to—for

better or worse? What if quality suffers because of a tight schedule?

RISK ANALYSIS Identification

Once you have identified the activities that will be required for the project, you need to look at each

activity and ask yourself: “What could go wrong if we attempt this activity?” Each area may have several

risks associated with it. The funding area, for example, may contain risks involving loss of core funding,

loss of a significant grant or contract, or past due payments. Each of these are valid risks, but some are

more important to the project than others. Once you have identified all the risks for your organization

or project, you can review the list to remove any overlaps and to make sure it covers all the important

risk areas.

Risk assessment

Risk assessment involves rating each risk against two dimensions: probability (or likelihood that it will

occur) and impact (or severity of the problem if it occurs).

The ‘probability’ aspect of risk assessment involves deciding how likely it is that the risk will occur. Each

risk can be divided into one of three categories (low, medium, high). An example involving the

frequency of a risk that occurs over time might be:

• high probability: the risk might occur once every one to two years

• medium probability: the risk might occur once every three to five years

• low probability: the risk might occur less frequently than once in five years.

Some organizations use a system of probability assessment that involves categorizing risks on a scale of

1 to 5, where 1 is the lowest possible likelihood and 5 is the highest possible likelihood. A great exercise

is to create a Risk Impact Scale, that identifies what each number would translate to for a given type of

risk.

The ‘impact’ aspect of risk assessment involves considering what the potential impact of the risk would

be on the organization, client or project. Each risk should be categorized in terms of impact or severity in

the same way the risk was assigned a ‘probability’ rating. An example of severity assessment might be

to use our same three categories (low, medium, high). Each risk would fall into one of three categories:

• high impact: the organization might be forced to terminate activities because of a catastrophic

failure or occurrence defined by the risk

• medium impact: the organization would continue but the risk will have significantly affected its

performance, timescales or costs

• low impact: the impact would be small and easily managed at a relatively routine level within

the organization.

After you have categorized your project’s risks according to probability and impact, you need to decide

which risks are worth creating a mitigation plan for, and which you are willing to accept.

To create a risk statement, you can use an “if” (eventuality) and “then” (consequences) statement. You

can also apply the value for Probability (P) and Impact (I) that you have derived. Examples might look

like:

P I

If…the service is more frequent than predicted, H

Then…we have increased downtime

P I

If…the operator training is not available as

promised,

Then…we must hire temporary operators

A Risk Severity Matrix (a color coded two-dimensional matrix showing Probability on one axis and

Impact (Severity) on the other axis) is a tool that will aid in the decision to mitigate, accept or even

transfer a risk. See the Session 10 slide deck for an expanded view of risk analysis—identification,

assessment, elaboration.

CHAPTER 5 Estimate Resources and Costs

ACTIVITIES TO RESOURCES Once you have used the WBS to derive the activities or processes that will be required to generate the

outputs or major deliverables you have identified, now is the time to go back to the WBS to begin to

identify the resources or inputs that you will need for each activity/process. In our earlier example of

the WBS for the Birthday Cake, we saw that the major deliverables or outputs were the cake, frosting,

toppings and candles. Each of those major deliverables is made up of sub-deliverables. For example,

‘cake’ is made up of flour, eggs, oil, baking powder, and cocoa. Those are resources. In addition, you

would also need an oven (equipment), cooking utensils (technology), a kitchen (facility), and a baker

(team member) as other resources. You could do the same with each of the other outputs.

Team

Identify the team required to make the project a success.

List the total number of necessary full-time equivalent employees (FTEs) and core team members (by

function). Convert part-time employees’ time to full-time equivalents (~40 hours/week=full-time).

Include subject matter experts (SMEs) who will need to contribute to the project. They may be

consultants or contractors rather than team members. Contractors are defined as vendors who work on

the project as part of the team. Consultants are vendors who work on the project on an as-needed

basis.

Other Resources

In addition to the team, identify all material resources the project will need.

• Explain all resources required—technology, equipment, facilities—required for the project.

• Outline any special resources required—such as access to locations, etc.

• Whenever possible, include how long you’ll need the resources for (and be sure to account for

any costs in your calculations).

COSTS In order to determine the return on investment (ROI) or whether this project is worth doing, you’ll need

a projection of costs as well as benefits. For many people (especially nontechnical folks), working with

these numbers can be intimidating. But if you have identified and clarified the business need and

impact, this won’t be hard.

Cost estimates are based on the resources you have identified. Once you have identified the resources

needed for your project (team, technology, equipment and facilities) put a cost to each one. This may

take some research, but it will also take some common sense. If you need a medical caregiver on your

team, for example, you need to decide if you will need her/him full-time or part-time. Once you know

what percentage of full-time, you need to determine how much experience you require. A new resident

will cost less than an experienced board-certified specialist, but residents will also require at least one

attending physician. Instead of a lower skilled physician, could you use a Physician’s Assistant or Nurse

Practitioner instead? These decisions will help you determine whether your caregiver will cost you

$150,000 per year or $300,000 per year.

You also need to determine whether you will buy or rent/lease your resources. This is a common

decision for facilities but may also apply to equipment or technology.

You need to include two main types of costs. The first type, project costs, consists of project and capital

expenditures. Project expenditures usually occur at the beginning of a project. They tend to include

development, testing and qualification, training and deployment, and travel costs. They’re pretty

straightforward to estimate—consider the type of work to be done on the project and approximately

how long it will take, then put together your estimate for completing that work.

The second type of costs, operating costs, can be tricky because you’re estimating how much money it

will take to maintain whatever you’re proposing. These include overhead: personnel, office space,

maintenance, licensing fees, and any other ongoing expenses.

Many managers overlook transition costs, the type of operating expense that kicks in when the

organization switches from something old to something new. Most major projects will cause some

disruption, and you need to account for it in your estimates.

Where to get the numbers

As you have probably gathered, you’re not making up these estimates alone in your room. You need to

reach out to beneficiaries and experts to get accurate information. Some of the numbers can be found

on the internet or other references. No matter what the source, don’t take the numbers at face value.

Make sure you know what assumptions the numbers are based on. Almost all estimates are based on

biases and understanding what those are can help you get the most accurate, balanced numbers

possible.

If you get a range of values for one of your estimates, that signals a project risk. Select the value that

you believe is the most realistic but include this as one of your risks in your risk assessment.

10 Steps to Write a Business Case

STEP 1

Identify a personal, social, economic or environmental problem that influences health. These are health

determinant problems.

STEP 2

Calculate the impact (or benefits) and feasibility (practicality or workability) of solving the problem. If we

can maximize the impact and the feasibility, we call this a “big problem.” That is, one worth solving.

STEP 3

Define a project that results in a solution or significant improvement to the problem identified. This is

called the Outcome.

STEP 4

Develop a Work Breakdown Structure (WBS) of the outputs or deliverables required.

STEP 5

Break each output or deliverable down to the activities or processes necessary to complete the

deliverables you have identified.

STEP 6

Create a time-phased schedule to complete all of the activities identified in the logical order necessary.

You may recognize there are some activities that cannot be completed until others have been done.

These are called dependencies.

STEP 7

Account for the risks associated with the deliverables and/or activities you have identified. Create a plan

to either eliminate, mitigate, transfer or accept each of the risks.

STEP 8

Identify the resources required for your project, based on the time-phased schedule you have created.

STEP 9

Calculate the budget required for the resources, activities and deliverables identified in your model.

Write a budget narrative that explains where each of the numbers on your budget comes from.

STEP 10

Convert your program logic model components into sections of the business case. Connect the sections

and assemble into the correct format.