Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Do you ever have trouble selling technology projects? Over the years I’ve
run through a bunch of methods and approaches. But it’s 2002, Wall Street
is collapsing under the pressure of its indiscretions, corporate America is
under fire for its inability to tell the whole truth and nothing but the
truth, and the technology capital markets are awful.
This last problem is especially important if you’re trying to sell a
technology project to a battered senior executive team that’s in no mood to
spend a ton of cash on a new project.
What this process is all about is the identification of real and political
reasons to buy something or engage a consultant. This can be a very tricky
process, since (because of the perennial competition for funds) there will
always be project enemies, those just waiting to say “I told you so” when
the project goes south. IT buyers — especially in large enterprises —
have to make sure they’ve covered their flanks. The “business case” is
therefore as much a “real” document as it is a political one.
Business cases are typically organized around questions designed to
determine if the investment makes sense. Let’s look at the key questions
that you should answer before buying software, communications, or consulting
services. Let me say up front that the answers to these questions should be
in a 10-page document (with appendixes if you must): If you generate a long
treatise on every investment you’ll never get the time or respect of busy
senior executives.
Key Business Value Questions
What business processes are impacted by the investment/application(s)?
The correct answer here identifies a process that’s broken, a process for
which you have empirical benchmarking data. For example, if you were
selling LAN administration productivity tools, you’d have to know what
you’re spending now and that the costs were rising dramatically. You’d then
need to know exactly what your performance target should be (e.g., reduce
the costs by 25%).
How pervasive is the product or service among your traditional and
unconventional competitors?
Many decisions about IT adoption are driven by what the competition is
doing: It’s always easier to sell something to a customer whose competitors
have already signed on to the product or service (of course, this assumes
that your competitors are smart).
What competitive advantages does/will the product or service yield?
In other words, why is this product or service so great and how will it help
you profitably grow the business.
How does the new product or service interface with existing business models
& processes?
This is a big question, since the “wrong” answer (like: “it doesn’t”) will
often kill a project. If deployment means ripping out or enhancing
infrastructure, then you’ve just significantly increased the price (and
given your internal enemies ammunition).
Key Technology Questions
How mature is the product or service?
The point of these questions is to determine if the technology or service
actually work — and work well. You will need quantitative data here: It
won’t help to tell everyone about how great your brother-in-law’s company
is. Additional questions here concern scalability, security, modifiability,
usability, etc.
What share of the market does the product or service own?
If the answer to the question is, “Well, one percent,” then a major
explanation will be necessary.
How does the new product or service integrate with the existing or planned
communications & computing infrastructure?
This question is extremely important because it identifies any problems
downstream that might occur because of decisions already made (that cannot
be undone).
Key Cost/Benefit Questions
What are the acquisition, implementation & support costs & benefits?
Here you need to look at obvious costs, like software licenses, and less
obvious ones, like training, indirect user and help desk support, as well as
the expected operational and strategic benefits like expense reduction,
increased market share, improved customer service, increased cross- and
up-selling, improved customer retention, etc.
What are the support implications? How complex, how costly, how extensive,
how timely?
Support is extremely important. You need to know — empirically — what the
support requirements and costs will be defined in terms of dollars, people
and time.
What are the migration issues? How complex, how costly, how extensive, how
timely?
This may or not be relevant, but if another tool was in place you have to
answer questions about how to get from one to the other.
Key Risk Questions
What are the technical, personnel, organizational, schedule & other risks to
be considered? What’s the risk mitigation plan?
The risk factors that everyone will worry about include scope creep, cost
and time overruns, incompetent or irritable people, implementation problems,
support inadequacies, training problems, and the like.
If risks are assessed as medium or high then a mitigation plan must be
developed, a plan that either moves the risk down to the “low” category or
eliminates it altogether. If the risks remain high, the project sale is
dead.
The Recommendation
The recommendation is go/no go/we need more information. The whole purpose
of integrating a business case into the sales pilot is to avoid the
“we-need-more-information-syndrome.”
The business case should also identify at least two “accountable” people,
people whose reputations rests to some extent on the success of the project.
One should be from the technology side of the organization and one from the
business side (if you can find the right hybrid). If there are no project
champions, it’s time to go home.
Steve Andriole is the Thomas G. Labrecque Professor of Business at
Villanova University where he conducts applied research in
business/technology alignment. He can be reached at
stephen.andriole@villanova.edu.
