Dealing With Incompetence

Everyone is incompetent at something. Many programmers are incompetent at writing novels, and many novel writers are incompetent at writing code. But that's all right as long as we stick to doing what we are competent at.

Unfortunately, sometimes, people have to do things they are incompetent at, and you have to deal with these people. Worse, sometimes doing your job depends on other people performing well on things they are incompetent at.This page is intended to gather wisdom on how best to handle these situations.

Scenarios

Your client bought a system from you, their tech people responsible for setting up the system for acceptance test is incompetent in the technologies used in your system, resulting in delays and false bug logs for the acceptance test.
Your client bought a system from you, their admin responsible for maintaining the system is incompetent in the technologies used in your system, he keeps calling you for assistance on the trivial aspect of your system, and generates many false bug logs.
You have to work with BadProgrammers, either from the same company as your, or from your client's team. See also NetNegativeProducingProgrammer.
You have to work under an incompetent project manager, and TheJobMarketSucks.

Your client bought a system from you, their tech people responsible for setting up the system for acceptance test is incompetent in the technologies used in your system, resulting in delays and false bug logs for the acceptance test.

You are faced with the tough choice of:

Educating their tech people, which may take forever and have uncertain results.
Doing the job for their tech people, which speeds up the acceptance test, but means that you have to do it again for the production installation, and they will keep pestering you when anything happens after production, and you will take the blame when anything goes wrong.
Do nothing. It's their job; they should do it even if the whole ship sinks....

Your client bought a system from you, their admin responsible for maintaining the system is incompetent in the technologies used in your system, he keeps calling you for assistance on the trivial aspect of your system, and generates many false bug logs.

Very similar to the previous case, but this is an on-going problem that you cannot fix once and begone, you are faced with the tough choice of:

Educating their admin, which may take forever and have uncertain results.
Doing the job for him, but you have to keep doing it for long time and you will take the blame when anything goes wrong.
Do nothing. It's their job, but you will keep wasting time chasing false bug logs, and your client will not be happy when their admin tells them that the system is riddled with bugs.

A long discussion on why these scenarios will occur in the first place...

The incompetence is your own, not that of your client. Either your system needs to be easier for your client to use, or you need to support it better, or you shouldn't take the client's money in the first place. Maybe your company should manufacture oven mitts instead of software, if you're not capable of creating and supporting a useful, usable product. Then again, you could always alter your business model to give the unusable system away for free and then charge big-time to support it and/or administer it for the client...

I wish it were that simple. Suppose the system you sold is web-based application, and halfway through the acceptance test, you finally find out the client's tech people do not know how to install Apache properly, and over half of the problems reported are due to that? Remember, they are the ones who will install and maintain the production system afterwards... Or the system you sold is in Java/php/etc web-based application, and the client has paid for the source and requires you to train their programmer enough to maintain it, but turns out their programmers only know VB, do you turn the 3-day skill transfer into a 2-week Java/php/web course for free? And consider that you have a couple other projects waiting for you to work on too.

One of the system's limitations is that it requires a proper Apache install. People who aren't up to this are going to encounter problems with the system. You have three options:

Redesign the system so that it does not require a proper Apache install
Don't sell the system to these people
Sell the system to these people and accept that there are going to be problems

But there's no whining about your users being incompetent. MistakesIndicateDesignFlaws.

Either make good on your commitments or return the client's money. I learned long ago, never try to sell a Unix system into a Microsoft house, nor try to sell a Microsoft system into a Unix house. If the customer is "not qualified" to use your system, either make him qualified or take the system back. Charging the customer more because you failed to communicate with him earlier is not an acceptable option

You assumed you can know if the customer has the required skill or not, and that I have not communicated such requirements earlier. Both assumptions are wrong. In all cases that I encountered with these kind of problems, such knowledge (do their have the skills?) is unobtainable until after the fact. What do you do when you tell your customer that your system uses X/Y/Z so they need people with such skills to pick the system, and your customer said "Yes, no problem."? (Keep in mind that those answering you are not the ones ultimately going to work hands-on with you. You are negotiating a sale there, and so you will likely only find GoldOwners and other users in the meeting.) Are you going to request a test for their techies to make sure they really do? And what do you do when ultimately no people with such skill are provided by the customer (they left, they are busy on other projects, etc)? By that time you have completed >70% of the contract requirements, and your company have invested 20 man-month resource into it, now only the required training or completing the acceptance test is left to be done, and you have to do it with people without the required skills. Are you going to tell your boss "Let's refund our customer and stop the project, we shouldn't have made this sale in the first place."?

It is easy to say "Don't do that in the first place, and this problem won't appear" in hindsight, as if it can be avoided at all, and we all know well-managed projects won't fail too. The point of this page is (originally) "What can you do when you encounter these problems?". Saying "that's your bad, you deserved it" isn't very helpful.

Why not ask your customers what they want rather than tell them what you require? It is not terribly difficult to ask "What types of systems are you currently running?" If you didn't ask in the meeting, you can also ask for a tour of their facility later; I have never seen an organization too busy to show off what they do and you will find out a lot about their true needs and capabilities. These are very basic market research recommendations to determine product design. Remember, you are providing a service to customer. As to the original purpose of the page, in this situation you either make good on your commitment or back out completely. If you are not going to walk away, you need to provide utilities and support until the customer is ready to handle it on his own (I would guess in about 1 year).

Our customers wants are simple, they want their own people to maintain the systems they are going to use. We can understand that. We offered to support the system for them (extra charge, of course, we have a business to run, too), but in these post-dot-boom days, most customers want to cut costs whatever way they can. So we made clear what skills are needed to install/support the system, and they agreed before the purchase. Our commitment is to provide training to their staff, whom the customer agreed will possessed the required skills so they can maintain the system afterwards. We are making good on our commitment, the problem is that, strictly speaking, the customer is not making good on theirs. Let me make this very clear, the customer made a commitment (sent qualified people to the training) that they cannot fulfill, and the commitment is made to save money. Of course, one way out of this mess is to provide, for free, the support they refused to purchase in the first place, which is the 1st choice I listed in the above scenarios. I am sure my customers will be very happy about that, getting free support and training, but I doubt my company can survive that way even if my boss allows me to do that.

The options are pretty straight-forward.

Modify your software to run in the customer's desired environment
Train your customer's personnel to support your software in your environment
Take back your software and refund the customer's money
Deliver the software, take the customer's money, demand payment for anything more, and hope you don't get sued.
Work out some combination with the customer that adequately compensates you for the sunk costs of the project while maximizing the customer's utility from the project.

I would also suggest that you discuss this issue with your boss. He is probably the one who should be making this decision and it certainly should not be decided based on what uninformed parties type into a web page discussion.

Thanks for you suggestions, but don't worry. I started this page in an hope for better ways to handle these situations, we have already gone through quite a few cases already. I always discuss with my boss when I found out the problem, the decision is his alone. IME, point 1 is always part of the contract anyway, the problem here is on 2, we want to train them, but there are just not ready to learn from the training. Option 3 is out of the question, even from the customer's POV, because they need the system running (and it is running fine, too), else they won't buy it.

We usually end up with option 4 or 5, and 4 only when the customer is being uncooperative, but option 5 usually leaves both side unsatisfied and it took a lot of documented cases of the incompetence exhibited by the customer's techies to convince the customer of the problem, which is very costly and time consuming to do.

If this is a repeated problem ("we have already gone through quite a few cases already"), I would suggest getting your development under control. There is no excuse for continuing to develop products that your customers cannot use and then blaming the customer. This is exactly the type attitude that gives all contractors a bad reputation.

I would hope the cause of the problem is with us, because we can do something about it. But I doubt it, because in all cases, after sitting down with the customer and explaining the problem (with samples of the kind of "difficulties" encountered by their techies), the customer's GoldOwners all agreed that they do not have the skilled people they promised, and we can then work out practical solutions (e.g. extend the acceptance test to give more time to setup the system properly). Sadly, this approach only works after a lot of delays and problems because we cannot find out their techies are incompetent beforehand, and we won't convince the customer of the problem without repeated demonstration of incompetence by their techies. OTOH, the problem may be because we are simply incompetent at DealingWithIncompetence...

The word "incompetent" has some pretty negative connotations. In it might be best to lean towards saying something like "not skilled at X", where X is some task, unless you really intend to signal those negative connotations.

Don't people charge for this sort of thing? Wasn't that how open source companies where going to make their money before the dot.com crash?

See InexperienceGeneratesFailure, InexperiencedTeamsAreRampant