Why do I need training ?

In recent times there has been a hue and cry that Corporate IT systems still need users to be trained on usage and functionality; the underlying hypothesis is that if one can adapt to all the social media sites, shopping portals and various mobile apps, why do corporate IT solutions require formal training as well as guides for users to struggle through them ? Why cannot the ERP, CRM, SCM, DW/BI and other systems be user-friendly enough for anyone to intuitively start using the application ?

Consultants, experts and companies have mushroomed claiming to help enterprises de-clutter and make friendly even the most complex transactional systems. They come in with variety of tools and review the problem from various angles and dimensions. These UX experts in many cases are able to create improvements with increased usability and thereby deliver the intended results. However these have been limited to websites, portals and in a few cases custom and bespoke applications.

Over the last 20 odd years of the existence of enterprise applications, the change in the user screens has evolved with changing functionality and technology. From green screen to client-server and then onto the browser, the change has been not too significant even when you consider all operating systems and platforms. The top 5 enterprise application screens today have changed only to incorporate different buttons and tabs, and maybe with a drop down or look ahead search; the rest remains the same.

Then how is it that new generation applications have broken this paradigm such that they have been embraced across geographies, age groups, user communities, and consumers and corporates alike. What makes these web and mobile apps so intuitive, easy to the eye and deft of click or touch ? No one ever provides training nor does anyone ask for it. Have the big name vendors no interest in easing the pain of using their apps ? I do not for a moment believe that they are immune to this phenomenon.

So I did my bit of research talking to the vendors attempting to unravel this mystery. Without exception, all of them acknowledged the problem and cited special interest groups, advisory committees and even empanelment of experts to solve the problem. I also got myself invited to a couple to ascertain the steps and direction, and with a desire to help. Using eye ball trackers, cursor followers, semantic parsers, and a horde of techniques beyond my comprehension, they attempted to sweeten the pill.

We all know that the gap continues to exist, the unrest with the user community increasing and the helplessness maintaining status quo. None the wiser after a few years of participation, I parted ways and started challenging my team and developers to create intuitive interfaces to apps. Easier said than done; while I did not like what I saw, with no bright sparks for improvement, the teams soon ran out of ideas and enthusiasm to pursue the nebulous goal. We did create some improvements, but they were nominal.

Only recently I had my Eureka! moment that the twain shall never meet, the usability mountain will remain unconquered for some time to come, and we will continue to struggle with training for every app, big or small, custom or off-the-shelf, that we deploy within or outside of the enterprise. The reason is obvious but not staring you in the face until you think hard about it and then some more. It will not come to you intuitively (at least it did not to me).

With tablets and mobile becoming mainstream compute screens and apps for specific processes connecting to corporate apps, the dependence on the conventional corporate IT solutions will reduce. Does this put off the pressure to simplify the usability of systems from the vendors ? Yes and no; most have taken on the opportunity to create their own apps retaining the customer and the corporate security needs. 

Corporate apps expect structured data inputs for business with defined boundaries and validated masters; they are input heavy and work in secure environments. Whereas consumer “friendly” apps mostly deal with unstructured public domain data which is viewed by many, input by few. The divergent needs keep them independent and their evolution following different paths. The CIO has to manage expectations at all levels and educate the enterprise on what reality will be for a long time to come.

Requirement gathering, the saga ends

A heated debate ensued between the two project managers, from the development vendor and the customer respectively on change in scope of the project. This was not a late stage discussion or changes requested during UAT; in fact the project was just a week old with the Requirement Specifications still being formulated. The key user who was also the subject matter expert sat through the charade wondering where she should step in. With no resolution visible, they all decided to go to the CIO for arbitration.

It was supposed to be a quick win project that typically delivers what everyone refers to as low hanging fruits. The project brief was a working model on a spread sheet of the solution to be developed. So it was assumed that the solution should be easy to create and scale up. The timelines and costs were agreed to and the vendor team arrived on site to finalize the project scope and integration points. So what could be the reason for the conflict ? If something is working, how can requirement change ?

The CIO heard the point of view from each stakeholder, the user, IT project manager, and the vendor. For the user, she had clarified how the model worked and what was expected from the system that the spread sheet was unable to deliver; the IT project manager stressed upon the integration to various masters and the scalability expected of the solution; and the vendor project manager completed with a complaint that some of this was not in the original scope that was outlined prior to commencement.

So what was the issue asked the CIO ? Wasn’t the current discussion to clearly define the functionality expected from the system ? Where is the conflict in the integration definitions ? Does expansion of the concept and explaining in detail qualify as scope enhancement ? They had an advantage over a standard software development model that a working prototype was available. There was a discomforting silence for a while until they all decided to go back and close the discussion amicably.

So when I bumped into the CIO many months later, I enquired about his story from our last meeting. He mentioned that it had gone live but did face challenges in the initial days. This was discovered during deployment that the system needed elaboration.  The functionality was evident common sense but missing from the system (I shall not get into the details here which my CIO friend explained to me to my surprise). He quizzed the team for the missing parts of the whole; the user said it was obvious, the PM agreed, the vendor did not.

It is not in the system since you did not ask for it. Technically correct but does not solve the problem. So now that the system is accepted, deployed and support phase over, this is a Change Request and will have to be managed as such. The ineffectiveness of any argument was evident and the only recourse was to give in to the demand in the interest of the project and the business. That vendor has not been welcome to new initiatives since then; even the support has been moved to other partners.

My friend the CIO had no recourse ! Do we ? With the outsourcing trends taking the direction that they have, everything has to be now explicitly stated and included as a part of the Requirement Document. If you do not have an internal team of business savvy IT team members actively involved through the cycle such outcomes are quite likely. Invest in your team, keep them actively involved in the project and not just to manage at a high level. Keep a watchful eye open. Assumptions hurt; try “ass u me”.

This is hopefully the last post in this series. If you would like to see the earlier ones, they are linked below:

Part 1

Part 2