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

New CIO.com blog post | 6 criteria for selecting a software implementation consultant

Just posted this morning… 6 criteria for selecting a software implementation consultant.

Enterprise software implementation is a big deal, and the right consultant can make your life easier. Here are six essential criteria to consider when selecting a consultant.

Today’s post will help you to adopt Tip No. 2 in last week’s post, 6 tips for finding a great software implementation consultant — “Establish objective selection criteria and stick to them.”


Leave a comment

$Dollars still drive EHS software decisions

A large manufacturing client of mine recently completed a software evaluation and selection process. The project stakeholders used a set of objective evaluation and selection criteria to arrive at a decision. Interestingly, these criteria did NOT include cost. If in, the final evaluation two software solutions were rated equal, then cost could be a deciding factor. My client and the software vendor were excited to move forward with implementation at warp-speed, as the clock was ticking towards internal deadlines.

Since the EHS business and IT sponsors kept the executive suite updated, it looked as if formal approval would be easy. The company had strong business drivers regardless of the project cost. Of course, no project has unlimited funds. In the end, the project was approved–only after a lot of number-crunching and many revisions to the executive presentation.

Why? Executives run the business using performance-based metrics. Most C-level executives are trained to value a project based on “hard numbers” metrics such as cost saving, cost avoidance and Return on Investment. Often, they dismiss the value of compelling “soft numbers” associated with benefits that are harder to quantify, such as making decisions based upon solid data, the ability for users to adopt (and gladly use) the software, data entry at the point of activity, and productivity gains from EHS process automation, self-service reports and dashboards.

Image

Dollars, Euros, Pounds, Yen

Prepare a compelling business case based upon a good understanding of your business. While this does not require exhaustive research, you need to know where to look.

  1. Keep it simple. Find 2-3 relevant “hard numbers” cost avoidance and cost savings examples.   These savings alone could pay for the project in 3-5 years.
  2. Consider the total cost of ownership (TCO). This includes software license/subscription, maintenance and implementation fees PLUS the cost of internal EHS and IT resources, external consultants, hardware and other expenses over the lifetime of the software. Many organizations have tunnel vision and compare only license and implementation costs; TCO allows a more realistic and credible evaluation.
  3. Avoid selecting the low-cost option just to save a few dollars. If the software fits current, near-term and long-term needs, then it may be a good option. Reread item 2 above. You may wish that you had chosen a more “expensive” option, as it would save effort and money over the life of the software.
  4. When in doubt, seek expert advice. Seek assistance if you lack the know-how to prepare a business case for C-level or Board approval. The skills needed to develop a business case are very different from the skills needed to administer the software after implementation. This expertise may lie within or outside of your organization.

While dollars still drive EHS software decisions, look at the bigger picture. You will be glad you did!


1 Comment

Increasing the probability of software implementation success

Last week I attended a Webinar that focused on the leading environment, health & safety (EHS) software companies. During the Q&A period, an attendee commented that, while the software may lead the market, the firms that implement the software may not be up to snuff. This results in problematic implementations and unhappy clients.

At a business lunch the next day, a colleague asked why some EHS consulting firms are less successful than others when it comes to implementation. I replied that implementation success is not about the software alone. No matter how feature-packed, intuitive and functional the software package, it takes more than software-savvy subject matter experts and EHS-savvy software engineers for a truly successful implementation. The implementation team requires proven methodology, good project management and social skills, and the ability to foster user acceptance.

  • proven methodology is important throughout the entire software life cycle–from concept through business needs analysis and software evaluation and selection to  design, system configuration, rollout and support. Proven methodology helps to reduce the margin of error and ultimately saves the  client time.
  • project management skills are important in planning, budgeting and tracking, and critical in managing “scope creep.” Project management skills are critical in areas such as IT risk management and identifying and recommending solutions to issues as they arise.
  • social skills are important since enterprise-scale IT projects involve different stakeholders with competing agendas. Members of the implementation team must be able to communicate with people at many levels and in various functions within the client organization. Some of the members must excel in facilitation skills, particularly when the group must reach a fact-based consensus. They must be able to work without showing bias towards certain stakeholders or software packages.
  • user acceptance often will “make or break” an implementation. Fostering user acceptance requires organizational change management expertise, something often overlooked during large IT projects. Organizational change management activities should occur throughout the software life cycle, and include much more than training. Read more about organizational change management here.

If you contemplate starting an IT initiative in the EHS arena, or to manage other subject matter, make sure that you have a professional leading the effort. Hands-on experience in the above areas can increase the probability of success in software implementations. Of course, these are a select few of all of the skills required. Read more about IT program management here.