Your System – Not Guilty As Charged

Just another WordPress.com weblog

Keys to Successful Software Selection and Implementation

Posted by Joel Schipper on January 29, 2016


Aiming to Achieve Your Executive’s Expectations

I discuss the best way to select and implement software to achieve the expectations of your top executives below, and you may also follow it with these slides in PDF  Keys for a Successful Selection and Implementation – Leading to a Great Reference v3 C16

Many software implementations take nine months or longer, resulting in higher internal efforts and costs, a delay of return on of your investment, the risk of obsolescence of what eventually gets implemented, and even a competitive disadvantage by falling behind faster moving competitors.

Much has been written about the processes required to execute the selection, how to manage and deal with vendors, required internal staffing, and proper communications.
Today we will learn about reaching towards the expectations of your executives.

Managing the scope of the selectin and implementation with regard to what will help your business is key to an effective system selection.  You must identify the executive expectations for the system’s ROI.  Is your system selection directly related to that ROI?  Are the project plans and tasks targeted to achieve that ROI?  Are your accomplishments being measured against that same ROI?

Make sure that your project is being driven against the expectations of your executives.  For example, those could be

1 – Accomplish Corporate Mission
2 – Drive Revenue and Make Profits
3 – Minimize Risk to Shareholders and Capital

Whatever they are, make sure that your system selection evaluation is focused only on accomplishing those objectives.

Begin by articulating what those goals in more detail:

  • How do the executives plan to accomplish the corporate mission?  By gaining market share?  Being first to market? Becoming a global competitor? Having the best customer satisfaction?
  • How do the executives envision driving up revenue and maximizing profits?  By developing new sales channels?  Lowering COGS and/or S&GA?
  • What are the techniques they plan to use to minimize risk to shareholders and capital?  Through better regulatory compliance?  By extending asset life cycles?

The answers to these questions will must be expressed in measurable terms, or else you won’t know if the implementation was successful.  Discover the right measurable quantitative or qualitative terms, whether they be in dollars or ratio‘s, survey results, or perhaps the executive compensation metrics in the 10K report.

For example, a goal could be to reduce inventory by 5% or by $50MM year over year.  Or improve Quality by lower Product “A” rework incidents by 10%.  Or raising average annual customer quality survey scores to 7.5 (out of 10) and then by 0.2 annually.  Or by increasing product upsells by 20% or taking orders in 2 minutes or less, or with fewer clicks.

Know what you’re going to need to measure, and understand how the new system will support these measurable goals.

Examine software features that are critical to achieve the executive expectations.  For example, what will help

  • Reduce inventory levels?
  • Improve quality results?
  • Examine features critical to process improvement or transformation?

Be specific about what is required so you can link the executive expectations to the software selection.

Finally, rank the executive expectations.  Some are most important … some will be easier to accomplish … some will be a stretch.  Agree on an achievable set of expectations to balance the

  • Effort to achieve
  • Level of reward
  • Risk of failure (or probability of success)

Beware that a common pitfall is to only focus only upon easiest, fastest goals; that is a danger you must avoid as the easy returns are not usually the ones that make a real difference.

So, the net result at this point is that you have the list of “must-have” or “required” features.  The list is defined deep enough to reveal critical features for executive expectations and for business improvement or transformation.  Vertical indusry requirements should be the baseline.  References and conference room pilots will ensure the software does what you want and expect it to do.

All other features are simply “foundational.”  “Foundation” and Nice-to-have features are not your focus.  Please do not spend your time in the selection analysis checking on features that all of your software candidates should be able to do, such as making balanced G/L entries, supporting at least 12 G/L periods, providing 3-way match of PO’s to AP Vouchers, etc.  None of these will drive your results or “move the needle” unless you are converting from Quick Books or a manual system – and then, likely all the systems under consideration will perform all of these ‘foundational’ functions.

You should, of course, use a “usability” review or demo, and reference calls, to confirm that all the “foundational” functions work as advertised.  You likely have a new generation of executives who have grown up under ERP and are looking towards the differentiating features.

This means you can “ditch” those lengthy RFP’s (requests for proposal) that are chock full of “expected features.” This is simply not a helpful exercise, but rather is a clear waste of time and money for you and the software vendors.  “Foundation” features are just that – part of every quality modern system foundation.  Focus only on the critical features for your industry, your business goals, and your future growth and expansion.  This will let you stop making software decisions based on long demo’s or lengthy “scorings”.

Recognize that partner products will usually complete the solution, and must involve proven integration with strong, well-known and supported integration tools.  Also, be sure there is a clear source of support and trouble resolution between the various vendors.  You don’t want to be the clearing house for support issues!

Now that we’ve agreed to focus on the critical functions that will differentiate the software vendors from one another, there are three keys to making the right selection for you:

  1. Software Usability.
  2. Software Architecture.
  3. Corporate Technological and Financial Viability.

Be sure to include all the partner solutions that make up the total “stack” in this analysis.  One weak link can ruin the entire party!

To verify software usability you dig into actual experiences through customer references.  At least one reference visit must be on-site with the reference customer.  As far as demo’s go, you should love a demo, or else the software vendor is failing miserably at a core component of their sales process.  Rather than do long demo’s, you are better off with a paid proof of concept as a more valid test of the required software features.

To pick the right software architecture, determine which of these three business environments fits you best, and only pick software from a vendor that matches your environment.

  1. IF your business processes are fixed or change very slowly, the consider a “mostly there” base point system that is easy to customize.  You should expect to live with this adjusted base system for a long time.  In my opinion, MicroSoft Dynamics is a classic example.
  2. IF your business processes are very complex, but won’t change much over time, then consider a system with vast features and configuration options, and expect to live with this adjusted base system for a long time.  In my opinion, SAP is a classic example.
  3. IF your business undergoes constant change, or is growing rapidly beyond your ability to accurately forecast future requirements, then you should only consider a system clearly capable of on-going growth and change.  Plan on staying “current” with vendor releases by using with modern upgrade practices.  Take advantage of application modules not in your initial implementation.  And, take advantage of technologies not needed today, such as the “Internet of Things.”  In my opinion, Oracle’s JD Edwards EnterpriseOne software is a classic example.

To confirm corporate viability, both the corporate and software roadmaps are critical.  This area requires extra digging and confirmation, since “talk is cheap.”  The future system life expectancy SHOULD be 5, 10, 15, or even 20 years unless you plan to exit your business sooner.  The underlying software technologies should point to a long future.  Find out through references what will be the required human and technology resources to maintain the system.  And be skeptical of closed, proprietary technologies; so many have become dinosaurs in the past.

A long corporate viability roadmap is an absolute must-have condition.  If your vendor is a public company, dig into the 10K SEC reports.  Consult your CFO to discover if there are financial viability issues.  Understand “exit strategies” for vendors funded through Private Equity.  And beware of Wall Street and analyst reports that are paid for explicitly by vendors, or where the vendor has a cozy relationship with the analyst.  Corporate viability analysis may be the #1 mistake in software selection.

Everyone needs to be part of this project, so don’t hide it off with a small team.

With the work you’ve done so far, it should be “easy” to find your final three vendors (if there are three) because they each will have:

  • Corporate viability
  • References for software usability
  • Budgetary limits from initial quotes
  • A successful “navigational” or “sizzle” demo in which you expect to be “wow’ed”

For your ‘real’ demo, use a scripted demo.  Scripted demo’s put you in charge of what you want to see – or what the vendor can show.  Realistic vendor data is fine; they don’t need to replicate your customers, items, bills of material, etc.  You are concerned with the business process scenario; customer friendly data doesn’t change the functionality.  Rather, the vendors must show every critical feature.  Do not take simple “yes” answers when judging critical features.

A long time ago, Sun Tzu said “In war, then, let your great object be victory, not lengthy campaigns.”  If you set up a process where three vendors each provide a 2-3 long day demo’s, the result will be exhaustion of your selection team.  You will forget what you’ve seen, and it will all blur together.  Remember that demo’s are only for the critical features necessary to achieve executive expectations.

Other good practices to avoid a lengthy process include having a fully budgeted and approved project before beginning the software selection; re-checking usability and viability for vendors that can show the critical features; and remembering that each day is one more day before beginning to achieve goals and benefits.

A four month time is possible.  Developing the RFP could be done in 2 weeks if the executives are available, or certainly after you’ve digested their critical expectations.  The vendor Response can be held to 3 weeks.  Creating evaluation documents and finalizing demo scripts can be done during this time.  RFP evaluation, customer visits, and follow-up can happen within 3 weeks.  Vendor demo script preparation (and finishing customer reference visits) occurs during the next 3 weeks, and the scripted demos and detail follow-up happen in the subsequent 3 weeks.  In the end, final Evaluation and Selection should take only 2 weeks.

You may need to look at some tie-breakers if there are too many good choices!  These can include:

  • Support services that cover your time zones, global geographies, language skills, and the number of years before a release is “unsupported”
  • User groups and input to vendor “development” are important as you’ll want plenty of company, and a voice to the vendor
  • Implementation services, including a robust eco-system of implementation skill sets to avoid reliance on any one resource
  • Contracts that make clear just who is responsible for your system.  Beware of ‘mixes’ of developers, partners, and resellers
  • Subjective evaluation of “Ease of Use” when all finalists are usable; just don’t let your lowest level workers drive the system selection, unless they are saying that the system is too clumsy or difficult to use.
  • Technical Viability of the Platform/Environment/Company

If your mix includes Software-as-a-Service (SaaS) Cloud vendors, then consider these additional factors, as these products generally provide best-of-breed practices, and are well suited when there is no mission-critical differentiation in critical features needed for you.

  • The same rules – usability and viability – still are in play
  • Add extra weight to integration approaches, service level / availability, and security.
  • Can you customize, and how?
  • How can you add third party software?
  • What are the reporting tools and business intelligence offerings?
  • How is auditing and SOX requirements handled?
  • How/when do you upgrade?
  • Will older versions be allowed?

Once you’ve made your selection (and purchase), it’s time to build a project plan to implement that software in light of your goals.  Be sure to:

  • Measure progress against original expectations
  • Make sure your implementation plans correspond to your original selection goals.
  • Determine what and where to implement to accomplish each goal.
  • Balance the effort to achieve with the level of reward and risk of failure (or probability of success)

Link the goals into project plans and closely monitor them.  Include user training, user acceptance testing, and stress testing in your plans.

Remember to measure your results.

  • Each goal has been linked to software features
  • The measurements of success for each goal were defined in the beginning, so use that as a baseline
  • Publish the new measurements to everyone, being very public about the results
  • Feature the measurements in the Steering Committee meetings and reports.

Remember:  “What is measured is what will be achieved.”

  • Publish your successes and explain your failures.
  • Publish corrective actions
  • Use incentives to drive achievement
  • Reward both achievement and the time to achieve
  • Use competitions and gamifications as appropriate.

And finally, if the project is having trouble or is delayed, consider:

  • Reviewing which goals are at risk, and attack problems starting with the value of the delayed goal
  • Using proven, team problem solving techniques
  • Revising project plans to reflect realities “on the ground” and move timelines rather than goals
  • Keep measuring and publishing results and reasons

And have some fun along the way!

Advertisements

2 Responses to “Keys to Successful Software Selection and Implementation”

  1. Listening to Ed Kubulins talk about successful software sales at the JDE Summit 16 in Denver today. Ed notes that the #1 thing in a software selection is to KNOW YOUR requirements, and make sure the software has functions that MEET YOUR requirements. And with Google, you can easily find the “top 4 things for chemical distribution ERP” or “5 must have reports for distributors,” etc. So in addition to listening to your executive expectations, get ready IN ADVANCE by doing this Google research and be ready to bring those to your ‘executive discovery.’

  2. Address the real life needs of the customer. A friend who is a former Controller knows what made her life crazy each day at work. And now she starts each software demo by directly addressing those issues, showing precisely how the software will smooth out those daily ups and downs, and provide the metrics and reports that top executives demand each month.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: