Project Selection – Case 1

A Project That Does Not Get Selected

Hygeia Travel Health is a Toronto-based health insurance company whose

clients are the insurers of foreign tourists to the United States and Canada. Its
project selection process is relatively straight forward. The project selection
committee, consisting of six executives, splits into two groups. One group
includes the CIO, along with the heads of operations and research and
development, and it analyzes the costs of every project. The other group consists
of the two chief marketing officers and the head of business development, and
they analyze the expected benefits. The groups are permanent, and to stay
objective, they don’t discuss a project until both sides have evaluated it. The
results are then shared, both on a spreadsheet and in conversation. Projects are
then approved, passed over, or tabled for future consideration.
In 2000, the marketing department proposed purchasing a claims database filled
with detailed information on the costs of treating different conditions at different
facilities. Hygeia was to use this information to estimate how much money
insurance providers were likely to owe on a given claim if a patient was treated at
a certain hospital as opposed to any other. For example, a 45-year-old man
suffering from a heart attack may accrue $5,000 in treatment at hospital A, but
only $4,000 at hospital B. This information would allow Hygeia to recommend the
cheaper hospital to a customer. That would save the customer money and help
differentiate Hygeia from its competitors.

The benefits team used the same three-meeting process to discuss all the
possible benefits of implementing the claims database. Members of the team
talked to customers and made a projection using Hygeia’s past experience and
expectations about future business trends. The verdict: the benefits team
projected a revenue increase of $210,000. Client retention would rise by 2% and
overall profits would increase by 0.25%.
The costs team, meanwhile, came up with large estimates: $250,000 annually
to purchase the database and an additional $71,000 worth of internal time to
make the information useable. Put it all together and it was a financial loss of
$111,000 in the first year.
The project still could have been good for marketing-maybe even good enough
to make the loss acceptable. But some of Hygeia’s clients were also in the claims
information business and therefore potential competitors. This, combined with the
financial loss, was enough to make the company reject the project.

Source: “Two Teams Are Better Than One” CIO Magazine, July 2001 by Ben
Worthen.

1
 Project Selection – Case 2
A Project That Does Get Selected

In April 1999, one of Capital Blue Cross’s health-care insurance plans had been
in the field for 3 years but hadn’t performed as well as expected. The ratio of
premiums to claims payments wasn’t meeting historic norms. In order to revamp
the product features or pricing to boost performance, the company needed to
understand why it was under performing. The stakeholders came to the
discussion already knowing they needed better extraction and analysis of usage
data in order to understand product shortcomings and recommend
improvements.
After listening to input from user teams, the stakeholders proposed three
options. One was to persevere with the current manual method of pulling data
from flat files via ad hoc reports and retyping it into spreadsheets.
The second option was to write a program to dynamically mine the needed
data from Capital’s customer information system (CICS). While the system was
processing claims, for instance, the program would pull out up-to-the-minute data
at a given point in time for the users to analyze.
The third alternative was to develop a decision-support system to allow
users to make relational queries from a data mart containing a replication of the
relevant claims and customer data.
Each of these alternatives were evaluated on cost, benefits, and risks.

Source: “Capital Blue Cross”, CIO Magazine, Feb. 2000, by Richard Pastore

Recommendation by Capital Blue

Estimate Cost Versus Value
Capital's valuation incorporates cost and payback in dollars, the relative quality
of the outputs the systems would deliver to users, the levels of risk and the
intangibles.

Dollars: Capital bases cost on dollars that would be spent on resources and
time, including hardware and software licenses and development time spent
by users, IT staff and consultants. In this case, the team chose to factor costs
over five years to avoid the fallacy of choosing an alternative based on
misleading short-term costs.

The team came up with initial cost estimates quickly in order to expedite the
analysis and choice of alternatives. After the analysis period, when the final
approach was selected, Capital did additional ROI analysis to help establish a
budget for the initiative. This budgeting process took four to five weeks
because of the time needed to research the vendor's technology offerings.
Because this project was expected to be expensive, extra care was devoted to
this part of the analysis .

2
To estimate dollar payback, the team used numbers from two areas: internal
savings and the return that the health-care plan modifications would generate in
the field. Depending on the option considered, internal savings could derive from
the number of IT people freed up from support and redeployed, unnecessary
software licenses that could be jettisoned and reduced need for hardware such
as direct access storage devices (DASDs). Pursuing the decision-support option
and its requisite data mart would also yield savings and cost avoidance by
allowing Capital to cancel development of a costlier, redundant, less-focused
data warehouse project underway at the time.
Estimates of health-care plan returns from the field were based on
historical "medical/loss ratios," a metric insurers use to calculate premiums
coming in against claim payments going out. If plan adjustments resulted in the
current ratio improving to meet or exceed Capital's traditional ratio, the resulting
value would be directly attributable to the new system. The difference between
the current ratio and the target ratio was the number applied to the ROI estimate.

The manual, existing method came up high on cost because of the long-term
expenses of writing and maintaining ad hoc data reporting programs and
maintaining staff with CICS expertise, a skill set Capital Blue wanted to transition
away from.

The second option, writing a dynamic transactional data extraction program,

would also incur high costs because the program would have to be ever-
changing in order to accommodate user requests for different slices of data.

The third option, the decision-support data mart system, had the highest short-
term costs because of the pricey software license and the costs of hiring
consultants to assist in the implementation.

The payback calculations were thus: The decision-support system option would
return 12 percent annually over five years, based on anticipated internal savings
and improvement in the medical/loss ratio. Capital did not bother to spend much
time calculating full returns for the other two options because it became apparent
that they were far outclassed by the decision-support system based on other
factors. If all three options were equally viable, they would have done a full
business case for each.

Quality: This is a measure of the accuracy of the data and the relative quality
to those business functions using it for management decisions. In this
instance, quality was the key decision factor—without high-quality data to base
decisions on, the health-care plan changes might be ineffective, or even
worsen the situation. Best of breed was important to this effort, but if the
company wanted a quick-and-dirty, one-time solution, quality may not have
been weighted as heavily.

With the manual method, inaccurate rekeying of report data into spreadsheets

3
could easily undermine data integrity, and the processes would be virtually
unauditable. For the transactional extraction program alternative, the data
would presumably be accurate, but it would not be practical and perhaps not
even possible for the program to provide relationships between the data,
reducing its value. The decision-support data mart, because of its auditable
processes, data cleansing and relational capability, would yield the highest
level of data quality, making it much more likely that user decision making
would be sound.

Risk: The ideal risk rating for any alternative would be low-low, meaning a low
risk of project failure and, in the case of failure, a low impact on the business.
Capital calculates the impact of a failed system using estimates of the costs of
downtime, lost sales, fines and even lawsuits. The risk of a given project failing
is mainly relative—how much more likely is this project to flounder than that
project, based on its complexity, past experience, having appropriate skill sets,
the viability of the vendors and so on.

In the case of the three data analysis alternatives, Capital determined that they
were all risky. Continuing to do things manually was risky because Capital
might never have gotten the information needed. Creating a proprietary
program to extract data from a dynamic transaction system that wasn't
auditable was risky. Building a new environment—a relational data mart with a
customer interface—would be risky because Capital had never done it before.
And the tight timing mandated by the state regulators upped the ante for all
three options. Each one rated a medium-medium risk, so this category of
evaluation was not a differentiator.

Intangibles: The Concept Exploration team did not identify any intangible
benefits for the alternative approaches. The other differentiators were so
overwhelming, they didn't feel they needed to consider intangibles. When the
other decision factors seem relatively equal, intangibles get more
consideration to help guide the decision.

The Recommendation
Quality emerged as the big differentiator in this Concept Exploration and,
along with the dollar valuation, was the deciding factor in the stakeholders'
choice to pursue the decision-support system option. The other two options,
"boiled down to throwing more resources at the problem or automating the
wrong thing." The decision-support data mart went live at press time, and
Capital appears on track to meet the state regulator's deadline for change
submissions this month.