Software

IT departments spend a good time to justify the return of their investments. However, software investments, taking a significant portion of the investments, are often neglected. Considering that the Pareto rule is in place for software use as well – 20% of the users use 80% of the application, or 80% of the users use 20% of the application etc.- CIOs need to rethink about improving the return on software investment.

Let’s start the evaluation before we purchase the software. Why do we invest in making an investment on the software? Is it creating operational efficiencies, automating a manual process, solving a business problem, building opportunities? What is the value that it is adding? If we cannot answer the simple question of adding value, then the investment may not be justified at the first place.

Next comes the training. Many software vendors direct users to the Frequently Asked Questions (FAQ) sections or the support forums on their web sites. However, user manuals, product documentation, extensive help files, end user and IT support trainings are often not mentioned. If the vendor does not have solid training programs in place, we can be pretty sure that hard times will begin immediately after we invest in this software.

Following the training, we have to evaluate that we have service, support and development solutions the vendor provides. Our vendor should have clearly defined service and support terms, which should also be translated into Service Level Agreements (SLAs). The SLAs should be stated in the contract, not  just in the vendor’s website and nowhere else.

In the past, the tendency was to select enterprise resource planning (ERP) applications, which are monolithic, expensive to maintain, lock-in systems that allowed “my way or the highway” type of integration with other systems. Today’s computing environment is exactly the opposite: the vendors compete on making their applications compatible with other applications. When choosing our software, we have to make sure that it easily integrates with our existing solutions. If in doubt, we need to ask the vendor what integration features it provides – native, APIs, export/import etc..

Continuing on the ERP systems, one of the benefits that they provided was scalability. The applications could scale up and scale out without any problems. The first thing that we have to look for in the software is the scalability. The numbers that the vendors could be high, but these can be deceptive. Imagine a vendor offering a 5000 page limit for your company knowledge website, which you are evaluating for 200 knowledge workers. It is obvious that 5000 looks big at the first sight, but making the small math it translates to 5000/200 = 25 pages per knowledge worker, which will definitely expire very soon.

We can also think about scalability in terms of accommodating further business requirements in today’s environment. Suppose  that we are evaluating a customer relationship management application for our enterprise. We have designed our workflows, the application can hold, process and report the data without any problems. However, if it does not take into account today’s mobility and portability requirements – if it does not support mobile communications, mobile workflows, does not have mobile security, is not optimized for mobile viewing -, and if the vendor still does not have those features in the roadmap then the application is definitely promising rough times.

To ensure that we will be able to use the application for some years to come, we need to ensure that the contract has [1] new features and enhancements [2] less than 5-year terms. These two items are closely tied together. A lot of changes happen in the business environment and they come out of nowhere. Our software has to roll out features that can answer such changes and it should have less than 5 year, preferably yearly renewing terms. If these options are not available, we have to negotiate a 3-year contract or an opt-out option. Failing to do any of these will most likely cause our company to get stuck in the application and result in painful update, maintenance, support processes in the future.

Next, we need to discuss with our IT team on the time they require to deploy the application. Given that we have some time, it will be a good idea to get the evaluation version and try to deploy to a couple of computers. That way we will be able to identify how long it will take for deployment and if the deployment will have any impact on the mission critical applications.

Once we decided on the application and deployed it, we need to measure the use. To be frank, there are very few companies that measure the use of the software. But when they do, they cannot believe the results. One of my clients deployed an application that provides business writing templates to 2000-plus users; on Remote Desktop Servers, on laptops and desktops. During deployment, I asked them to carry out the necessary work to track the use on System Center Configuration Manager (although they did not believe it is necessary, they did not turn me down). After one month, when I asked them to check the telemetry, it was seen that the application was only run once, which was immediately after it is deployed!

Finally, we have to evaluate the application with our IT staff. Is the IT staff satisfied with the application? What is the state of the support requests from the end users? What is the vendor’s expertise? Is the vendor willing to give a hand or is the vendor “just doing its job and nothing more?” In case of any dissatisfaction, we need to arrange a meeting with the vendor and take actions to iron out any issues that we are having.

Taking these steps carefully will ensure that we are improving our return on our software investments. What steps do you take to maximize your investment? We’d love to hear your comments.

Web Hosting Geeks’ Blog