Picture this; you are supporting an application and a user rings you on the phone exclaiming "The application doesn't work!" What is the user stating and how do we resolve their application issue?

A majority of users believe an application is at fault when they cannot perform a certain task or get an unexpected result to their interaction with the application. There could be a number of reasons for an application error or an application failing to perform as the user believes it should. To resolve any reported issue you need to put aside the user's assumption that the application is at fault and methodically diagnose the problem. I use and recommend the following steps in resolving a user's application issues:

1. Get a clear description of what the problem is from the user.
2. Focus upon the user's interaction with the application. What we are looking for is training issues where a user is not getting the result they want because they are not using the application in a prescribed way.
3. Ensure that the data the application is working with is of a high quality. Dodgy data can cause some applications to behave in unexpected ways.
4. Finally scrutinise the code and see what the application is doing.

First, we need to know what the user was doing when they reported the problem and how the user was notified that the application was not behaving in the way they expected. For example; it could be that another employee was showing the user something and mentioned that something did not seem to be working as "they" expected.

Second, we need to focus upon the user's interaction with the application. Is the problem a training issue? A user may have performed an action the application did not expect or they may have not followed a series of established steps which they have been trained to follow. Why would there be no checks and balances built into the application to apprehend user mistakes? Usually the budget allocated to the development of an application will determine how much work the application will do for the user and how much of the solution will depend upon user training. If the original solution was that the application would not need to check the user's input and that correct input would rely upon user training then the user's problem may not be an application issue but a user training issue.

Third, we need to look at the quality of the data the application is working with. If the application finds data in a format it does not expect then an error may occur. Perhaps a report relies upon it's data-source to decide the number of columns it should display and suddenly there are one too many columns being displayed. Data issues can easily masquerade as application errors but at some point data issues are usually due to a reliance upon user input or scripts that create data. I once had an application fall over because the data warehouse changed the format of the data it provided. At this point it is either a user training issue or vendor training issue and not an application issue.

Finally if all the above investigations have not resolved the reported issue then it is time to look at the application itself.

So many times in the past I and others have gotten caught up in trying to resolve phantom problems within software only to find it was a data integrity issue or user training issue. It is quicker and easier to follow the above steps in their respective order and remove all doubt as to the cause of the problem before scrutinising an application's code. If the first thing you do is concur with the user that the application is at fault even when it is not, the mud will stick and the user will begin to distrust the application which might be perfectly fine when it's data is correctly entered.