- How long did it take them to model your source? This will give you an idea of how much time it will take if you were to implement their software and the amount of resources (internal) you will need to tie up with it.
- How much customization they have done in order to show you a working model?
- Level of complexity. After watching what they have done, are you going to be able to do it yourself in case you want to modify or add new process for any reason in the future?
- Try it yourself. Ask them to allow you to setup the same process yourself with the ability to ask questions while doing so.
- How did they setup reports? Can you setup/modify the report yourself? If you can’t gauge that then ask to try it yourself.
- Can you run what-if scenarios reasonably easy?
- Are you going to end up saving time? Are you going to enhance accuracy? Are you going to be closer to compliance with this software more than with what you are currently using?
IS MY SOLUTION SUSTAINABLE?
First, let me start by defining what I mean by sustainable. In its simple form, Merriam-Webster dictionary defines sustainable as the ability to last or continue for a long time. This is the definition that I am referring to in this blog, not the traditional three aspects of sustainability: social, economic, and environmental. So having clarified what I mean by sustainability, let me put this now in the context of this blog. In this blog, I will be discussing if your current (or to be) Environmental Management Information System (EMIS) application is sustainable; i.e., are you going to be able to keep it and maintain it for long time without costing you an arm and leg? How do you make sure that you end up selecting the right system that will work for you and not become a burden on your company? Is there certain criteria that you can apply which will help you with your selection?
After many years of experience implementing EMIS solutions for different companies, the one common thing I noticed time after time is the challenge (and sometimes the disappointment) that clients face after going live. During the implementation period (which could last from few months to multiple years), everybody is busy configuring, customizing, training, meeting deadlines…etc. Once the system (or a phase of the project) is delivered and in production, everybody is happy and relieved until the client start using the system on their own. That is when the rubber hits the road and frustration bubbles up to the surface.
The problem with the environmental market in general is that it is fragmented; requirements are different from one industry to another and even from one company to another within the same industry. This means that you will not find one application out there that will fit all industries without some sort of customization. Some software companies claim that their software is highly configurable, yet in reality they are highly customizable – in my opinion creating new database objects would be considered more of a customization than configuration (who’s going to maintain this customization after the go –live?). Other software companies allow customization to the front end via coding in order to meet clients’ requirements, again more customization and the struggle to maintain it and the need to perform rigorous testing every time you apply an upgrade.
After introducing so many customizations to make the software meet client’s requirements, the result is a monster application that not only requires a lot of effort to maintain but also very complex to use. This is when you will see consulting services tied up with clients for long time after go-live to support these changes and sometimes even help in simple tasks like modifying a process or updating a report.
So how do you make sure you do not end up in a situation like this? This is not a simple question to answer because it often involves other considerations related to your data & processes that you will need to prepare before you start looking at software (I will leave this to another blog). But for now, I’ll focus on the selection criteria that will help minimize or cut down post production issues.
To reiterate, in my opinion customization is the main reason why we end up with a heavy system that is difficult to sustain. On the other hand, you need customization to make the software meet your requirements. So what do you do with this dilemma? The answer is, you make sure you spend enough time understanding all about the systems that you are considering before you make the selection. Here is what I suggest you do when considering a new software to implement:
Ask the vendor to model a process that you currently have (for example give them a source with medium complexity and ask them to model it in their software). When you meet with them next time, ask for a live demo to show you how they configured the system (do not accept PowerPoint presentation only) and observe the following:
This is a quick checklist that will help you gather more knowledge and insight on the software which you are evaluating. It is not a comprehensive list by any means but definitely a good start. Finally, I am not claiming that there is one system that will meet all your requirements, the point that I am trying to drive is not to take the software capabilities for granted. Make sure you verify and test drive before you commit. The time you spend at the beginning is so much worth it compared to the pain and cost that you might end up dealing with due to a wrong selection.