Lexicon Systems, LLC Blog

lex'•i•con: the vocabulary of a branch of knowledge. Thoughts on environment, health & safety (EHS), sustainability and information technology to support them.


Leave a comment

12 tips for killer software demos

When selecting enterprise software, demos are a key part of the due diligence process. Even with a short list of 3–4 vendors, sitting through several days’ worth of demos can try your patience. Learn how you can work with prospective software vendors to deliver a killer demo to engage and inform your stakeholders.

12-tips-killer-software-demos

Freepik/Jill Barson Gilbert

I recently facilitated an enterprise software selection process. This required gathering information on software and vendor capabilities, interviewing reference customers and participating in multiple software demos, among other activities.

While each software vendor on the “short list” can address a vast majority of the client’s business needs, each vendor has a range of capabilities. So, how do you set the stage to allow comparison and to make the demos informative and enjoyable, instead of exhausting?

12 Tips for Killer Software Demos

Avoid “demo killers” like poor preparation, dismissing key stakeholder needs, going off script, talking too much, failing to engage the audience, poor demo skills, bashing the competition and apologizing for the demos or software.

The most successful and enjoyable software demos were those where I worked with my client and the vendor in advance of the demo. Here is insight into my approach for “killer demos.”

1. Prepare

Ask important questions before the demo, for instance, the business drivers for the enterprise software; what systems the company uses today; the company’s primary concerns; the expected benefits of the new software; user community and job roles; stakeholders who will attend the demo; decision-makers and key influencers.

2. Focus on needs

Shape the demo around users’ needs — not wants — and priorities. This requires documented software business requirements, with user consensus on needs and priorities.

3. Avoid the standard demo

Standard demos show that the vendor did not consider the customer’s needs. Instead, take astandard approach as described in these tips.

4. Don’t change a thing… except…

Demonstrate the software in its standard, “out of the box” form — without integration,customization, or significant configuration — unless otherwise requested by the customer. An exception is minor personalization using the customer’s branding.

5. Show a day in the life

Simulate the user’s day-to-day experience. For example, show how a “power user” creates monthly reports, and enters detailed data. Show how a casual user completes an assigned task. Show how a site manager or a corporate manager views key performance indicators (KPIs) on a dashboard.

6. Stick to the script

Create a “storyboard” for the demo based upon business needs and priorities. If the customer provides software scripts and/or demo data, then make sure that the scripts align with the stated needs and priorities. Demo the software to best showcase its capabilities while addressing each script.

7. Start at the end… then go backwards

First demo reports, dashboards and workflow that show how a user interacts with the software. Then demo key data entry forms. Demo a workflow or two. Run a few key data queries. But demo software configuration, workflow configuration, report and dashboard creation only if the users would do this day-to-day.

8. Speak to selection criteria

Understand the customer’s software selection criteria, and address them throughout the demo and dialogue.

9. Address resource needs

Address how many subject matter experts (SMEs), project managers and IT resources the customer will need for implementation, roll-out and ongoing maintenance. Provide customer references that can back up these resource estimates.

10. Have IT experts available

Summarize the software’s architecture, hardware and software needs; installation options (on premises, Cloud, Software as a Service) and implementation — but don’t bore a room full of subject matter experts with IT details. Have IT experts present or on call during the demo to answer IT questions.

11. Distinguish yourself

Address how your software will improve the customer’s business. Be positive about capabilities and transparent about third parties you use to deliver software and services. Boast about your successes, and back up statements with evidence. Do not make negative or false statements about the competition.

12. Deliver strong

  • Know your audience – anticipate and address their needs.
  • Engage the audience – control the content and flow, and encourage dialogue.
  • Have a strong opening – capture the audience in the first two minutes.
  • Make your case – benefits the customers will gain, and what sets you apart.
  • Respect the clock – arrive in plenty of time to set up, and plan to finish early.
  • Get trained – learn how to speak to a group and how to demo software. 

Conclusion

A well-delivered demo can make up for software shortcomings, while a poorly-delivered demo can destroy the chance of customers embracing even the best software. Demos can be compelling and enjoyable when the software vendor and prospective customer organize a “killer demo” through preparation, focus, speaking to business and IT issues, and strong delivery.

This post first appeared on the Strategies for Software Lifecycle Management blog.

Advertisements


Leave a comment

3 ways to avoid costly software selection mismatches

Some organizations faced with enterprise software selection make emotional, rather than objective, decisions; select technology before understanding their needs; get caught up in vendor hype; or find a solution that does not match their ability to adopt it. Here are three ways that software selection pros make the selection process easier.

Recently, I joined a tech product review forum. This is a volunteer assignment where the sponsors encourage objective reviews. The reviews help prospective customers to make informed buying decisions.

My first assignment was to review a robotic vacuum cleaner. I found the product easy to unpack and set up. I needed to watch the robot the first few times I used it, to ensure that the machine did not get snagged on something. After multiple random passes, it cleaned the ground floor of my home. This took about three hours and two battery charges to do what I could have done manually in 20 to 30 minutes with a regular vacuum cleaner. The robot did only a fair job of picking up typical debris.

In the end, I did not recommend this product.  This tool did not meet my basic needs—to clean quickly and effectively, with little effort. The robotic vacuum cleaner is an interesting technology, but not developed to where it can replace traditional vacuum cleaners. It is early in the product lifecycle, slightly costly for what it does, attractive to techies, though not ready for the majority of us to adopt.

If I had purchased this product, I would have been out a few hundred dollars at most. But what if I had purchased enterprise environment, health & safety (EHS) software? I could have spent hundreds of thousands of dollars, only to have a mismatch. Here are three things the pros do to avoid costly software selection mismatches.

1. Start at the beginning

Don’t start looking at software until you know what you need. First understand your needs and priorities, and then seek out products that best match them. If you know your needs, you should focus on at most, two or three candidate software platforms that best meet your needs.

Do not review the universe of available software, because this only creates confusion. Back to vacuum cleaners for a moment… If you need to clean hard flooring and pile carpeting in a four-bedroom house with five family members, one cat and two dogs, then forget handheld vacuums and shop vacs. Instead, focus on the products and technology that meet your needs.

Since enterprise software initiatives can involve multiple phases over month or years, consider your most pressing needs, as well as mid-term and long term needs. Mid- and long-term needs—and project objectives—may call for software that is flexible, configurable, and scalable to accommodate new users, new business processes, and future mergers & acquisitions.

2. Separate the wheat from the chaff

Sometimes it’s hard to tell one software package from another, just by sitting through a couple of hours of demos. You may like each software platform better than the one before, or worse, may like them all, when, in reality, they differ greatly. And you may be subject to marketing hype like, “We are the leading provider of EHS software to Fortune 500 companies” or “We provide the lowest Total Cost of Ownership in the industry.”

To make your life easier, take a systems lifecycle approach and carry prioritized business needs from one project phase to another. This helps you to create an environment for apples-to-apples comparisons.

  • During the Analysis/Needs Assessment phase, make sure to clearly identify and prioritize requirements, considering key stakeholder input.
  • Use prioritized requirements (and, as appropriate, mid-term and long-term needs) as the basis for a Request for Information before the demos.
  • Ask each of the “short list” of 2-3 vendors to demo their software according to use cases that you provide, and evaluate how each of the vendor packages meets your needs.
  • Make sure to discuss and document your software and vendor evaluation and selection criteria before inviting vendors in for demos.

3. Understand IT maturity

  • Technology Enthusiasts love tech first and foremost and want to be on the cutting edge; they are the first to try a new product.
  • Visionaries love new products as well, but they also consider how those new products or technologies can be applied. They are the most price-insensitive part of the market.
  • Pragmatists are open to new products, but need evidence the products will work and be worth the trouble. They are much more price conscious.
  • Conservatives are much more hesitant to accept change; they are inherently suspicious of any new technology and often only adopt new products to keep up with others. They don’t highly value technology, and are not willing to pay a lot.
  • Skeptics are not just hesitant, but actively hostile towards technology.

When you select software, make sure that you understand your organization’s IT maturity. Is your company an innovator, salivating for the latest technology, and willing to work with software vendors to iron out the wrinkles in a beta product? Or does your company sit solidly in the market majority, willing to wait for software to be tested and proven before you purchase it?

Also consider where the software lies along a product lifecycle curve. Is it an early market product, lean and mean, gaining momentum, made by a vendor with lots of innovative capabilities? Or is it a more mature technology with plenty of breadth and depth, integration and reporting capabilities, in its fourth or later version, with more enhancements on the way?

Select enterprise software that’s a good fit for your organization and its needs. These are just three ways to make a better-informed and objective enterprise software selection. If you do not have all these capabilities within your organization, do not be afraid to ask your IT group or a trusted advisor to help.

This article originally appeared in the Strategies for Software Lifecycle Management blog.


Leave a comment

Good RFPs lead to better proposals

white arrows painted on ashpalt

Get all suppliers headed in the same direction.

Is a Request for Proposal (RFP) or Request for Quote (RFQ) in your future? To make sure that your RFP does not become a “Request for Problems,” consider the following advice:

  1. Engage the right team. Include a cross-section of stakeholders to develop the RFP and to evaluate proposals. 
  2. Send the RFP only to 2-3 qualified parties. By the time you reach the RFP stage, you should have a good idea of which suppliers can best meet your needs. Do not waste the supplier’s or your time just to get pricing information.
  3. State the evaluation criteria up front. Share the “high level” criteria such as fit with business needs, ease of use, supplier qualifications, etc. Spare the details.
  4. Provide project background information. This sets the stage and gives the supplier a reference point.
  5. Provide a proposal outline or response template. This  permits you to compare proposals on a level playing field. A clear outline will elicit better responses and a template should make responses easier to evaluate.  Limit the response length in certain areas as you see fit.
  6. Make it easy for the supplier to respond. Be specific with your request for information.  Avoid asking for superfluous information, and instruct the supplier to be brief.
  7. Provide a single point of contact. Typically, Supply Chain or Procurement is the contact. The single contact will ask the end-user of the product/service for help in answering questions in their domain. This levels the playing field and keeps politics out of the equation as much as possible.
  8. Request customer references–and check them! Assume that suppliers give only positive references. If you have contacts within other organization, then call them as well. Ask the same questions of each reference, including questions like, “Would you choose this supplier if you had to do it again?”
  9. Impose a “quiet period” from the RFP issue date through supplier selection.
  10. Provide feedback to ALL suppliers. After selecting a supplier, remember to give feedback to those who did not win the bid. Surprising, many organizations forget this common courtesy.

See the IT Insight archives for further reading on this and other topics related to software evaluation, selection and life cycle management

© 2013 Lexicon Systems, LLC.


Leave a comment

Vendor reference call do’s and don’ts

In my 25 June 2012 post I introduced due diligence for software initiatives. When your organization issues a Request for Proposal (RFP), you should ask each vendor to supply customer contact information to allow due diligence. Here are twelve do’s and don’ts for reference calls…

  • Do speak with reference customers with business needs and/or implementation scope similar to yours.
  • Don’t extend each call beyond 30 minutes. Respect the software customer’s time.
  • Do prepare a list of questions that you need answered, and use it as a guideline.
  • Do use a combination of closed- and open-ended questions to allow you to gather good information you might not have anticipated before the call.
  • Don’t ask questions related to confidential contract information such as license or subscription fees or implementation costs.
  • Do ask what some of the greatest challenges were with the software project.
  • Do ask the customer if s/he would select the software and/or implementer if s/he could do it over again.
  • Do keep the number of people on each reference call from your organization to a minimum.
  • Do have the same people in your organization participate in each reference call.
  • Do consider whether you are speaking with a beta customer who adopted the software early, vs. a customer that implemented software when it was more mature.
  • Don’t hesitate to ask a reference customer to provide a short Web or face-to-face demo of the software in action.
  • Don’t limit yourself the references that the vendor provides. If you know someone within another customer’s organization, make a phone call.


Leave a comment

Have you done your due diligence?

Due diligence is a way to manage business risks. Enterprise software initiatives cost in the six and seven figures and take months or years to complete. Prudent organizations conduct due diligence not only on their software consultants, but also on the software, the vendor and implementation team. The due diligence process starts before you first speak with the vendor.

Read EHS Software Due Diligence is Critical to Success to see sample evaluation criteria, learn about reference customer contacts and get advice gathered from customers in the field.


Leave a comment

Software selection made easier

There is no such thing as “software selection made simple” or a “silver bullet” killer app that meets every organization’s environment, health & safety (EHS) needs. Companies looking for EHS and Sustainability software have many choices—too many, in fact.

The Paradox of Choice says that too many choices make it harder. Companies often choose software because it is easy to evaluate, rather than what best fits their needs. With thousands of commercial EHS software applications available in the marketplace, how does an organization evaluate and select software?

Read The Software Selection Paradox to learn more.