The FT Word – July 2001
The FT Word
The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.
Welcome
Welcome to the July 2001 edition of the FT Works Newsletter, a monthly review of trends in the support management arena. In this month’s issue:
· ROI – beyond the snow job for the CFO: creating ROI analyses to determine the payoff of CRM investments
· Using your knowledge base as a low-cost training tool
And a reminder that you have a month left (until 8/31/01) to take advantage of the special $100 price for the new The Complete Guide to Hiring Great Support Managers“. This offer is valid for newsletter subscribers only. Details at the end of this issue.
ROI – Beyond the snow job for the CFO
I’m somewhat of a skeptic when it comes to ROI (return on investment) analyses, since many of the ones I’ve seen have only tenuous links with reality and seem to be designed with the narrow goal of getting a specific purchase approved. In fact, a properly done ROI analysis is a great tool to determine whether a particular project is worthwhile. So let’s see how you can do you can analyze the purchase of a new CRM tool.
The logic behind ROI analyses is to compare the cost of an investment against the benefits it will bring to the company. The trick is to corral *all* the costs on the one hand and to assess reasonable benefits on the other. Let’s start with costs. You need to add up:
1) the cost of the software itself (the CFO won’t let you forget that one!)
2) the cost of maintenance and upgrades (you know how important they are)
3) the cost of the hardware required to run the tool (it could be zero in the long run if you can reuse machines, but you will want to start with parallel installations for a while. Be sure to check whether individual workstations will need upgrading; even adding a little RAM can cost a bunch if you’re outfitting hundreds)
4) the cost of any auxiliary software required (database software, reporting software)
5) the cost of maintenance and upgrades for the hardware and extra software
6) the direct implementation costs (out-of-pocket costs paid to the vendor or a third party). This in itself would deserve a full issue of the newsletter. Suffices to say that you should always expect to exceed the quote you have, especially for a long project. Try to get price guarantees (good luck!) and plan for 10-20% more than the initial quote. Some of my colleagues cynically suggest doubling the quote, but you should be able to do much better with good project management.
7) the indirect implementation costs (costs that you will incur internally). This item is usually neglected, perhaps because it’s hard to figure out. The reality is that internal costs can rival and exceed direct costs. Think about who will need to work on the project (project manager, SMEs, testers, etc.) and estimate how much time they will spend on it.
8) training costs, both direct and indirect
Depressed? Hang in there, here comes the best part: benefits. Include
1) the expected decrease in case volume. It can be a significant figure if you are supporting low-complexity products and you are installing a self-service system. In a high-complexity environment, don’t get carried away: a 10% decrease would be great!
2) expected increases in productivity : will the support reps be able to resolve cases faster with the tool? How much faster? It’s often helpful to segment the cases into easy/medium/complex since new tools typically don’t have much of an impact on complex cases but could make a big difference for the easier ones. Also think of segmenting electronic cases versus phone cases. Analyze cases handled by different groups separately. A finer analysis of the different phases in the life of a case may be required, for instance to determine savings in the routing phase, or the impact of being able to deliver status reports through self-service. In any event, your savings will be contingent on your costs, most of which are people-based and therefore will match the complexity of the software. Do not use “standard” costs you can find in overall studies as they are unlikely to match yours.
3) reduced training requirements: if the current tool is particularly onerous, or if the knowledge base will replace existing training, you may find savings here.
4) increased employee satisfaction resulting in reduced turnover: this one’s dicey, but I would allow it if you are currently experiencing turnover because of poor tools.
5) increased revenue: it’s usually very difficult to translate increased customer satisfaction into revenue (and even harder to sell the results to an inquisitive CFO) but you should capture obvious benefits such as being able to check entitlement easily and therefore be able to deny customers that have not paid for the service, or track service packs better. If you wish to go further, investigate “avoiding doom” scenarios: if you ever lost a customer because of a tool failure, that may be the only justification you need!
Now that you have a full list, it’s time to honestly spread out both the costs (most are upfront) and the benefits (which could come much later) over time. Despite what the vendors say, very short ROIs (investment recouped within a few months) are very rare, especially if you support complex products. So feel free to tinker with the ROI analysis to make it fit a reasonable time frame, but should feel very proud if you can get to a ROIs on the order of a year are quite respectable. Yes, everyone tinkers with ROIs until they fit a reasonable time frame, but
Using your knowledge base as a low-cost training tool
Training can be costly, especially if you have a small group and/or cannot train more than a handful of people at a time. Here’s a low-cost, high impact idea that can work in all settings, either as the training solution of choice or as an adjunct to other delivery mechanisms.
Simply create a training plan, listing the various training activities required from reading documents, hands-on experimentation, self-paced training courses, listening to tapes, etc. Suggest appropriate sequencing and time frames for each task. Place the training plan in your knowledge base. If your knowledge base system allows, have the training plan point directly to any knowledge base documents it refers to.
Then, point your staff to the training plan. It’s a great way to demonstrate the value of the knowledge base to newbies or doubters.
FT Works News
SupportWeek published an article about electronic software delivery entitled The New ESD: FTP grows up on 7/10/01. You can find the text at http://www.supportgate.com/supportweek/20010710/article2.html
The Service and Support Professionals Association will publish a Common Sense booklet I wrote on the same topic, Electronic Software Distribution Management An idea whose time has come this summer.
A reminder that The Complete Guide to Hiring Great Support Managers is still offered to newsletter readers (only) for the special introductory price of $100 through 8/31/01. 40 pages of no-nonsense tips and 566 pre-tested questions from which to conduct thorough and pointed interviews. Great for all of you who recruit for support managers and executives, and perhaps as a job-hunting tool too! Special introductory pricing of . For more information, including how to order, go here.
I’m working on a second guide, this time focused on hiring support reps and support engineers. It should be ready next month.
Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.
Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826
I intentionally ptseod the question to foster and provoke a discussion. I have over 20 years of IT and SW experience, but primarily in the ERP space, so on the business side of the IT world.I recently moved into the Enterprise Architecture world and I am just stunned how far behind the IT world is in terms of implementing and deploying their own infrastructure solutions.With the exception of some areas, IT runs IT based on Spreadsheets, PowerPoints and Visio.And it is IT that tells the business to go out and implement an integrated ERP backbone system where there is only 1 system of record.When I go into meetings and ask folks about their Enterprise SW landscape, they either have nothing to fall back on or they use PowerPoints or Visio Diagrams to explain to me their application portfolio.We all know that those PowerPoints are already outdated by the time they were printed.And these are not small companies, these are companies that have multi-billion USD IT budgets, hundreds of applications and they manage them in spreadsheets.Your comment about decreasing budgets and more and more demands from the business side is obviously valid.But when headcounts are being cut and the work gets more and more, one has to think about how to work smarter and more efficient.It can not be that the argument is We are so busy, we have no time to think about working more efficiently .The first step in my view would be to actually start defining a repository of IT artifacts and basically do an inventory of all important IT objects.- What applications are we using?- What components are those applications based on?- What versions of those applications and components are deployed?- What interfaces exist between those applications?- Who in our enterprise uses those applications?- What business processes are those application supporting?Those are basic questions that IT needs to be able to answer so that an IT strategy and roadmap can be developed and that the IT strategy is aligned with the business objectives.Coming from the business side, I have heard to many business execs say IT is not helping us, IT is not supporting our business strategy, IT costs me a lot of money and I don’t see the value .Start small with baby steps but keep in mind that eventually you want to grow into the other areas like business architecture (modeling business processes and business functions), deployment architecture and information architecture.Even ERP started small.Supply Chain Planning doesn’t make a lot of sense when some of the building blocks like accurate inventory levels and available manufacturing capacity does not exist.IT Planning doesn’t make a lot of sense unless you defined and manage some of the basic building blocks of IT as described above.Markus