A common situation today is that the business units are purchasing SaaS services, secretly without knowledge and/or acceptance of the IT department. The reasons for are many, but at least that they:

do not believe that IT will give them a permission to order the service,

are afraid of that IT will offer some custom-tweaked Intranet setup,

will get “similar” but inferior service, eventually when IT gets time to do it.

How did we reach this point?

I would say that lack of understanding and the illusion of total control are to blame. Similar findings can be found on a recent publication of University of Turku, SaaS Handbook, consultant company Sulava’s Marco Mäkinen’n video about the shadow IT, and in an article in Tietoviikko (the leading Finnish IT professional paper). I’m sorry that previous references are all in Finnish so you just have to take my word for it or use Google translator 🙂

I’ve been thinking this issue a while and my opinion is that the biggest problems are following:

Firstly, IT says “No” because it does not understand the business problem at hands or the benefits that the chosen SaaS solution would offer. As IT professional myself, I too used to start with listing problems and risks whenever a new service was presented to me. I did not believe that the solution would solve the issue because I just simply did not understood how much this would actually help the business units. Ok, I did some soul-searching and found a reason for My Inner Problem Troll. I have had such a bad experience with implementation of new software services: sales cycle is long, price is high, laborious server procurement and installation, mandatory customization and integration projects, bad end-user training experience, and poor usability. And very often after the software implementation project nobody wants to actually use the product – and everybody is feeling sick and tired of it. These experiences lead further to the problem number two.

With an engineer style, we often tend to overdo things and aim for perfection and making everything ready at once. Very typical at least in Finland, Nokialand. The new service must be fully integrated to other systems, the information must not be in silos in the different systems, the service must perfectly adapt to our processes (how outdated they ever are…), and on top of that it must adapt to changing business needs, and finally, the implementation must happen to all personnel at once. Phew. Everything has to be one complete solution.

When the chosen service is finally in production, the business need may have changed and therefore nobody wants to use the service. Summarized; all the integrations, customizations and implementation took too much time and way too much money.

The price of the traditional software product will easily lead to the problem number three.

Does this sound familiar? Because the purchased product was expensive and the implementation was painful, you desperately want to use the licenses and servers for almost any problem you encounter – even if there are better (and less expensive) solutions available. In other works, it is easy to end up trying to save money by using one single product to solve the various needs.

I dare to argue that by doing this way you will end up saving money from the wrong end. As an example: how many of you organize events by email and Excel sheets? Did you know that there are alternatives? If you count the hours you use for excel work and emails and compare this to services like Lyyti (this is a Finnish service) we don’t need to be a Nobel awarded mathematician to understand a) the cost savings and b) increased value to the event participants.

How did we end up here?

The need to control everything, futile (and expensive) perfectionism, fanatic avoidance of data silos and emphasis on the potential risks instead of the benefits have led to a situation, where SaaS servicesare purchased without the acceptance of the IT management.

So what can we do about it? A lot! The solution is not to add more technology or interfaces.

Software production companies have already accepted that agile development and early trials are the way to get a product that is good enough for the actual business needs and the schedule. So why would IT department want to act in a way that is suspiciously similar to the waterfall method? I would highly recommend added agility and demo mentality are also tested in the IT departments – SaaS services are very easy to test and experiment!

If a SaaS product does not meet your needs, it is really easy to skip it and test another one. The testing of new services costs way less than you think and it gives you possibilities to react to actual business problems – and not only to the problems that you can afford, have time to solve or know how to fix!

Researcher Antero Järvi from University of Turku said this to me when I asked about how to integrate SaaS services to the rest of the applications: “Don’t integrate anything before you use the service for a while and evaluate if you even want to continue to use the service.”