Problems caused by user error/competence 4

[jrbarnett]

At a former employer of mine, a colleague and I co-developed a piece of software for a client to replace a very successful DOS application (also developed by my ex employer, but not me). From his point of view, the old application, being DOS based was classified as legacy although it did everything he wanted and he was happy with it and knew his way around.
The specification from him for the new software was very loosely defined, basically being "Build a Windows version of the DOS software" and nothing else. Running the old application in a DOS box was not acceptable from his point of view even though he had done that for years and was comfortable with doing it.

Since initial test versions were provided for him to provide feedback about 3 months after we started development work, we had serious problems. They weren't software bugs, but were caused by his incompetence when it came to computers and IT. From our testing, We knew it worked in the office, and at his premises when I went to install it and provide initial training because colleagues of his were able to get it working and use it quite comfortably.

His computer illiteracy is not confined to this piece of software though. I have dealt with a number of IT support calls from him relating to simple use of Windows applications. For example:
* He doesn't know the difference between a right and left mouse button click.
* He is unable to comprehend the fact that minimised windows can be accessed from the Window menu and don't need to be opened again, or those opened afterwards don't mean those opened earlier have closed.
* He doesn't seem willing to accept that an Access hosted database application will look different to a DOS text mode application developed in Clipper.
* He doesn't understand that antivirus software with two year old signatures is able to protect him from current viruses (I have fixed many by editing the registry on his PC, rebooting and deleting the files later. He won't fork out for a new package or even accept a free one as an alternative).
* He has asked me how to edit his signature in Eudora several times.
* If something didn't work with his system, he would go into control panel and fiddle using options he didn't understand so as not to bother me, then phone up on the end of his tether and I would end up fixing something more serious than it was to start with.

I could go on, but I'm sure you get the gist of my argument. Basically, from my and my colleague's point of view, he was the nightmare user on both development and support calls. Shortly after some of the beta versions, my colleague and I (and sometimes the managing director as well) started getting emails from him using very strong language, written in full caps, on a daily basis criticising the software, claiming we hadn't looked at the old DOS system in implementing its Windows equivalent and we were incompetent.

The upshot is that three years after development commenced, and about 18 months after we were completely happy with the application from my ex employer's point of view, he is still not happy with it and insists on running the two in parallel wanting to see identical results from the reports in each system, but only entering the data into one of them and can't see that this will produce different results in the same reports.
By the way, the client still uses the old DOS system to run his business.

Has anybody else had to deal with serious acceptance problems caused by user error or luddite tendencies? How have you got around it? Any suggestions would be most grateful. Unfortunately, telling him to get lost and ceasing contact is not an option.

John

 

[BJCooperIT]

Now you have opened a can of worms! Prepare to be bombarded with e-mail.

I had a user who was force-fed a new system by management when he was perfectly happy with the legacy system. He went kicking and screaming all the way. No longer could he play his little games with flat files on the mainframe and modify the reports to come up with the totals he wanted (not accurate totals, just the figures he wanted to present to management). He did not know Windows, or Oracle and despite a lengthy acceptance and training period declined to learn. After all, he was a busy man.

He was scheduled to present the system to the users in 5 one-day sessions (Mon-Fri). He announced on the Friday before that the system was crap and he wouldn't show it to anyone. He said it was an embarrassment. We developers wound up working all weekend to setup a training plan and creating handouts. I started training the users on Monday.

By the end of the first day, the users were complimentary.
By the end of the second day, the users were estatic.
By lunch of the third day, he decided to teach the class.

The system suddenly became his idea to hear him tell it! We shamed him into it. The simple fact was he had not taken the time to learn it or to prepare for the class.

He now tries to write his own SQL to create his reports because he doesn't like the ones the system has (even though he wrote the specs). I have seen his code and have warned management that he does not know what he is doing and the totals are completely wrong!!!

If I were still on at that client site I would glue myself to his left hip. I would "help" him work and try to teach him as gently as possible. Some people learn by watching you and then they correct their actions, thinking that no one ever would know they were doing it wrong. He would be happy because his work would be getting done.

In the meantime you could leave retirement brochures on his chair when he is not looking!

Good luck, I wish you success with this troublesome client.

select * from Life where Brain is not null

Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000
^{When posting code, please use TGML to help readability. Thanks!}

 

[jrbarnett]

BJCooper,
The gentleman in question is the company proprietor, and the person who initiated the request for the new software so there is no way we would get a sign off on the project at the moment.
He is in fact, semi retired, and this work is a hobby (selling specialist books), but that fact is irrelevant to this posting. Right from the start I don't think his heart was ever in it.
For example, because of his age (guesstimating late 60's - early 70's) and health, while not poor compared to some people I know, was certainly not top notch. Every day I went for a site visit he would have a rest in the afternoon, and sometimes while I was working he would go out to take his dog for a walk.

My reason for leaving was nothing to do with his problems and attitude, but I must admit they were getting to me when I was given my notice. Whenever I have been in touch with my former employer, there is always something moaning about this client or this piece of software. The colleague I wrote it with is still working there and has not a good word to say about him. The reason I posted this is that they are looking for ways to deal with this problem and asked me if I had any suggestions, having worked on the project and knowing the client.

John

 

[TomKane]

What is it that made him want to upgrade? What is it about the DOS software that is unacceptable? Was it that there are things his app can't do and wanted it upgraded - but (maybe) was told that it must be windows as that's the way of the world. It just seems odd that he'd request a change and then rubbish it. Funnily enough our major app is DOS based but we developed a front end to it and as far as the user is concerned it's a new app.

 

[palbano]

>> Has anybody else had to deal with serious acceptance
>> problems caused by user error or luddite tendencies? How
>> have you got around it?

The root cause of this problem was the lack of an explicit contract, including requirements and specifications, at the start of the project. Contractual relationships are totally different than corporate ones.

The contractors have no one to blame but themselves for entering into a losing relationship. Since the developers are responsible for the bad situation they should bear the burden. What I mean is that you just have to deal with this customer as kindly and professionally as possible while respecting his wishes.

All the while doing that, you can make a consistent effort to get the customer to agree to a modified contract that provides real, measurable goals for determining the end of the project.


-pete
_{I just can't seem to get back my IntelliSense}

 

[BJCooperIT]

pete:
Hold on a minute. If my consulting company negotiates a crummy contract and places me there then I, the developer, am responsible?
No way!

I agree you have to make the best of it and nudge the person along. This opens a whole discussion of how to write a contract that protects both parties.

select * from Life where Brain is not null

Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000
^{When posting code, please use TGML to help readability. Thanks!}

 

[palbano]

BJCopperIT, calm down now... my use of the term developers was used to indicate one contractual side verses the other, client, only. I was not using it in the sense of a single person. I was implying zero knowledge of which individuals from the developer company might interface with the client(s).

Does that help clarify my previous comments? ( I have to do this often… apparently my message based skills are… on a scale of 1 to 10 somewhere around a –50 )


-pete
_{I just can't seem to get back my IntelliSense}

 

[sleipnir214]

palbano:
I think you've hit the crux of the matter: expectation management.

In my experience, more projects are scuttled by failures of expectation management than anything else.

The most glaring example is when the client and the contractor do not even agree on what the project actually is. And jrbarett is in one of these situations.

Unfortunately, jrbarnett is in no frame of mind to even deal with the situation reasonably. When you are referring to users as "incompetent" is pleonastic. Users, by definition, are incompetent -- if they weren;'t, they wouldn't be users. But when that word is used to refer to a client, I don't see how the relationship can sour more without litigation.

jrbarnett:
Your client's technical expertise, tendency to nap, age, and health is, frankly, none of your concern. Satisfying the project requirements as he sees them is -- without that, this is a never-ending project.

His general grumpiness is germane only in how you respond to him personally. I've found that grumpy old sons of bitches tend to respect you more when you bark back.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[jrbarnett]

Hello everybody,

BJCooperIT was right: I have opened a can of worms here.

To respond to your points in turn:

TomKane,
We don't know what his reasons were for wanting to replace the DOS software, the best we could think of was exactly your suggestion: he heard in the press that DOS was legacy and being phased out and being replaced by Windows, and so he thought he needed to upgrade. I'm sure it was a lot of "The grass is greener on the other side." and was taken in by the hype.

Palbano,
You are right in that the company had no explicit contract relating to this project and that is part of the problem (see my response to Sleipnir214 below), but we fulfilled his very vague requirements, which were to produce a Windows version of the DOS software.
As for why the directors agreed to proceed with this new package, I am not exactly sure.
At the time the request was made, he had been a client for over 10 years and we had very few support calls from him relating to this DOS system. If we had 2 a year it was a lot.
It just worked and sat on his server and he ran it from a shortcut on his desktop on one of three networked PC's in his office. We had no idea at the time it would cause so many problems or have such consequences.
The fact that he didn't like the software we produced right from the first beta test version could be said to be partly our fault for not asking him what he wanted at the time. However, as he didn't specify any screen layouts or other preferences for the interface from the outset, we took it as given that we had free reign to do it as we saw fit, based on an MDI Windows interface.
What we found out far too late was that his expectation was a Windows version of the DOS software, working in exactly the same way as the DOS version, with an identical menu system and structure.

Sleipnir214,
I agree that the client's personal problems and lack of computing skills are none of my concern, however, they were affecting the project, specifically relating to the time he put into learning how to use the new software, and the time we were able to quiz him about problems he had with it and what could be done to overcome them, which is why I raised them here.

Whenever I have been in contact with him, via email, telephone or on site, I have always treated him with the utmost respect and certainly not criticise him to his face. He reciprocates when in a face to face contact situation, but if he is in his office and I am in mine, this changes
He knows, and will admit, if asked, that his computer expertise is lacking. To some extent, he is "application" rather than "computer" literate, for want of a better phrase - ie he knows how to do certain things related to his computer, such as start it up and shut it down properly, use the old DOS system, read and write email, browse the web with IE etc.
He is also quite happy, when his internet connection is broken, to fiddle in the modems control panel and dial up networking to see if he can get it working even if it ends up doing more damage than it had been had he left it alone. Yet, he doesn't seem willing to learn something new, such as how to use this application, even though he specifically requested it.
My guess is that while the DOS system is there and available, he is quite comfortable using it and there is no benefit for him to learn to use the Windows package properly.

John

 

[palbano]

>> fulfilled his very vague requirements

You can't meet vague requirements it's not logically possible. You can only prove specific measurable requirements. This is part of the contractors responsibility, expecting vague requirements from clients and writing real requirements that become part of the contract.

... (vague requirements)

>> partly our fault for not asking him

Wholly your fault (your being your company not you specifically)

>> we took it as given ...

Ah yes, the Assumption methodology also know as the Ready Fire Aim methodology.

…. ( Assumptions)


-pete
_{I just can't seem to get back my IntelliSense}

 

[jrbarnett]

To answer TomKane's question, the Windows system includes no additional functionality over the DOS one, so there is no advantage to him in getting to know the Windows system while the DOS one is still working.

Palbano
I understand your comment about vague requirements, but if ever we asked him to clarify what he wanted, he would say "all the DOS functionality in a Windows program" and nothing else. We couldn't get anything more specific than that. This is exactly what my former colleague and I did.
It might not have been what he envisaged, but it fulfilled his 'specification'.
In fact, we ended up adding extra functionality for free over the DOS system when these problems became apparent in an attempt to resolve them, as a goodwill gesture.
The functionality was a context sensitive help system and a "Help" button on each screen to bring up the appropriate page.
His attitude was that it was easier to pick up the phone and have us talk him through it rather than press the F1 key or click Help and read what it says. This screen also included a function to print the help out on the default printer, so he could close the help and get back to what he was looking at with the documentation to hand.

John

 

[CajunCenturion]

Actually, the spec "all the DOS functionality in a Windows program" is quite specific. Nothing is left to interpretation. If he were to say, "it doesn't do 'this'", then sit down in front of the DOS program and ask him to show you 'this'". It's either there or it isn't. If the DOS program does 'this', then you've got some work to do. If the DOS program does not do it - then it's not in the spec. The DOS program is the foundation by which every dispute should be judged. There is no better functional spec than a full functioning working system. If the Windows program performs all of the functions of the DOS program, then you've met functional specs.

Now, that being said, there may be differences of opinion with respect to the user interface, and how that interface functions. And I would suspect that the user interface issues are were the problems lie. And, the customer may have a quite valid point. Does the Windows program have an identically functioning user-interface? It is perfectly legitimate for the customer to expect that a given sequence of keystrokes that produce a certain result in the DOS program will have the identical results produced from the Windows system with the identical sequence of keystrokes. Can you say, as the vendor, that you've met that functional requirement. The identical functional user-interface? But again, there is nothing vague about the spec. Does the windows system perform just like the DOS system?

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[palbano]

Actually, the spec "all the DOS functionality in a Windows program" is quite specific

Not on my planet I wouldn’t touch a project with a spec like that with a ten foot poll. A project with a spec like that does not have a schedule, it has a halflife

CajunCenturion, i wrote that before reading your second paragraph where you seem to completely contradict that statement.

Are we not providing you with enough material to satisfy your arguing needs so your resorting to arguing with yourself?

I certainly hope you have a sense of humor. If my humor offends you please feel free to RF this since my position is already stated above.

-pete
_{I just can't seem to get back my IntelliSense}

 

[lionelhill]

"Application rather than Computer literate"

That phrase leapt out at me. This is a serious problem today. People are trained to use a particular package and not given any training on the underlying theory of what's going on. An obvious example is computer graphics. There are loads of courses on Photoshop or Powerpoint or whatever, but people come back from these courses with no idea of the difference between a bitmap and a drawing, and no clue how to interface between their application and others. I get this on a nearly daily basis...
But it's not the users' fault. They're being given "cheap" training that doesn't cover their needs, because it's easier to teach "Photoshop" than to teach computer graphics.

Right, having wibbled off topic, back to the matter of difficult contracts and difficult customers.

Some projects simply aren't worth doing, and some customers aren't worth having. If this thing is going to cost you more in money and reputation than it will earn, say no. No one should feel obliged to take every potential customer who walks through their door (and I say that from both points of view). It is better to admit that your company cannot fulfil someone's needs(*see below) than have a bad relationship grumbling on for years.

(* not necessarily through your own company's fault. Some people's needs are just too difficult)

 

[CajunCenturion]

On the contrary palbano I'm being quite serious. I can assure you that a working system, referenced as a requirement, is as specific as you can get. It is completely and totally un-ambiguous. I don't know what planet you come from, but here on earth, a fully-functional system from which to derive requirements is even better then a working prototype. You already have your screens, you already have your reports, there is no question of what each menu item does, there is absolutely nothing ambiguous in that spec. There can be no - "The contract says this, but it really means that". All that matters is what the existing program does, and the system will speak for itself. It's cut and dry.

You stated in your original post "The root cause of this problem was the lack of an explicit contract, including requirements and specifications, at the start of the project.". That I don't agree with. The root cause of this problem was the implicit assumption by the software vendor that the customer would accept having to change the way he does his/her job. That he/she would accept being trained in a new technology, in order run to the same old application. The customer did not ask to learn Windows, they asked to have their application

You think that I'm contracting myself in the second paragraph. What I'm doing in the second paragraph is showing where the software vendor failed to replicate that which was in the DOS application.

If you go back and read jrbarnett original post, he lists six specific gripes about this customer. With perhaps excepting point #3, not a single one of them has anything to do with the functionality of the DOS application. And even point 3 is an interface issue, and not a functional one.
Every point has to do with the windows environment, and not the DOS application. Quoting from the second sentence, "it did everything he wanted and he was happy with it and knew his way around.", the key operative phrase is "and knew his way around". And I suspect that what got changed - the way around.

Based upon what I've read in the thread, the vendor failed to replicate the user-interface of the DOS application, thus putting themselves in the position of having to train the customer on Windows, which the customer was not interested in. They forced the customer to change the way around their own system, which the customer did not want - and that's where the rub is.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[CajunCenturion]

Actually, there is one even better spec than a working system, and that would be the source code from the working system.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[jrbarnett]

CajunCenturion,
You've hit the nail on the head with your user interface comments. Have a star.
From a very early stage he was made aware that it would look different and behave differently to the DOS system, and was given the option to cancel. He chose to proceed.

Although the Windows system has the functionality of the DOS one:
a) it looks very different simply because it is a Windows rather than a DOS application.
b) it behaves differently, for the same reason. For example, in the DOS system, screens behind the active one are inaccessible until it is closed, whereas in Windows they are accessible from the Window menu.
c) The methods of doing some things were different as well, even such things which we would consider quite minor as pressing Enter to move between fields in DOS to using tab in Windows.

In designing the Windows system, navigation between screens was set to be in the same order and had the same options and selection in a similar layout to the DOS but he still couldn't make the change easily.

As an example, for those who have access development experience: we replicated the menu system originally using the Access Switchboard function as this was the closest analogy to his DOS menu system, but he didn't like it. We replaced it with a custom menu system built with CommandBars, which he much preferred even though the Switchboard was far closer match to the DOS equivalent menu system.

Palbano,
I now know the company regrets agreeing to do the work in the first place. This is now a nightmare, and I use this as an example if anybody asks me if I have been involved in projects with serious problems.
Hindsight is a wonderful thing and a very exact science.

However, nothing can be done about the past now. What has happenned has happenned and nothing you, I or anybody else can do will change it.
I don't feel it is possible to retrospectively add a new contract relating to an existing product, without an existing contract to expire first.

lionelhill,
We realised this project wasn't worth doing far too late.

John

 

[DonQuichote]

(the project) does not have a schedule, it has a halflife

palbano, you get a star for that one! I will definitely use that sentence for some future or past projects...

Best regards

 

[CajunCenturion]

<tongue-in-cheek>
I'm kinda curious DonQuichote - when you refer to the half-life of a project, just remember how easily that can be turned against you, as half-life usually refers to decay rates and/or reaction rates, and I've dealt with some rather shrewed customers and clients, who could easily retort with something along the lines, Half-life?? - are you implying that your code actually decays? I don't want code with a half-life, I want something stable!

I wonder what the half-life of IntelliSense is?
</tongue>

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[DonQuichote]

Have you never estimated a task and then heard from management (who know nothing about software) that it will be done in half the time? I can feel the bugs radiating from the code... I want to get out!

Now that is a project with a half-life.

Best regards