Outsourcing optimize

10 ethical rules for IT consultants and contractors

Adhering to a code of conduct will help you avoid the various ethical pitfalls you'll encounter on the job.

Applying a set of rules or ethics to business matters can protect you as well as your clients. In times of trouble or doubt, they help you determine right from wrong. You could just apply the big rule of rules: Treat your clients as you want to be treated. But in business, you often need specific guidance. I hope the following rules will serve you as well as they do me.

1: Be honest

You could lie about your strengths, your background, your expertise, and even the hours you spend on a project. It might be the largest temptation you face because there are so few auditing features in place. The client has to take a leap of faith when hiring you. Don't violate that trust for any reason, especially not to keep the job -- which brings us to #2.

2: Say no when necessary

Clients hire you for your opinions, your experience, and your knowledge. Giving them anything less violates their trust and will eventually bite you back, hard. The client might not act on your advice. A disagreement might even lead to a parting of the ways, so it's difficult to speak up when you disagree, but you must.

3: Wait when necessary

Knowing when to wait is the flip side of #2. It's unethical to push your point of view beyond discovery. In other words, it's your job to present what you've learned and make your best recommendation. It's not your job to force your recommendation.

4: Concentrate on the client at hand

When charging a client, you belong to that client. Don't troubleshoot another client's problem; don't even think about another client's project. If you must take a call from one client while at another client's facility, be discreet. Never say, "I've got to take this call" and turn your back on a client in their own facility! If possible, turn your cellphone off during these conversations. "Give me a minute to turn off my cellphone so we're not disturbed," goes a long way.

5: Lock the backdoor on your way out

Developers like to code a backdoor that no one else knows about. It's a failsafe method for gaining access when all normal routes fail. When you leave a project, provide documentation for locking or even destroying your backdoor. You have no ethical reason for maintaining it. (I'll get hate mail for this one.)

6: Maintain confidentiality

Due to specialization, some consultants have multiple clients in the same field. There's nothing inherently unethical about it. There are lots of IT projects that aren't competitive, so providing those skills to competitors won't put them at risk. Two firms fighting to be the first to market a specialized phone app won't both hire you as a developer. But both might hire you to update their disaster preparedness plan.

To protect yourself and your clients, provide full disclosure when working for competitors. In addition, be extremely careful when contracting proprietary details -- there's a fine line between tying your hands and protecting each client's interests.

7: Respect management's confidence

Just as you shouldn't violate confidentiality between clients, you shouldn't spread confidential information through layers of the same company. When the client shares confidential information with you as part of the discovery process, don't share that information with others in the company. For instance, if you learn from the CEO that the company is preparing to outsource its customer service department, you can't warn your best friend, who works in customer service.

8: Don't stir the pot

Every company has its own drama. Stay out of it. The only views your client is paying you for are those that support your IT position. Keep to your consulting views and leave all the personnel drama to the folks in Human Resources.

9: Report unethical behavior

If, during the discovery process, you learn that the manager in charge of your project is doing something unethical or illegal (related to the company), you have an obligation to report your findings (not your suspicions) to someone in a position to intercede. However, it's just as unethical (in my opinion) to exclude the manager in question from the process. Call a meeting to present your evidence but invite the manager, too. Take the high road and then find another job, because you can't survive this one.

10: Don't create a dependency

Don't covertly create a dependency just to maintain a relationship (paycheck) with a client. A project might yield a new maintenance or support contract, but it must grow from need and mutual agreement, not pretense or trickery.

Other rules?

Does this list cover most of the ethical issues you encounter as a consultant or contractor? What other rules do you follow to stay on the straight and narrow?

About

Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.

23 comments
Englebert
Englebert

Much as most people dislike documentation, it is professional to maintain a high standard of communication to the next person who takes over your work Bennett Mendes

PMPsicle
PMPsicle

#12 Don't pad the bill or the engagement. You're there for a reason. Do that work and then leave. If your client wants you to do more be sure they are aware of the extra cost BEFORE the work is done. On a daily basis don't pad either your daily bill or your expenses. #13 Don't undervalue your services. There will always be those who want to pay half price for your services. You have a responsibility to yourself, your dependants, your creditors and your profession to charge a fair rate. And that means you need to know what the fair rate is. (I've seen whole markets destroyed by clients knowing they can pay hourly employee rates for contractors). #14 Don't overpromise. If you can't do something or if there is a cost to doing something be sure your client knows before you start. Remember that setting expectations are half the battle for happy clients. Glen Ford http://www.vproz.ca

reisen55
reisen55

On December 7 I spent four hours in a medical office attempting to restore internet. The actual problem was that Optimum had changed equipment out on the pole, so nobody had internet, thus my assigned task was void. Still, a kid from Cablevision had totally screwed up the inside of the network with moved cables and public IP addresses (yes, public) so I had to reset everything and then diagnose the MISSING DNS servers for a spell until Cablevision did arrive and confirmed their work outside was the fault point. So, four hours of relatively good work. Client did not want to pay me. I did not restore internet. I am taking him to court if I have to. How about clients who respect and honor the commitment and expertise of the people they call in for a job!!!!!!!!!! Oh, if I was not incorporated, I could do small claims court, but NO, a company has to file a civil complain to I may have to do court costs. My other option is write him off as a bad debt (I am never working there again anyway) and move on. CLIENTS! They should have ethics too.

rod
rod

Hopefully this is a misunderstanding or inappropriate use of terminology!! Creating a 'back-door' in the first place in unethical (at least in my opinion) "Developers like to code a backdoor that no one else knows about" Is there any evidence or proof of this? Personally, as a developer, I find even the suggestion of this to be offensive. RodG

biancaluna
biancaluna

From time to time you will have a client that has processes and frameworks that are quite low on the maturity scale. Do not succumb to mediocrity, our trade and our skills are important, assist the client to move up, do not move your standards down as it is easier and may avoid conflict. Particularly in the management of change, scope and quality, we are there for a reason. The value for money should also be borne from our discipline. I have seen too many contractors and consultants slip, and that breeds mediocrity. Then they walk away.

Tony Hopkinson
Tony Hopkinson

A fully documented tradesman's entrance on occasion, with a key and security camera...

bill
bill

If you are on a daily rate give a full day and more. If you are on an hourly rate don't add up the part hours at the end of the week. We are usually paid more than the people who employ us or we work along side and therefore need to be seen to be value for money - this is easily demolished by penny pinching.

skraman
skraman

Good Ten Commandments ! What I will add to Rule #3 is an extension. Don't just stop at your best recommendation. If you are able to identify multiple (manageable number, of course) options, provide all of them to the client, with their pros and cons listed and let him choose. This way, you don't even have to push your best recommendation. When the client sees your list, he would assume that you have no hidden agenda and increased confidence level can do wonders.

Suresh Mukhi
Suresh Mukhi

Does this mean we have to leave our source code?

Geosota
Geosota

Name the client but obscure the data or Obscure the client and provide real data.

stevenvantil
stevenvantil

This list has a lot of great points but one is more important. Not creating dependency is so very important. I have seen this in the past, people think they can get away with this to make the company have to rely on just the one person. They are only fooling themselves and looking after their own selfishness. Companies can spot this and they will hire someone else. No one is not replaceable. Things will go on. A good team atmosphere of sharing should be promoted and that is what I try to do at the data center I work at. Thanks for reading my two cents, Steve VanTil http://www.onlinetech.com

melbert09
melbert09

Whenever I leave a contract, I will always get someone to sit next to me and delete my accounts on Exchange, AD, Firewalls, etc... I do not create back doors in the first place. I just like to leave the company with the documentation for my project with absolutely no way to get back in after I leave. I do not want to be the one blamed after I leave. If they bring me back, it is too easy to recreate the accounts necessary.

yosarian0
yosarian0

who contacted Cablevision to have them come back out and correct? If it was you then you likely have a case; if not then it's iffy. Do you have a minimum charge stipulation in your contracts?

davcomp
davcomp

...and that is exactly why I stopped working for medical offices years ago...

PMPsicle
PMPsicle

Yours, theirs and the truth. Before jumping to "they are crooks" always try to see the situation through your client's eyes. You might be surprised. And you may even manage to save the relationship. Having said that, every consultant runs into this situation at one point or other. From the insurance agent who keeps adding work and then wonders why the bill is higher than expected to the corporate manager who keeps changing their mind and then refuses to pay because you couldn't make the mess work the way they thought it was going to work to the prime who screws up the code then complains that you shouldn't have reported all the bugs. There will always be bad clients. Some will refuse to pay. Some will not be able to pay. All you can do is 1) take a deep breath 2) ensure that you've done all you can to stop the disagreement 3) learn to recognize the signs. Glen Ford http://www.vproz.ca

Bduffel
Bduffel

I agree with your "lagniappe" (a little something extra") attitude. I would recommend, however, that your invoice shows the total hours worked and then you can apply the "preferred client discount" to adjust the total. I wouldn't leave it to chance that they will notice the extra time you are giving unless you show them.

Marc Jellinek
Marc Jellinek

Yes, you leave your source-code behind. Work-for-hire means the client owns whatever you produce, including the source code.

AnsuGisalas
AnsuGisalas

Wait, I was thinking of bagnettes, disregard please :)

Marc Jellinek
Marc Jellinek

Oh, and since the client owns the source code, you can't re-use the code at another client, unless mutually agreed upon at the start of the contract.

Suresh Mukhi
Suresh Mukhi

Most clients who don't have their own IT Department don't even know what a source code is. So when I was a consultant, I did leave it in one protected folder of their server for my own access but did not tell them unless needed.

Bduffel
Bduffel

No, source code ownership is an ambiguous issue unless ownership is spelled out in the agreement / SOW.

Tony Hopkinson
Tony Hopkinson

How much do you have to change before it's something else. Past just a straight copy and rename, it's near unenforceable. Not to mention, you probably wouldn't do exactly it like that gain. :( This time I'll use a while loop. :D