IT Consultant

Recommend clients using FTP switch to SSL or SSH

Susan Harkins — Mon, 17 Nov 2008 22:09:37 +0000

FTP is certainly not the right transfer protocol for sensitive and confidential data. If you have consulting clients who still depend on FTP, Susan Harkins explains why you may want to encourage them to update to SSL or SSH.

—————————————————————————————————————

Secure file transfer is a challenge we all face. Electronically exchanging confidential or sensitive data carries risks that the data won’t reach the intended recipients or worse — that an authorized person will intercept the data.

For years, FTP was the way to transfer files on a regular basis. After all, it is quick and easy. I mention FTP because, despite its lack of security, FTP is still the most common method of transferring files. FTP protocol includes little or no security, leaving data vulnerable to attack and authorized viewing during transmission and while stored on the server.

Unfortunately, many companies have no IT mandate on the subject and leave data transfer decisions up to individual users. This is a disaster in the making. If your clients are still using FTP, you might recommend an update to either Secure Sockets Layer (SSL) or Secure Shell (SSH).

SSL: Also known as FTPS, SSL provides secure encryption using standard FTP connections. SSL protects data from unauthorized viewing and editing during transmission.
SSH: Also known as SFTP, SSH encrypts the entire transfer process.

SSH seems to be the favorite because most operating systems support it. The following table compares features of the three transfer methods.

Feature	FTP	SSL	SSH
Credential encryption	X	X	X
Transport encryption		X	X
File integrity check	X	X	X
Built-in compression			X
Connection ports	2	2	1

As you can see, SSH is the most robust, and the port issue alone is a great bonus. In addition, only SSH offers built-in compression for better performance.

Chances are, you know all about SSL and SSH, but it might be time to discuss better security for file transfer with those stubborn clients still clinging to unsecured FTP connections. It’s time for those clients to change their attitude in regards to data transfer; they must treat data transfer as an essential process and standardize their file transfer solution.

The first step to standardization is to adopt a more secure method of transfer, perhaps SSL or SSH, for sensitive data. You can help clients decide which is the most practical and efficient. The next step is implementation and education. It’ll be your job to make sure everyone has the appropriate access, licensing, and training.

Related TechRepublic resources

Get weekly consulting tips in your inbox
TechRepublic’s IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

Giving IT consulting clients realistic estimations

Chip Camden — Sat, 15 Nov 2008 20:00:04 +0000

To estimate when you’ll complete a consulting project, leave the best case out of the standard PERT calculation. Find out how to come up with the worse case and most likely case numbers.

—————————————————————————————————————

The first rule of estimating time requirements for an IT consulting job is: Don’t do it.

Okay, that’s not exactly right. In fact, you should always estimate the time required for a project — if you bill by the job, that’s how you’ll determine your price. Even if you bill by the hour, you’ll want to get a handle on exactly what you’re committing yourself to in terms of scheduling. Just don’t share that estimate with your client, if you can help it. No matter how many qualifications you put on it, no matter how many times you remind them that it’s only an estimate, just by putting a number or a date out there, you’ve created an expectation.

But sometimes clients insist on getting a “rough timeframe” — or, if you bill by the hour, a rough cost estimate. Back in my early days of consulting, I’d just pull a number out of my, um, hat — a number that was usually based on the best case scenario. You know, the one where nothing goes wrong. For some reason, I was rarely correct.

A while back, Tom Mochal posted about using the PERT technique, in which you average the worst case, best case, and most likely case (heavily weighting the most likely case) to come up with a decent estimate. Personally, I’d forget about the optimistic case and divide by 5 instead. The probability of the best scenario is equal to the probability that Murphy’s Law will be suspended — and we should all know from experience that Murphy’s Law is more reliable than gravity.

But even so, how do you come up with the numbers to plug in as worst case and most likely case? For the worst case, you have to stop somewhere. I mean, just think of how many things could go wrong. In the most critical stage of the project, you could be taking your morning stroll and be hit by a falling piece of frozen airliner sewage and not wake up from the coma for six months. Do you build that into your worst case? Of course not! Because the coma could last for seven months. Seriously, though, you can only include the most likely delays in your worst case scenario. How’s that for a paradox?

When computing the most likely timeframe, I follow a formula something like this for each activity:

T = (G * U) / R

where:

T is the resulting time estimate for the activity.
G is my best guess for how long it “feels” like it will take.
U is the uncertainty factor.
R is my reliability quotient.

G is the least scientific quantity here. Unless your work is highly repetitive (in which case, you should write a program to do it), it’s difficult to say with any precision exactly how long any activity will take. That’s why I call it G, for Guess. That’s also why this equation has the U and the R, which I’ll explain below.

U, for Uncertainty, is a multiplier for unknowns. How much of this activity involves new research? How much has already been solved? Here’s a guide:

(U = 1) I’ve performed this activity myself before, and I know what I’m doing.
(U = 2) Many others have done this before, so I’ll be able to Google my way through.
(U = 4) I read somewhere that somebody did this before.
(U = 8) Nobody has done this before, but all the pieces should be in place.
(U = 16) We’ll have to invent how to get from point A to point B.

If the solution involves learning a new programming language or other major technology, multiply U by a factor commensurate with your ability to learn new languages, etc.

I often find that when my estimates are off wildly, it’s because I failed to get U right. I’ll mistakenly assume that some part of the problem must have already been solved before, but then I’ll come to find that we’re actually breaking new ground. The more research that has to go into a project, the less reliable your initial estimate will be — exponentially. But sometimes you can reasonably lower the value of U by doing a little prototyping up front.

R, for Reliability, takes your past performance at estimation into account. At the end of each project, compute the ratio of each activity’s G value divided by the actual number of hours spent on it. Average these in with the same ratios from all your other past projects, and you have R. R may seem to represent the probability that your best guess will be right, but it isn’t — it’s actually far more useful than that, because it’s a predictor of how far off your best guess is likely to be. Thus, if you have a history of taking twice as long as your best guess, then R will be 0.5 — which multiplies your final estimate by 2. It’s the old adage “take your best guess and multiply by n“, except that n is determined by just how bad your guesses have been in the past.

Now you have an estimate that you’re likely to be able to live up to. But we never like to disappoint a client, so when they ask, double it. After all, we’re still subject to Hofstadter’s Law: “It always takes longer than you expect, even when you take Hofstadter’s Law into account.”

Tracking and reporting your IT consulting hours

Chip Camden — Fri, 14 Nov 2008 20:00:39 +0000

Keeping a detailed account of the work you do for clients doesn’t have to be time intensive. Chip Camden shares two applications he created that make activity tracking a breeze.

—————————————————————————————————————

Like many consultants, I usually bill by the hour; this means, strangely enough, that I need to keep track of how many hours I actually work for each client. When I’m on a client’s site, that’s a pretty simple equation: departure time minus arrival, minus any time spent on other matters (calls from other clients, blogging, hitting on the Administrative Assistant [just kidding — never go there… anymore]). But I’m rarely on site — I perform most of my work remotely. While this allows me to easily shift my attention between projects, it also requires me to apply more energy to tracking my time.

I’m glad that I don’t have any clients that require a level of detail that includes actual start and stop times. All of my clients are satisfied with a total number of hours per day, though some of them want that broken down by project. So I find it useful to keep a stopwatch for each separately reported activity. As I switch between projects, I stop one and start another. At the end of the day, I record the totals for each activity.

Now, I bet you’re thinking, how many stopwatches does Chip own? How does he keep track of which stopwatch belongs to which project? Where does he find the desk space for all of them? What if his mouse hand knocks one off the desk and into his foot bath? (That last one is easy: I don’t use the mouse).

Seriously, I’m not talking about physical stopwatches here. Welcome to the 21st century — I keep all my stopwatches on a tab in my browser, using a little JavaScript application I whipped up. You can use it, too — or you can download it and host it yourself. If you’d rather run it on your Windows desktop, I created a C# version a few years ago. The JavaScript version lets you add stopwatches to the page; for the C# version, you just launch the application once for each stopwatch. Both versions include an edit field for a description, so you can keep them straight.

In a perfect world, these stopwatches would include the ability to submit the data to a server application to record time directly to your books, but I haven’t taken it that far yet. What I do now is manually transfer the totals, rounded to the nearest quarter hour, into a spreadsheet that I maintain for each client. No, I don’t use any pre-packaged accounting software; I’m pretty low-tech in that department. But I rarely have more than five active clients in any given month, so my mostly manual invoicing procedure still takes only about half an hour.

All of my current clients are happy to receive their invoices via e-mail as a PDF attachment. Typically, I divide the invoice into two pages. The first page summarizes current activity, prior balance, payments received, and total balance due. The second page provides the detail for the current period. The reason for this division is that most clients have a separate Accounts Payable department that doesn’t want to be confused by too much detail. They’ll end up with the summary page. Whomever I report to for project status is more interested in the hourly detail. They’ll use that information to track the cost of specific projects and to confirm that I’m actually working on what they want me to be doing.

How do you keep track of your hours? What level of detail do your clients require?

(This post was inspired by part of a discussion thread on my last post, Customizable IT consultant sample contract — with a nudge from Chad Perrin.)

Do you ever recommend Google Docs to smaller clients?

Susan Harkins — Fri, 14 Nov 2008 13:33:54 +0000

Google Docs seems like a flexible and affordable solution for small businesses (it’s free), yet a recent study found that nobody’s using it.

—————————————————————————————————————

If a company has more than one employee, chances are they’re collaborating on something. Typically, they e-mail documents back and forth. The more employees involved, the more documents they exchange, and the harder it is to incorporate all the changes. Even worse, the potential exists for someone’s edits and comments to get lost in the shuffle.

The Microsoft shop big enough to deploy SharePoint doesn’t need help. Still, even small businesses have choices, such as Microsoft Office Groove and Office Live Small Business. Beyond what Microsoft offers, there’s also Google Docs, a Web-based office suite that allows you to create documents, spreadsheets, and presentations. Users share the documents with one another and decide who can view and edit. Google Docs’ features are impressive:

Users can view and edit a document simultaneously.
Users can see other viewers as they edit.
Users can make comments rather than edit content directly.
Google maintains a copy of each revision and users can revert to earlier versions.
It’s free!

Google Docs seems to supply a viable alternative for expensive collaborate software; however, there are some limitations:

Users must have a Google account, which really isn’t a deal-breaker.
Google can (and does) change the suite without informing users.
Applications are limited; power users will balk at the limited features.
You can’t control security.
Shared documents are on Google’s servers, not yours. It’s not the right place for company accounts and confidential documents.

Google Docs should be wildly popular, but an uncontrolled survey found no one recommending it for their smaller clients, and I’m wondering why. Is there just no market for it, or are users leery of putting documents on a foreign server? Have you recommended Google Docs to any of your smaller clients?

Related TechRepublic resources

Train consulting clients to monitor their own systems

Susan Harkins — Thu, 06 Nov 2008 15:45:22 +0000

You can’t possibly keep tabs on all the PCs in your consultancy network, so train users to monitor systems themselves. Susan Harkins suggests which tasks to teach them and explains how this exercise can help build your relationship with clients.

—————————————————————————————————————

IT isn’t just technical nuts and bolts. As a consultant, you spend at least part of your time building trust with your clients and their employees. They don’t have to be separate issues though.

One way to build trust and get technical tasks done at the same time is to train clients. Now, you can’t train them to do everything, but you can teach individuals how to monitor their systems and keep things running smoothly. In short, teach them how to do the following tasks for themselves:

Run a full virus scan every day. If the software runs the scan automatically, show users how to check the log to make sure the software actually ran the scan as scheduled.
Check virus software to make sure it’s running and its definitions are up-to-date.
Check backup files to make sure the process was successful.
Check for Microsoft patches and updates. This teaching process will depend on update settings.
Check for security breaches (if a firewall is installed on the local system).
Clear temporary files and downloaded program files.
Defrag the system regularly.

These are just a few things that the average user is certainly capable of handling. With a checklist and some basic training, users can monitor their own systems and save you the trouble of performing these tasks. Teaching users how to monitor their systems displays trust and confidence, and both go a long way toward building a good relationship with your clients. Perhaps most importantly, users will learn a bit about their systems and learn to recognize when they should call you for help.

Are there any items that you would add to the list? If you have trained clients to monitor their systems, how is it going? Post your thoughts and experience to the discussion.

Consulting field proves popular among IT business graduates

Mary Weilage — Mon, 03 Nov 2008 21:44:00 +0000

A growing number of graduates from the top IT college programs in the country are going into the field of IT consulting. Find out more about what makes these programs stand out.

—————————————————————————————————————

When we were compiling the research for the TechRepublic Special Report entitled Top 10 U.S. college programs, I noticed that it was mentioned that a number of the graduates from these business schools go on to become IT consultants. Some of the programs even offer specific IT consulting courses.

Here are excerpts from the report that illustrate this point:

Meaghan Bouchoux, a 2000 James Madison University grad now working as a manager with Bearing Point, credits the school’s IT Consulting course with giving her consulting career an immeasurable head start. “By the time I had graduated, I had gone through an entire systems development life cycle, so nothing was a surprise to me when I entered the consulting world. I had done the hands-on work to create that mock project from the ground up and was a few months ahead of my peers because of that experience,” said Bouchoux, who in 2008 was hailed by Consulting Magazine as one of the top 30 consultants under 30.
The IT program at Virginia Tech, which currently hosts approximately 270 degree-seeking undergrads, attracts students desiring a technical degree they can apply to the business world. It comes as no surprise then that many of the program’s graduates move into consulting firms where a more technical background is often valued alongside business acumen.
Many graduates of the Computing and Information Technology track [in Carnegie Mellon University Tepper School of Business] go into consulting or work for software development or implementation companies.

Download the Top 10 U.S. college programs report for more specifics about the schools’ programs. Then, post to the discussion to tell us a little about your training to become an IT consultant. Was it primarily on-the-job training, classroom education, or a mix? Or, are you completely self taught?

Customizable IT consultant sample contract

Chip Camden — Mon, 03 Nov 2008 14:31:14 +0000

Chip Camden presents his standard consulting contract, along with explanations about each section. See if you can modify his contract to fit your needs.

—————————————————————————————————————

In the discussion about my recent post on growing your IT consulting business with your friends’ help, TechRepublic member patrick asked how to word a canned contract to save time when proposing small jobs. Even for larger engagements, it’s a good idea to have a standard contract template that you can quickly customize. It makes you look much more professional, as if you sign new contracts so often that you need to have a streamlined system for producing them.

Here’s my standard consulting contract in its entirety, along with explanations about each section. First, the intro:

BUSINESS CONSULTANT AGREEMENT

This agreement is made as of __________________, by and between _______________________ (”Client”), a __________________ company, and CAMDEN SOFTWARE CONSULTING (”Consultant”), a Washington company.

Fill in the blanks with the contract date, the name of your client, and where they are located or incorporated (you might need to change “company” to “corporation”). Naturally, your template should have your company name and location instead of mine.

RECITAL

A. Client desires to retain the services of Consultant for the initial period of twelve (12) calendar months, and Consultant is willing to perform the services called for upon the terms and conditions set forth in this Agreement.

NOW THEREFORE, for and in consideration of the premises and the mutual covenants hereinafter entered into, the parties agree as follows:

1. Terms of Agreement. The engagement shall commence as of _________________ and shall continue to and including _______________. This Agreement can be extended by mutual consent of the parties hereto upon the same terms and conditions for a period of time as agreed upon by the parties.

A one year initial period is usual for me, and then I send them a new contract; this allows me to negotiate changes in rate or anything else on a regular interval. For some short-term projects that have a well-defined scope and that you know you won’t renew, you could specify the exact period here.

2. Duties. Consultant shall provide software planning, design and development services to Client.

This is what I do — change this to say what you do. In my opinion it’s best not to be too specific, so you can do whatever the client needs but not get roped into anything you don’t want to do. On the other hand, if you’re specifically trying to prevent certain types of duties, you might want to barricade yourself in here.

3. Time Requirements. Consultant agrees to furnish Client with consulting services as required by Client and as mutually agreed upon in advance by the parties hereto.

I don’t make specific time commitments in contracts if I can help it, although I have capitulated to occasional demands for a specific number of hours. I’d rather keep it as flexible as possible, so I can easily devote attention to emergencies from other clients when they arise.

4. Compensation and Terms. Client shall pay Consultant the sum of ___________________ ($___.00) per hour for services performed. Client shall pay Consultant the sum of ___________________ ($___.00) per hour for travel time when such travel is authorized by Client. Travel time includes all time spent between departure from origination and arrival at destination, inbound and outbound, minus any time therein during which billable services are performed. Consultant shall present an invoice to Client each month for services performed, travel time, and expenses. Payment shall be due in full within 30 days of the date of the invoice.

Fill in the blanks with your hourly rate and your travel time rate, presuming you’re hourly. If you have other terms, this section will need a lot of rewording. I generally charge half my hourly rate for travel time. Note the definition of travel time; if I’m able to work while traveling, I bill that time at full rate. You’ll also want to modify the terms if yours are other than Net/30.

5. Expenses. Client shall pay all expenses reasonably incurred by Consultant in the course of performing services under this Agreement, as mutually agreed upon in advance by the parties hereto.

I don’t get wicked with my clients over expenses. For instance, I usually eat the costs of hardware and software licenses, unless it’s expensive and highly specific to their needs. But I like to have this coverage in here so I don’t have to eat air fare and hotel charges. Note how “as mutually agreed upon in advance” is intentionally vague. It doesn’t have to be in writing — though I like to get and save an e-mail confirming their commitment, just in case.

6. Confidentiality. Consultant shall treat as confidential and shall not disclose or use for the benefit of any person other than Client any and all information made available or disclosed to Consultant as a result of or related to the Business Consultant Agreement; provided, however, Consultant shall have no obligation hereunder as to any portion of such information which is disclosed by Client to others without any restriction on use and disclosure.

Here’s a mini-NDA, so I don’t need a separate agreement for confidentiality. It’s a pretty broad statement — essentially, I can’t tell anyone anything about the work I do for my client unless they say I can, or they’ve already made the information public through other channels (inclusive or).

7. Rights and Licenses.

(a) Consultant hereby grants to Client, and Client hereby accepts the entire right, title, and interest of Consultant in and to any software, documentation, and information first produced or created by or for Consultant as a result of the performance of work or the rendition of services under the Business Consultant Agreement.

Most of my clients are vendors of proprietary software (yes, I work for some of the “evil” closed-source establishments), so they demand the full and exclusive rights to anything that I produce specifically for them. If you work for other types of companies, they probably don’t care about the copyright to your software, so you might want to reserve those rights instead. You might even just omit section 7 entirely and let default copyright law apply.

(b) Consultant hereby grants to Client, and Client hereby accepts, an unlimited, unrestricted, royalty-free, fully paid, worldwide and nonexclusive license to any software, documentation and information not first produced or created by or for Consultant as a result of the performance of work or the rendition of services under this agreement, but included in said work or services, provided Consultant holds copyright to said software, documentation, or information.

Let’s say I developed a useful algorithm a year ago and published it on my blog. It perfectly fits a purpose for my client, so I use it. But I don’t want to give up my copyright on that code just because it is now part of their product. So, I grant them a non-exclusive license without any restrictions; they can resell it as part of their product without accounting to me, but I retain the right to use that code as I see fit.

(c) Consultant may utilize publicly distributed software, documentation and information within the solutions provided to Client under the terms of this agreement, provided that said software, documentation, and information is either in the public domain or is licensed for public distribution under terms that do not conflict with the licensing of Client’s products in which they are included.

This is a relatively new section, dealing with open source and other publicly distributed material. I let my client know that I won’t reinvent the wheel if freely available source code fits the project. But because my client is going to sell what I produce for them, I must insure that any distribution license for this material doesn’t force them to choose between changing their license terms or violating the license of the material in question. Thus, for instance, I can almost never use anything that’s licensed under the GPL. There’s some overlap between (b) and (c) — they both apply to anything that I’ve published on Chip’s Tips – but the two categories aren’t incompatible.

8. Relationship. Consultant is retained by Client solely for the purposes and to the extent set forth in this Agreement, and Consultant’s relationship to Client shall during the terms of this Agreement be that of an independent contractor.

I’m not my client’s employee — I’m independent. Even after more than 17 years, I still love how that sounds.

9. Waiver, Modification, or Cancellation. Any waiver, alteration, or modification of any of the provisions of this Agreement or cancellation or replacement of this Agreement shall not be valid unless in writing and signed by the parties.

Standard legal CYA that prevents “but you told me…”.

10. Assignment. Any attempt to assign or transfer any rights, duties, or obligations herein shall render such attempted assignment or transfer null and void.

No bait and switch. They’re signing me, and they’ll get me. Likewise, they can’t push their side of the bargain off on someone else.

11. Liability. In no event shall Consultant be liable for any damages arising from the use of the software developed under the terms of this Agreement.

Very important — if somewhat unenforceable. But at least they signed to it, so we know where the expectations are.

12. Governing Law. This Agreement shall be construed in accordance with and governed by the laws of the State of Washington.

That’s where I live and work — change as appropriate. One of my clients insisted on making it their home state instead. I hope they never add travel to court to the indignity of being sued.

___________________________ (Client)

_______________________Date _________

___________________, Title: ___________

CAMDEN SOFTWARE CONSULTING

  _______________________Date _________

Sterling W. Camden, IV, Owner

Fill in the name of your client and the name and title of the person who will sign the agreement. Change CAMDEN SOFTWARE CONSULTING and my name to yours. Send it to your client and request that they sign and return a copy (I used to say “send two and get them to send one back,” but nowadays we generally e-mail PDFs instead of trusting the postal service to deliver tree flesh). Don’t start work until you get the returned copy. Trust me on that.

In preparing this post, I realized just how different the requirements can be for a contract from person to person and from job to job. Before you adopt this version wholesale, please consult with your lawyer to make sure it says what you want it to say. I am not a lawyer, so please don’t take my word as legal advice. I assume no liability for damages resulting from the use of any part of this contract for any purpose, including but not limited to kindling a fire, blowing your nose, or making paper airplanes.

Thanks to Chad Perrin (of TechRepublic’s IT Security blog), who suggested this subject to me after reading patrick’s comment. He also helped me identify some changes I wanted to make to my standard contract before I published it for all the world to see how stupidly vulnerable I was.

Additional sample consulting contracts

The five fundamentals of IT consulting

TechRepublic — Fri, 31 Oct 2008 21:02:17 +0000

Rick Freedman offers advice and observations from his book The IT Consultant: A Commonsense Framework for Managing the Client Relationship. See what you can learn about building a solid foundation for good consultant-client relations.

—————————————————————————————————————

Editor’s note: The featured download was originally published in 2000, but we decided to resurface it from our archives because the concepts discussed still hold true today.

For many IT consultants, mastering the technical aspects of their field and following through on projects isn’t a dilemma. Acquiring the client-relationship skills needed to be a successful consultant, however, is difficult for many.

Pulling concepts from his book, The IT Consultant: A Commonsense Framework for Managing the Client Relationship, Rick Freedman explains the five fundamentals of IT consulting. This download addresses the complexities of providing your advice and service to clients; it can also help you fine-tune your approach and strengthen your client relationships.

According to Freedman, the level of trust in the relationship between client and consultant will determine the success of the project, more so than the technical discipline involved. Moreover, developing a clear understanding with the client about what should be accomplished and helping clients to envision the desired result will ensure a positive relationship. Most importantly, Freedman says, consultants should act in an advisory role, allowing clients to make decisions and helping them reach their goals.

The life of an IT consultant presents a plethora of daily challenges: keeping up with the latest technology, choosing the right products for a job, managing complex projects, and networking with associates to find the next contract. Along with these tasks, a consultant must focus a lot of attention on the client relationship. Freedman believes the IT advisory process is based on five fundamental concepts. Find out what they are by downloading the five fundamentals of IT consulting.

Stay ahead of the economic crunch by encouraging clients to pay cash

Susan Harkins — Wed, 29 Oct 2008 10:00:53 +0000

Some clients like to pay consulting fees with credit accounts that actually cost the consultant money. Susan Harkins suggests offering cash discounts in lieu of credit payments.

—————————————————————————————————————

I find that most clients are eager to take advantage of discounts. Years ago, a client was in financial trouble, and it took more than a year to receive payment. I offered the client a discount if they paid in cash within 15 days, and they took me up on it. I chided myself for waiting so long to offer the discount.

During these worrisome economic times, it may be wise to offer clients a discount if they pay in cash. On one hand, IT pros are in a fortunate position because clients aren’t going to stop using their computers and networks. However, you’d feel the pinch if even one of your consulting clients went out of business or if a few clients had to cancel (or substantially reduce) their monthly on-demand maintenance contracts.

An easy way to help balance some of these changes is to persuade your clients not to charge your fees. Depending on your setup, you could be paying 1.5 % to 4% in fees. When you add in the monthly fee you incur if you don’t meet the minimum, the money adds up.

Most likely, clients will need some incentive to pay cash. If you offer a discount for cash payments made within a specific number of days, it could go a long way. For example, a charging client whose fee is $300 with a credit merchant fee of 3.5% nets you $289.50. So, it winds up costing you $10.50 to do business with this client. By offering this client a 1.75% discount for a cash payment, it lets you split that fee, and both you and the client save a little money. Instead of receiving $300 and paying the credit merchant $10.50, you receive a payment of $294.75, saving you $5.25. Your client pays $294.75 instead of $300.00.

While that isn’t much money, but if enough clients use the discount, those small fees could add up to sizeable savings. I’m certainly not suggesting that you start to refuse credit payments; I just think it can’t hurt to try the discount option for a few months and see what happens. Remember to make the offer clear on your invoice with verbiage such as THIS DISCOUNT NOT VALID WITH CREDIT PAYMENTS.

Communicating effectively with remote IT consulting clients

Chip Camden — Tue, 28 Oct 2008 23:07:25 +0000

Remote IT consulting success depends on being able to communicate effectively with clients. Here are five important aspects of remote communication to keep in mind.

—————————————————————————————————————-

Working remotely certainly has its benefits. Besides saving time and money on the commute, it also minimizes interruptions so you can concentrate on your work. Most tech geeks love to focus on solving problems — so much so that they can do it for many hours at a time without even speaking to anyone else. In fact, they may even prefer the company of computers over that of other people. Yet, one of the most important factors of remote IT consulting success is communicating effectively with our fellow human components. That’s true even when you’re on site, but when you’re telecommuting, it becomes even more important to get it right — yet easier to neglect.

Here are five aspects of remote communication that deserve your attention:

#1: Timeliness

As soon as you run into an issue that requires input or a decision, you need to let your client know. If they decide to shelve their response, that’s their decision — but you don’t want to introduce delays by not letting them know about it as soon as you do. Likewise, if your client requests your input, you need to respond that same day — even if it’s just to say that you need more time to think about it. Leaving your client hanging is a sure way to make them wonder if you’re even there at all.

#2: Frequency

Even if there are no emergencies (and the last time that happened to me was… um…), it’s good to maintain regular communication (on an active project, this means daily contact). I tend to keep my head down on a problem until well after the end of the day (which is a good habit), then come back the next day and keep working on it without sending a status to my client (which is a bad habit). Meanwhile, the client is on the other end of the dial tone wondering what’s going on. I have to make a conscious effort to at least send a “Here’s what I got done today” e-mail just so they know I haven’t been playing hooky.

#3: Channel

As I’ve mentioned before, e-mail seems to work well for most of my client communication. It’s delivered relatively quickly and fairly reliably, without causing an interruption. However, it’s not without its drawbacks. One disadvantage of using e-mail is common to all written forms of communication: It doesn’t easily indicate tone of voice, facial expressions, or other non-verbal cues. It’s up to the recipient to imagine all of that subtext. Ancient Hebrew was written without vowels, and sometimes those missing vowels affected the meaning significantly. Modern written communication has overcome that problem (even modern Hebrew), but it still leaves out much of what goes on in face-to-face dialogue. So, an occasional on-site visit and regular telephone conversations can go a long way towards building your relationship with your client. Just make sure that neither one becomes the default, interrupt-driven mode of delivering information.

#4: Transparency

What does transparency mean? You often hear this word chanted around like some mantra of corporate culture until it ends up doing the exact opposite of what it promotes: obscuring rather than revealing. It means being honest — but even more than that. It means making it perfectly clear (ha) what’s going on and what’s planned: current status, perceived risks, mistakes made, and unknowns. It requires that you have enough faith in yourself that you don’t need to hide anything from your client, or even try to color it to your advantage. If you’re consistent about being transparent, your client will learn to trust you implicitly. If you’re ever caught cheating though, you’ll never regain that trust.

#5: Humanity

Computers will never replace humans until they learn to become human themselves, or until they have no further need for us. A remote consultant can sometimes become a less than human quantity in the eyes of their client, especially if their only communication is text-based status updates. If you talk to your client mostly by e-mail, work to become a good writer. Keep your technical content concise and to the point — you don’t want to be sued for making their heads slam on their desks. Mix in some humor, so they actually look forward to reading what you have to say. Include the occasional personal detail, but don’t get too graphic about that condition you had treated. In short, be the kind of person in writing that your client is glad to know as a person. It will strengthen your relationship and ease any difficulties you may face together.

I’m sure you thought of other considerations while reading this list — what are they? Please share them in the article discussion.