So you are thinking of calling yourself a consultant. You feel that it is a title that you can wear with pride. But exactly what does it mean? In regulated industries, such as the medical and legal professions, recognized experts bestow the title upon the individual. This indicates that the individual completed certain courses of study and was tested and found to possess sufficient knowledge to merit the title. In many other fields, titles seem to have no relationship to experience or knowledge. There are programmers with years of experience who still call themselves programmers and there are students with a few months of instruction in one computer language who call themselves consultants. So what exactly is a consultant? I once heard a story that I feel explains the concept.

The Ministry of Tourism in Rome had a problem. It seemed that hundreds of cats prowled the city's famous sites, scavenging food in trash cans and yowling at all hours. Tourism was declining and the number of complaints led the Ministry to conclude that the cats were the cause of the problem.

First, they decided to destroy all the cats, but someone suggested that they could save money if they destroyed only the cats of one sex. Without mates, the cat population would gradually decrease. Then someone suggested that they could save even more money if they did a study of the cat population and discovered which sex had fewer members. The study was completed and it was discovered that there were several hundred female cats and only one male cat who protected his territory with zeal. They decided to capture and destroy the male cat and thus solve their problem.

A newspaper picked up the story and reported it. Overnight the male cat, now named Rudolph, after Rudolph Valentino, became a local hero. Protestors marched in front of the Ministry of Tourism demanding that Rudolph be allowed to live. Faced with this opposition, the Ministry decided that instead of killing Rudolph, they would have him neutered. One night the fateful deed was done.

Soon the female cats discovered what had happened. They began to call mournfully for their champion. Their yowling rang through the night. Neighboring tomcats, learning that the city was now open to competition, began arriving from the surrounding areas. To their surprise, they found Rudolph strutting haughtily down the main thoroughfare, exacting tributes in return for allowing each tomcat entry to his domain.

"Why do you parade down the street with such pride when you can no longer perform?" he was asked.

"No longer am I an ordinary cat," he answered, "I am now a consultant."

This is a story that I like to tell both clients and prospective consultants. After everyone has had their laugh, I wait for the mixed reactions the story is almost certain to elicit. Clients like to point out that the story reinforces the belief that "Those who can, do. Those who can't, consult." The story suggests that consultants are people who, if they were not self-employed, would be unemployed.

As a consultant myself, I like to point out the other aspects of the story that clients usually miss. Rudolph had every reason to call himself a consultant. He had all the necessary credentials. These include years of experience and a long list of satisfied clients. The fact that he himself was unable to perform was incidental. It is not always possible or even practical to expect the consultant to do the actual work. After all, why should a client pay a computer consultant $75 an hour or more to code, when a programmer can do this just as well for only $25 an hour? This would be a waste of the client's money and a misuse of the consultant's special expertise.

To understand the consultant's role in supporting a client, one must understand exactly what defines a consultant. There is no scientific measure by which one can evaluate an individual's performance and decide whether that person is just an adequate programmer or consultant material. The decision to become a consultant rests with you alone. The decision to accept your self-evaluation and hire you as a consultant rests with your clients alone. There are, however, a few loosely applied rules that can help you in your general evaluation.

Broad Knowledge vs. Specific Knowledge

There is an old joke about a farmer teaching his son arithmetic. He shows his son that if he gives him two eggs and then adds two more, he will have four eggs. He runs through many variations until he is satisfied that his son understand basic arithmetic. The son is placed in a class for students who already know arithmetic. The teacher begins testing the students.

"If I take two apples and then two more, how many do I have?" she asks the farmer's son.

He begins to cry, "That's not fair! I only know eggs."

A programmer who has worked in one particular computer language for many years may be even more expert in its use than a consultant hired to design a system which will be implemented using that language. However, the consultant should be able to produce the more efficient design. While the best programmer can only produce a poor system from a poor design, even an adequate programmer should be able to produce a good system from a good design. So it is the design, which is the consultant's main contribution, that will ultimately define the project. The design is based on expertise in a number of systems and a number of methods. Programming can be based on one method and one language. Some people can spend ten years on the job but only have one year of experience multiplied ten times. In short, despite ten years of experience, they only know eggs.

Every client's needs are unique. A good consultant will recommend a different combination of hardware and software to each client, specific to each requirement. A programmer generally knows only one way of doing things. (One who only has a hammer treats every problem as if it were only a nail.) He will then design the system to fit his method of programming instead of the client's method of conducting business. This often results in a system that is inadequate, inefficient, slow and difficult to use. (In consulting terms, this is called a "kludge.") I have come across business systems written in slow and unwieldy BASIC, because that is the only language the "consultant" knew. By rewriting the system to take advantage of the routines developed in more efficient languages, I have often increased the system's performance. In one instance, I converted a monthly invoicing program from an overnight batch function that ran for twelve hours to a real-time function that ran in only forty minutes.

Experience - this is a rule that I consider unbreakable, though I have found that many so-called consultants and prospective clients treat experience, or the lack of it, lightly. I have come across programmers with a few months of experience on one machine, with one language, who call themselves consultants. I have even seen students with several months of instruction in one programming language pass themselves off as consultants. They are often hired, primarily because of their cheaper rates, to work on computers upon which they have not been trained. This has led to disastrous results for the clients. Even when the so-called consultant is familiar with the client's computer, there are still problems that can be encountered.

Computer system often use combinations of hardware and software developed by several manufacturers. There is always the possibility of a new problem surfacing that cannot be solved by looking in the manual or making a phone call. One of the most pressing issues in the industry is that of compatibility, where a software or hardware item will work properly unless used in conjunction with another item. When this occurs, several factors exacerbate the problem.

First, it is often difficult to determine what is causing the problem. Often, cards have to be removed from the computer and different programs have to be unloaded in order to discover the culprit. This may take hours or days.

Second, once you isolate the product, the manufacturer may refuse to assist in solving the problem. He may claim, rightfully so, that his product performs well in all tests and it is not his responsibility to solve a user's difficulty caused by an incompatibility with someone else's product. Since none of the items are actually defective, you cannot lay this problem at the door of the manufacturer or dealer. It is up to the consultant to solve it.

A programmer is only responsible for the code he writes. He does not have to concern himself with hardware problems and software incompatibility. A consultant is responsible for the entire project. It is his job to see to it that the system functions.

An experienced consultant will have established a network of other consultants who may have heard of this problem and its solution. If a solution cannot be found, someone may know of alternative methods of achieving the same result, so that you can replace the offending item by another which will not present the same difficulty.

People are often amazed that after they have spent hours trying to resolve a problem, they call me and I give them an immediate answer. Perhaps, like a stage magician, I should keep the secret of my incredible performance confidential. But I promised to reveal some secrets of consulting so here is how I do it:

Most of the questions asked of me have been asked before. Most of the problems that people run into have already been weathered by someone else.

An experienced consultant will have already run into many of the problems that can hamper a project. When I amaze a client by solving a pressing problem at a moment's notice, he may not realize that the reason I can do so was because a previous client had the identical problem and at that time I (or one of the other consultants in my "network") spent the hours or days necessary to solve it. There is no substitute for experience. The smartest programmer who has recently decided to call himself a consultant will run into new problems that a mediocre experienced consultant can solve.

Ability to manage time - at your daily job, you work for one boss. He assigns the work that he expects you to do. Sometimes he will ask you to put a project on hold and work on another, but it is rare for a boss to ask you to work on several unrelated projects simultaneously, or assign you more work than it is possible for you to complete in the time allotted. A good consultant works for several clients at the same time. (If you only work for one client and the project ends, the client goes bankrupt or his nephew becomes a consultant, you would find yourself unemployed. That is why it is necessary - not just preferable - to be working on several projects at the same time.)

Clients are funny people. Though they only pay you by the day or by the hour, they like to think that you will be devoting your full time and effort to them alone. They particularly prefer to enjoy this delusion when you have committed yourself to completing a certain phase within a specific period.

As a consultant, you and you alone will manage your time. If you are the type who is always behind schedule and keeps a prepared list of excuses, you may be shocked to discover that this will not work in private consulting. Your client does not want to hear about your personal problems, your car problems and he most certainly does not want to hear about your other clients.

Unlike an employee, a private consultant's time is entirely his own. There are no set working hours and no set vacations. Every hour that you save is an extra hour for you and every lost hour must be made up. If you are running a few hours behind schedule on a project, you cannot quit at 5 o'clock. If you are a few days behind schedule, you may have to give up that holiday weekend with your girlfriend (if you have time for one) or your wife (if she's still with you).

Ability to Think Independently - there are many bright people in the computer field who are excellent programmers. Given a set of system specifications or "specs", they can produce efficient code that will meet anyone's standards. Often, these same people hang up a shingle, obtain their first private client and then find themselves unable to write a line of code. They forget that clients do not give them detailed specs. In fact, most clients are often unable to accurately describe exactly what they want the program to do.

Programmers are told what to do. Most often they work with databases that have already been created, hardware already in place and a language someone else has already chosen. A consultant decides what to do. He must be able to listen to the client describe what he wants, determine what the client actually needs and then explain to client what is required. He must be able to develop his own specs, select the equipment and software that best meets the client's needs and produce the best system at the most efficient cost.

(Note: I will be using the term efficient cost to mean the lowest possible cost to the client for what the client needs. It does not mean the lowest cost possible, but the lowest cost that will not detract from the system's performance or expandability. I will use the term consultant to refer to a person who has the qualifications to be a consultant and the term programmer to refer to a person who is qualified to be a programmer but not a consultant. This is not meant to deride programmers. Many programmers are qualified to be consultants but choose to remain programmers, just as many consultants are not even qualified to be programmers yet choose to call themselves consultants.)

This is another reason why the consultant must be familiar with several different methods of working. A consultant who only knows one way of doing things may not know the best way. He is not presenting his client with a choice or with the benefit of a range of expertise.

Communication skills - programmers often deal only with other programmers. At work, their conversation is rife with jargon. It may be acceptable to tell your supervisor, "I want 500 megahertz clock speed with 0 wait states, 64 megs of PC100 RAM, 20 gigs of ATA 66 storage a database with transaction logging and referential integrity." The same sentence would send a prospective client rushing to the phone to find another consultant.

Some clients feel that if they can't understand their consultants, it proves that they hired highly skilled and technical people. Most clients, however, are smart enough to realize that if they can't understand the consultant, he probably can't understand them either. It suggests a serious communication problem and the consultant who can't explain what he intends to do in simple layman's terms is often unable to get a client. A most important goal in establishing a good client-consultant relationship is ensuring that the client and the consultant are both fully aware of what each expects.

Satisfaction - this is another important aspect that must be addressed on two levels. The first level is client satisfaction. Before a programmer becomes a consultant, he should prove that he can provide client satisfaction. This may sound like a Catch-22 situation, for it seems impossible for someone who is not yet a consultant to demonstrate that he can provide client satisfaction when he lacks clients. The fact remains that this should be easily proven or the programmer should remain with his regular vocation.

A consultant realizes that the term client can be interpreted loosely. Whenever you perform a service for someone, that person becomes your client. If you are a programmer whose task it is to prepare reports for your boss, he becomes your client. Before you decide to become a private consultant, you must prove that your client, your boss, is satisfied by your performance.

I have met many programmers who became consultants because of constant disagreements with their superiors, often after similar experiences in several different companies. If you have difficulties pleasing your superiors at your regular jobs then consulting is not for you. If you cannot please someone who is not paying your salary out of his pocket and does not risk personal loss when something you have written fails to work properly, what makes you think that you can satisfy a private client who has so much more at stake and will be so much more demanding?

(Also keep in mind that the worst that happens if you fail to satisfy your boss is that you get fired. Private consultants not only loss their clients, they can get sued. You can be sued for more than the payment you received for your work.)

On another level, you must obtain personal satisfaction. If you do not find consulting challenging and rewarding, but instead find yourself arguing with clients or griping about them behind their backs, then consulting is not for you. It takes a great deal of dedication to achieve success in the private consulting field. You must be prepared to work long hours, making less money than you would at a regular job. You must be prepared to smile and say "No problem" when a client asks you to change the report he had you modify Tuesday back to the way it looked on Monday. (Later I will discuss methods of preventing your clients from changing their minds too often, or at least making sure that you get paid for the extra work when they do.)

A good consultant enjoys the challenges posed by the possibility of a new client, preparing a new proposal, accepting a new contract and facing a different set of requirements. A good consultant does not moan (too much) when he has to spend unpaid time solving a problem caused by a bug in third-party software or hardware, because he knows that some day he may use the knowledge he gained in solving this problem to help someone else (and this time he might actually get paid for it!) At the very least, when the problem comes up again at another location, he can casually suggest the solution and amaze everyone with his brilliance.

What makes a consultant unique is the ability to apply previously acquired knowledge to a diversity of new situations and to determine which of the many methods used beforehand is the best one for this particular assignment. It is the difference between working by rote and actually thinking about what you are doing and determining the most efficient means of reaching your goal.

Before entering the computer field, I once had the privilege of studying under a brilliant teacher. Since this was a computer vocational school, he was not content with simply spoon-feeding the material to his class. Many of the students were just not of the proper mind set to become efficient programmers. They were just taking the class for one or more of the following reasons: a) it was something to do while they were unemployed, b) the government was paying for it anyway and c) programmers make a lot of money so maybe they could too. Few were taking it because they had a real interest. Not surprisingly, few actually passed the class and even fewer found jobs in the computer field. This teacher did not believe in wasting time and resources so that the class could be filled with bodies. He did not want to follow the watered-down syllabus designed by the school. He wanted to teach an advanced class so that those truly interested could learn enough to actually find a programming job. (And, unlike classes taught by others in the same school, a number of his students did become programmers for prestigious firms.)

His method was to have us learn the material on our own. When we had difficulty grasping a concept, he would then explain it. He also gave us assignments which carried these concepts far beyond the book's simple exercises. It soon became apparent which students would excel. Some read through the material and were happy if they could complete the exercises in the back. Some started study sessions and worked on the teacher's assignments.

The teacher then gave us a demonstration that clearly illustrated the difference between the first and second approach. In the book we learned how to create programs that manipulated a series of data records until it reached the end of the data. The program used a variable called Out-of-cards-flag to signify that the end of the data had been reached. When the last record had been processed, the Out-of-cards-flag became true and the program ended. The teacher gave us a program printout and asked us to find the errors. In his example, he used a variable called End-of-data to signify that the last record has been processed. A number of students marked this as an error and replaced it with Out-of-cards-flag. These students would have difficulty mastering complicated concepts if they could not grasp the simple fact that like math, a variable name could be almost anything the programmer chooses.

Of course this mistake could only be made by a student and no programmer (one would hope) would be unaware of that he could choose his own variable names. But it was a demonstration of the difference between one who comprehends and applies concepts to one who memorizes and repeats the same methods over and over again. In a consulting situation, new problems arise and the client looks to you for the solution. There is no handbook that categorizes your particular predicament with some patented answer ("In case of problem C13, use solution I93.") You will have to rely on your previous experience and your wide range of knowledge to think of a similar situation you once encountered and how you resolved it. Often this alone isn't enough and you may have to invent a new solution. However you handle it, you have to be able to do more for the client than tell him, "I only know eggs."

A consultant rarely accepts limitations. Just because a program states that it does not contain a certain function does not mean that it can't be made to perform that function. If I had a nickel for every time I made a program do something its own developer claimed was impossible I'd have, well, about 50 cents. But the experience of making the program more powerful and one-upping its own developer was worth a great deal more in satisfaction.

So before you decide to give up a steady job to become a consultant, make sure that you have the minimal requirements necessary to have at least the possibility of success.