Four keys to effective software evaluations on your IBM i:

Posted by Paul Hodgkinson on Sep 15, 2013 11:35:00 PM

   

An effective software evaluation is key to success...

Purchasing software has always been something of a risk, however in today’s climate there is more pressure than ever before to make the right decision.  With a reported 70% of software projects failing to deliver the pre-purchase objectives, it seems easier to make the wrong decision than the right one.  I believe there are a couple of significant reasons behind this failure rate:

  • Projects are not often clearly and realistically defined prior to the evaluation process
  • Business users are rarely involved in the process

If we address these fundamental issues, I’m convinced that a significant majority of software projects will be successful.  The evaluation process is of vital importance in turning this around, so here are my four tips to a successful software evaluation:

 

1 define the problem

1. Don’t look for a solution until you have properly defined the problem

You wouldn’t start test driving cars before narrowing down the decision-making criteria:  Size, safety, comfort, price, manufacturer, fuel efficiency, on/off road capability, warranty and value retention are variable across models, and each buyer places a different emphasis on the range of features available.  Given we are so meticulous about decisions in this context, it seems strange that anyone would embark upon the purchase cycle for a software solution (which is generally way more expensive than a car) without first defining exactly what they want from the purchase.  Yet a large majority of IT decision makers seem willing to skip the initial planning process, leaving themselves to be influenced by the marketing spin and selective education of software vendors.  A clear set of requirements allows for objective comparison of solutions, resulting in a scientific rather than emotional decision.

 

planning

2. Involve your end users in the planning and evaluation process

Whilst it’s important that a software solution is technically and architecturally sound, it’s at least as important that it increases rather than decreases user efficiency, capability and satisfaction.  We see so many businesses miss the opportunity to significantly improve the productivity of their staff – as well as to drive down costs – because they implement a solution without ever properly scoping user requirements.  If you’re willing to invest just a few days observing users at work, and brainstorming with them on how technology could best support them, you will save yourself weeks spent retrospectively adding customizations and features that could have been included in the original specifications.

 

explore facts

3. Don’t let a vendor or “expert” tell you what other vendors can or can’t do – find out for yourself

I regularly read and watch the self-proclaimed AS400 luminaries mislead the community with their claims of what is and isn’t possible with i applications.  The web versus native versus hybrid mobile debate is a case in point, where in their ignorance vendors and commentators wrongly assert that web applications have no access to device features.  Whilst it’s a pleasing part of my role to be able to demonstrate web apps accessing the camera, GPS and accelerometer to great effect, I’m angered that the ignorance or self-interest of a pundit can result in businesses making poor and ill-informed decisions.

The only reliable source of information on what a piece of software can or cannot do is the vendor themselves – and even then I’d encourage you to request a demo to confirm that what you’re seeing is not just marketing smoke-and-mirrors.  It can seem prudent to enlist the advice of an industry big-hitter when making your decision, but don’t substitute this for a direct evaluation of the different options.  You may well discover that the “expert” is not quite as clever as they think!

 

Proof of Concept and Prototyping

4.Define a small project that incorporates all of your requirements, and ask each vendor to deliver a proof of concept

Software evaluation is a science – not an art.  Many vendors will offer the chance to download their software and play with it for a trial period, however there are two problems with this:

  • You’re generally not trained to use their software, and so are unlikely to get a true representation of what can be achieved when the software’s used to full effect
  • Unless you clearly define what you want to achieve with the trial and then measure every option against the same criteria, you’ll never get a global view of which one best meets your specific requirements.  You’ll only be assessing your gut reaction to the look and feel of the tool.

Don’t be afraid to ask the vendor to do the work for you.  This doesn’t mean that you shouldn’t seek to understand what’s involved in creating a solution, or indeed how much work will be required for you to become competent with the software offering – you definitely should make yourself aware of these things.  It does mean though that you will see what can be achieved by the software at its best, and if you ask for a run-through of how the results were achieved you’ll have a good awareness of how long it will take you to get there yourself.

There are very few guarantees in life – and software is no exception – however if you take a measured approach and employ the tips I’ve outlined here, you’ll greatly improve your chances of making the right decision and achieving that elusive successful implementation.

 

Here is another great resource for you as you progress with an evaluation of your software: http://www.cio.com/article/731773/How_to_Choose_the_Right_Software_Vendor.

Or request a free assessment with looksoftware and explore the possibities today! http://go.looksoftware.com/assessment



Paul Hodgkinson blog image

Author
Paul Hodgkinson
EMEA Manager, looksoftware

 

Topics: IBM i, Application Modernization, Application Integration