Business Case - News and ArticlesHow
to bungle a software upgrade September 26, 2006 from InfoWorld
Ten years ago, I was the IT manager at a successful software company whose
main product was aimed at large insurance companies. It was a DOS app that read
records from large data files, did a little processing, and passed the results
to other apps downstream. It wasnt particularly pretty, but it was accurate
-- and it was fast! It worked in batch mode, processing thousands of records per
minute, which was a critical feature, considering how many records our clients
needed to manage each day. We were doing well with this app, which was pretty
much the industry leader. So in a classic it-aint-broke-so-lets-fix-it-anyway
move, some of our managers and salespeople began complaining that it wasnt
written for Windows. They lamented the fact that we didnt have a nice Windows
GUI we could put on our sales brochures. If we didnt rewrite for Windows,
they insisted, our competitors would eat our lunch! And while they had our attention,
these same people decided that the product would be even more appealing to our
customers if it worked interactively, so users could process a single record at
a time. This seemed an odd request, because as far as I could remember,
not one of our customers had ever tried to use the product in this manner. Come
to think of it, our customers had never shown much interest in a Windows version
either. I expressed my concern, but the boss was convinced that a Windows version
of the software would be our ticket to world leadership. Most of our in-house
programmers had been laid off by this point, so the boss hired an expensive set
of consulting software developers. In spite of my stated reservations, I was put
in charge of managing these guys -- requirements, test plans, testing, daily builds,
and so on. When I costed out the notion of rewriting the application from
scratch, the boss decided it would be way too time-consuming and expensive. The
developers suggested creating a Windows front-end that would manipulate the old,
reliable DOS application in the background. I considered this approach to be a
serious kludge. Worse yet, it made the app a lot slower. And it was almost impossible
to run it in high-speed batch mode. But it worked, and it was cheap. My boss loved
it. We worked on the code for six months; then the copywriters showed up.
In order to create compelling sales materials, they insisted, we had to redesign
the menus so theyd look good in the brochure. We were already over budget
and over time, and some changes made the app harder to use. Still, the boss insisted. We
had worked closely with sales and upper management, and they loved the new
Windows version. Unfortunately, we hadnt shown it to any of our users. Apparently
I was the only person in the company who was feeling nervous about this. Finally
we prepared to take the app, the new brochures, and a large sales team to the
biggest insurance convention of the year. Proudly, we demonstrated our new
baby to some of our largest customers. They liked the interface, they loved the
brochures, but they all had the same two questions: How can we get this
to run faster? and How do we turn on batch mode? Our sales
staff had no answers. But I had one: Keep running the old version.
Of course, I didnt think saying it out loud be a wise career move. So I
kept it to myself. 180 View Beware of decisions based
on technology without a business case. Watch
out for maintenance
July 2006 form CAmagazine - "Companies
on the hunt for a new system typically do an ex- haustive analysis of various
options before they make a tentative selection. Once they do, the subject of maintenance
inevitablyrears its head. For some strange reason, vendors wait until the very
end of negotiations before they bring up the subject. They might even treat it
as a mere formality. The question is, should you sign the contract as is? The
short answer is no. Everything should be negotiable, including the maintenance
contract. Usually, vendors will ask you to pay maintenance on the list price.
But in a competitive situation, they might allow you to negotiate using the discount
price. Maintenance usually runs about 18% of the licence fee. But the contract
could include escalation clauses, such as standard cost of living increases. At
the very least, make sure there are no increases for three years. A ceiling should
be provided after that. In the fee, only a small portion goes toward actual
maintenance. Most of the fee goes into R&D. Any vendor that does not invest
heavily in R&D will not be able to compete with more nimble companies that
leverage new technology. You want your vendor to be successful; otherwise, it
will be purchased for its customer list, not its product. That will leave you
with the task of converting sooner or later to a new system. So you do need
to pay the vendors something. But is that something worth the price? You might
not want to upgrade every year, especially if you have customizations that will
need to be adapted to the new system. You might be able to live quite happily
without new features that add complexity or require more computing power. Some
vendors will require you to upgrade whether you want to or not. But you can negotiate
the length of time you can wait before upgrading. But there may be compelling
reasons to keep current. Your chosen vendor might also be working on new software
that won't be available for years. This new software might be chargeable unless
you keep current with upgrades and pay your maintenance fees. Some vendors will
not support their clients unless they stay relatively up to date. The vendors
would argue - rightfully - that problems encountered may be fixed in the newer
release. Maintenance and support can mean very different things to different
vendors. One vendor might give you unlimited annual telephone support, while another
might give you none. What's more, even "unlimited" support has some
limits. Vendors need to protect themselves from taking endless calls from poorly
trained customers. They will also vary in their responsiveness. It won't do you
much good if your vendor takes several days to get back to you for a critical
problem. Let's assume you have unlimited support and your contract includes
an adequate response time. Will you get your money's worth? During the implementation,
your support questions will probably be answered by the implementation consultants
rather than the vendor's support department. You should ask for a break on maintenance
fees during this period. However, the vendors will say you are getting support
indirectly, since the implementation consultants are calling them instead. The
vendors have a point but the consultants won't be making as many calls. And once
the system is up and running, support calls should be less frequent. Some vendors
will allow you to purchase a bundle of support hours to be used as required. Vendors
have a good thing going with their maintenance fees. Today an investment in business
systems should be a 10-year proposition. Ten years at 18% of the purchase price
isn't bad. Vendors are more willing to discount their licence price than their
maintenance price. But remember: everything goes on the table before your signature
goes on anything. Business
Cases - Are they worth the paper they are printed on? November
2005 from CAmagazine and written by Michael Burns - "Chartered accountants
have a vital role to play in building business cases for IT investments, whether
they be for ERP systems or new networks. Unfortunately, most business cases are
not built by CAs, but by IT people who often lack the know-how and independence
to do them right. A business case is a tool that supports planning and decision-making
for both operational and investment decisions. A good business case includes the
methods and rationale that were used to quantify benefits and costs. It shows
expected profit impact and/or cash flow consequences over a period of time. Some
progress has been made in IT investments over the past five years. Before the
dot.com meltdown, companies shelled out for IT just to outdo the competition or
because they were mesmerized by the hype. Today, you at least need a business
case before making an IT investment. Sadly, its often not worth the price
of the paper it was printed on. One of the big problems with business cases
is that they are written by the same people who want to be funded for a particular
IT project. These people have a vested interest and typically find a way to make
their case with numbers. It gets worse when organizations rely on vendors to help
with their business case. The vendors may have some slick material and may be
able to offer a few ideas for people who dont have a clue, but caveat emptor. Business
cases often come complete with calculation errors, convoluted formulas and missing
explanations. Its easy to say a new system will improve efficiency by a
small percentage, but its a lot harder to provide evidence to support that
percentage. Direct observation is the best choice, followed (in descending order
of credibility) by corporate statistics, surveys, case studies, benchmark data,
educated guesses based on respected managers, educated guesses based on external
expert opinions, uneducated guesses and vendor-supplied ROI information. A good
way to determine the potential savings in improving operational efficiency is
to conduct a survey on the time employees spend on all non-value-added activities
such as rekeying information or reconciling data between systems. The survey should
be confidential and conducted by an external party to reduce the risk that employees
will avoid telling the truth. But be careful with the potential savings identified
by eliminating non-value-added activities. It can become a big morale problem
if employees think their jobs are at risk. Often, the answer is to involve them
in more useful activities such as analysis or talking to customers. Sometimes
the most compelling business case is that you have no choice for example,
your existing ERP system may no longer be supported or your business may have
changed. Still, there could be a big spread between the low- and high-end solutions.
You should have a business case to justify the higher-end solution if you think
its the best option for the company. So lets say the business
case was done properly and the IT investment was made. Typically, the file is
put away, never to see the light of the day again unless something goes wrong.
But a business case should act as a beacon throughout the entire process. It should
include measurements for determining whether the investment was successful. The
measurements should be used to motivate all employees involved in the project. Accountants
have the number-crunching skills and business knowledge needed to build better
business cases. Its time they took charge of the process."
Beyond
ROI: Enterprise Payback 2005 from Enterprise Applications Consulting
- "While most vendors have been able to construct comprehensive ROI models
for their products, these models largely fall short in their ability to accurately
measure the total value of an enterprise software investment. This is due to the
fact that most ROI models are focused on quantifiable measures of return. While
this is a useful and often necessary function, the focus on purely quantifiable
measures leaves little room for a discussion of more qualitative success factors
that are often difficult to fit into a fixed economic model. A more complete analysis
of return can be had by looking at the overall payback that enterprise software
can offer to a company. Enterprise software payback includes not only quantifiable
improvements in bottom and top line functionality, but also more qualitative measures
such as new business opportunities, improved customer and partner relations,
and improved time to market that contribute significantly to the success
of a companys enterprise software implementation and use. Enterprise software
buyers who understand the overall payback that a given product suite can offer
their company will be able to make more informed choices that lead to success
not just in software deployment but in overall business functionality." For
more, click here. Business
Cases: What, Why and How
June
13, 2005 from Computerworld - "Business cases are essential to good business
decisions and IT success. They provide the foundation for informed decisions about
what to fund, what to cut and how to set IT priorities. Moreover, they help set
corporate expectations by accurately stating the benefits that will result from
new programs. Many IT organizations
resist building business cases. A familiar excuse is that they are just too much
work. Developing and using business cases requires significant time and effort.
Bruce J. Rogow of Vivaldi Odyssey and Advisory estimates that a comprehensive
business case costs between one quarter and three quarters of 1% of a project's
total development cost. Although this may appear to be expensive, it's much cheaper
than taking a massive write-off down the road. Some organizations
argue that business cases aren't applicable to their industries. In fact, business
cases are crucial to every industry, including government and the nonprofit sector.
Every organization needs a consistent way to evaluate potential investments on
the basis of data and reason, rather than on passion alone. Business cases come
in various shapes and sizes. At minimum, an effective business case does the following:
- Defines the problem and the proposed program's objectives and scope.
- Describes business and technical assumptions and alternatives considered.
- Provides estimates for resources, scheduling and costs.
- Describes
major development and operating risks.
- Quantifies tangible benefits and
describes intangible benefits.
- Predicts financial return."
Click
here for the rest of the article. Battle of the Metrics CFO
IT - Winter 2004 Issue - "CFOs remain optimistic improbably optimistic,
some might say about the role that IT can play in their companies. Despite
a surfeit of talk about IT becoming a commodity or a utility, fully three-fourths
of respondents said they consider IT to be strategic, and of those, about 60 percent
will spend more on IT next year as a result. But they despair of spending
it wisely. Despite assuming greater involvement in setting IT strategy
a trend in effect for several years CFOs remain unconvinced that IT investments
are paying off, or that they know how to properly assess IT projects before giving
the green light. Fewer than half believe the IT expenditures they've made in the
past year have achieved the return they had hoped for, and for every CFO who has
resolved the ROI debate by adopting a formal approach for some or all IT projects,
another continues to search for better ways to analyze the return on spending. "At
the end of the day," says Etterman, "these are judgment calls, not empirical
decisions. We focus more on business metrics than financial metrics." As
one example, he cites a recent project to improve his company's maintenance and
service renewal rates. "We got a 30 percent improvement," he says, "and
there was an IT component to it, but it also entailed changes to our processes.
So I can't say exactly how much of the benefit can be traced to the IT portion
of the effort... "The applicability of ROI depends, to some degree,
on the nature of your company," he says. "We think of ourselves as being
very good at customer service as opposed to some other emphasis, like being a
commodity provider that might stress operational efficiency. So if a project looks
like it will enhance our mission, we tend to like it," even if a firm payback
within a specified time frame appears impossible to calculate... Although
nearly 40 percent of survey respondents said they continue to debate the ROI issue
and look for better approaches, very few will admit publicly that their companies
should do things differently." It seems to me that there is a better
approach than to just rely on ROI. The article talks about business metrics in
passing as well as evaluating IT investments on the basis of whether it enhances
a company's mission. I think that any investment that will enhance a company's
ability to achieve CSF (Critical Success Factor) metrics, should be considered.
Why not set a budget for IT and then evaluate investments based on which ones
contribute most to CSFs at the least cost? For the article, click here. Article
on Business Case published in the July 2004 edition of The Bottom Line
It wasn’t that long ago when companies invested in Information Technology (IT)
just to remain competitive. From an IT textbook taught at a Canadian University
today, you would find “Boards of directors have finally realized they have to
bite the bullet and fund these huge multiyear projects just to remain competitive”
Those days are over. Business is back in the driver’s seat. As IT projects have
a bad reputation for being over budget, not on time and not generating the expected
results, senior management is not going to proceed with IT projects unless there
is a compelling business case. For the article, click here. Business
Case Benefits July 21, 2004 from gannthead.com - The author, Mark E.
Mullaly (a highly regarded Project Management Professional), suggests ways to
quantify intangible benefits. "While the benefit may be intangible, it may
result in additional benefits that can be measured. As an example, more businesses
than I can count claim that the benefit of doing a project is "improved customer
service." Great claim, but how do you measure it? Assuming, for the sake
of argument, that you actually measure customer satisfaction--whether through
surveys, focus groups or market research--then you have a proxy that you can start
to use. What's the increase in sales (actual products sold, net sales revenue,
revenue per sale) when customer satisfaction increases? Every point increase in
customer satisfaction will likely have a corresponding increase. And so, as customer
service actually does go up, so does revenue." Mark also suggests "Identify
the cost of the next-best-means of attaining a benefit."and "Identify
the cost of not getting the benefit." For more from Mark, click
here. ROI - It's definitely a journey. Not an end in itself
June 2004 from darwin - "Over the years, after countless ROI analyses for
leading software providers, my opinions have fundamentally shifted about the use
of ROI analysis and how meaningful ROI results can be. In short, my take on ROI
has shifted away from the belief that the results of ROI are factual and the goal
of the ROI exercise is to find the answer. The degree to which slight changes
in variables yield significantly different results was my first lesson in ROI.
ROI can be volatile... Often overlooked is the fact that ROI is a house built
on best guesses. It's an estimate. The rate of innovation of products, business
models and partnerships in the technology industry makes ROI even more elusive
than in other industries. Another lesson: ROI can be based on relative unknowns.
These two lessons led to another: that the real teaching of ROI is not in solving
the equation, but in learning through the process. ROI is a journey not a destination...
Initiatives can be purely based on strategic or business value. Many times
a tedious and exhaustive ROI analysis is still answered by the question, "but
how can we not do it?" I will argue that any initiative valuable from a strategic
or business perspective does have an associated financial return. However, many
times the return may be too difficult to quantify. A good example of this is website
design. What is the return on having a website that is easy to understand, informative
and intuitive to navigate? It may be hard to quantify the benefits especially
if you do not sell your product online. But how can you "afford" to
not do it?" For the ROI article, click
here. The Proof is in the ROI March 30, 2004 from TechnologyEvaluation.Com
- This article talks about the importance of ROI, needing expertise in developing
an ROI and that vendors can and should help with building ROI. "Eight-two
percent of IT decisions require ROI analysis according to Information Week. Eighty-one
percent of buyers expect vendors to quantify the value proposition, and by doing
so, 60 percent more projects are likely to be approved. Perhaps the most important
fact of all is that a valid ROI sales effort reduces the sales cycle by 30 to
40 percent, according to the Gartner Group." For the article, click
here. I say when a vendor helps build the ROI, buyer beware. With
a little creativity, you can prove anything with numbers. The vendor may also
be working closely with internal people who have a vested interest in having the
IT investment approved. Get someone who is independent to build the ROI. This
person could be an internal financial expert or your accountant or an independent
consulting firm such as 180 Systems. Click here
for information about our business case development services. Alternatives
to ROI March 9, 2004 from E-Business Executive Daily - We read that
"In late 2002, Deloitte & Touche and the IDG Research Group teamed up
to study 200 IT leaders at companies with $250 million to $5 billion in annual
revenue. The goal was to determine how these leaders utilized and evaluated the
value of their IT investments. The findings were eye opening and unexpected. Results
showed that there were at least five methods for measuring IT value, of which
ROI was only one of the methods: Sixteen percent of the respondents utilized a
specific ROI formula or benchmark for measuring IT value; 11 percent used increased
revenues; 16 percent used TCO (Total Cost of Ownership); 15 percent used the measure
that the project is up and running within a certain time; and 19 percent used
an increase in productivity to measure value." The writer comes to this conclusion
- "As can be seen, there is no single measure of IT value that is the consensus
"most accurate" reflector of IT value." I would agree that there
is no consensus but consensus does not equate to most accurate. In fact, the other
measurements being used reflect that many companies don't know what they're doing
when it comes to evaluating IT investments. That's not to say that ROI is perfect
but it's a hell of lot better than revenues, TCO, whether project is up and running
or productivity increase. For the article, click
here. Some guidelines for ROI March 25, 2004 from DM
Review - We read that "As an enterprise buyer of IT solutions, it is vitally
important to assess the potential ROI of an IT investment using believable, objective
modeling tools. This means that IT vendors who offer ROI calculators to demonstrate
proof of ROI must be using tools that are unbiased and based on the ROI experiences
of their deployed customers. If a vendor has built their own ROI model in house,
you are correct to be skeptical about its objectivity. Here are some questions
to ask of IT vendors regarding their ROI modeling tools:
For the article, click
here. IT Budgets and ROI November 17, 2003, CFO Magazine
- "A knowledge of basic finance is often lacking in a typical IT department.
For example, in a joint study of 130 senior IT executives by the Society for Information
Management, the Kellogg School of Management, and DiamondCluster International
earlier this year, 74 percent of respondents said they would like to have a strategy
to regularly calculate technology ROI, but that 51 percent "have no process
to align and evaluate IT investments with business strategy." And 42 percent
acknowledged that their IT staff lacks "sufficient working knowledge of financial
concepts." I personally wouldn't trust the IT executive with the ROI calculation
- not because they don't have the knowledge - but because of the conflict of interest.
You can prove anything with numbers if you have the incentive. Independent accountants
with the number crunching skills are badly needed in the IT world. For the article,
click
here. Making the Business Case for Technology Investments
CIO Analysis provides some basics for calculating ROI. Their advice includes "If
your initial calculations yield an ROI less than expected, don't panic - take
a closer look at the calculation. If the ROI is drastically negative, there are
probably breadth and repeatability issues or unreasonably high costs. If the ROI
is simply lower than you need to proceed, it's likely you can fix it - and gain
appropriate benefits from your investment". The trouble with this approach
is that you are encouraged to number crunch until you get the numbers to work.
Beware of ROI calculations from those who have a lot to gain from the project.
For the article, click
here. What are the common mistakes involved in measuring return on
investment? Darwinmag.com takes a more cynical and practical approach
to ROI. ROI is not easy to calculate as most companies don't have good data to
support their ROI calculations. The article discusses the value of e-business
investments versus brick-and-mortar investments. "Rule number one for ensuring
ROI is that e-business has to leverage the brick-and-mortar functionality because
without it you are out on a limb spending money on a vast unknown. That was why
a lot of ROI didn’t come out of initial e-business experiments -- because companies
spent a tremendous amount of money on a channel that hardly existed for them and
certainly had no proof of potential. There was a lot of money wasted. Today, we
have the advantage of having had a lot of experience. If you look at e-business
as an essential part of your brick-and-mortar strategy you’ll get an ROI out of
it much, much faster." For the article entitled "Five Thoughts
About ROI", click
here. Skunk Works or how to get IT investments in today's market
January 17, 2003 - From CIO Insight comes an interesting article about getting
a project funded despite the cutbacks. Skunk works used to refer to a few technical
geeks working away in isolation on some risky project. Now skunk works has become
mainstream as a way to prototype a new technology without committing the big bucks.
IT labs are being setup that demand business results—and most within 90 days or
less. Another key difference in today's skunk works is that "the key to project
success is getting—and keeping—IT and business leaders aligned around common business
goals. Most IT labs are places where such teamwork is not only encouraged, it's
mandatory." For more, click
here. Improving Accounting Technology ROI From BusinessFinanceMag,
"For most companies, the primary factor shaping the business case for an
accounting software upgrade is ROI. Companies expect a new system to pay for itself
in several years or less. And that goal is entirely achievable, given such benefits
as faster cycle times, lower levels of staffing for finance activities, more efficient
budgeting tied more closely to company strategies, and less time wasted on low-return
manual tasks. ROI doesn't happen automatically, however. If you're considering
a new accounting system, there are some guidelines worth considering... Look for
a vendor with experience in serving your industry...Some of them offer software
tailored specifically to your industry...Within the financial arena, the range
in ROI from investments in financial analytics software was anywhere from 39 percent
to over 2000 percent, with a median ROI of 140 percent..." For more,
click
here. Tightening the Reigns on IT Spending According to
the Boston Consulting Group, much of IT spending is wasted as a result of several
critical dysfunctions that plague the IT organization and management of most companies.
The first dysfunction is a lack of transparency - companies don’t know how much
they are spending, where their money is going, or what they are getting for it.
The second type of IT dysfunction is a lack of business orientation - the IT effort
falls out of step with the company’s strategic vision. The third type of problem
is a lack of governance. Many companies have no chief information officer, and
many others have CIOs with insufficient authority to make or drive IT decisions.
For a link to this article from BetterManagement.com, click
here. A survey of over 250 executives (CFO's, Directors of Finance,
Controllers...) on IT investments CFO magazine and Morgan Stanley surveyed
252 executives between July 30 and August 20. The survey found that a resounding
majority of CFO's are devoting more time to IT issues these days. When asked whether
their companies have gotten the expected ROI from technology investments, almost
half said no or rarely. For the survey results, click
here. The case against the business case CFO magazine
also published an article on October 30 that cautioned about over reliance on
ROI. There are some projects that don't need a hard and fast business case such
as an implementation of an accounting or ERP system. I disagree. Although
there may be cases when an organization has no choice in the implementation of
a new ERP or accounting system, there are choices in which system is selected.
If there is not a good business case/ROI for the more expensive system, then the
less expensive system could be the better alternative. Click here
for the article. |