By Chip Nickolett
If you're considering moving into consulting and are eager to learn about the role, or have already hung your first shingle, it's wise to make sure your skills and expertise can match the job's expectations, as there's a distinct difference between a contractor's role and a consultant's role. Understanding the role, responsibilities, and professional requirements of each is key to succeeding in a consulting career.
When I served as an MIS leader, a role I held for eight years before moving into consulting a decade ago, I'd worked with consultants but hadn't been impressed. Often, the consultants' technical and analytical abilities were less than what I managed on staff. Many would state what was wrong, without making recommendations for improvements, or would make recommendations that were either too vague or impractical.
Then I met a consultant who was very good—he came up to speed on our environment quickly, took the time to analyze the environment and the work performed to date, asked a lot of questions in a nonjudgmental way, made a few suggestions that we tested, and then made his formal, specific recommendations. A lot was accomplished in a relatively short period of time, and I really saw the value of his work.
About two weeks later, he called to see if we had implemented any of his recommendations and, if so, what the results were. I commented that I felt that he was the first good consultant I had ever worked with. He said the project experience was "the difference between a true consultant and a contractor." And he was absolutely right.
Understanding who and what a contractor is
Now that I run a consultancy, I'm constantly interviewing people who have a consultant title but who actually fall into a contractor category. Contractors, in my definition, are focused on a single type of mid-level activity—such as programming in a specific language or with a specific tool. Contractors focus on a limited scope. They work on specific tasks at the direction of others and often are unaware of the scope, business goals, or impact of the overall project.
Is that bad? Absolutely not. Contractors generally fill a void in the skill sets of their clients or provide additional resources for accomplishing a goal. Often, these contractors really like what they are doing, are good at it, and don't have a desire to change roles. And there is nothing wrong with that.
The role of a consultant
A consultant role is much more layered than that of a contractor; consultants often multitask and handle more than one project at a time.
A consultant is often tasked with leading an initiative rather than waiting for specific direction. For example, instead of waiting to be asked what the status of a task is or what tasks are outstanding, the consultant provides a list of tasks, the status, and a schedule. Instead of doing just what the client requests, a consultant looks for other opportunities for improvement while doing the expected work.
Consultants aim to get an understanding of the overall scope and goals of a project, make sure that they understand the deliverables, and offer specific suggestions when it makes sense. And all of this is done relatively quickly without having a negative effect on productivity.
A consultant should provide an increase in the breadth and depth of technical skills, an improvement in analytical skills, and the ability to clearly and concisely communicate important information in a timely manner.
Some people could view the consultant role as a jack-of-all-trades and master-of-none. But that is not the case, or at least should not be the case. I often tell people that it's necessary to know a lot about a few things and a little about many things. The reason is not so that you can pretend to know everything, but rather that you can have a good working knowledge of what is going on around you. This knowledge provides a better overall understanding, helps you theorize and make assertions, and, most importantly, gives you the ability to ask intelligent questions that may lead to answers more quickly.
Rather than react to an issue, the consultant will identify potential issues, address what can be easily taken care of, and let others know of the potential problem. In contrast, a contractor may stipulate that there is a problem but not suggest ways to resolve or mitigate the problem, the level of effort required, and the risk involved.
Moving into the consultant role
If you're essentially a contractor at this point and want to start a consulting career, you need to focus on three specific areas: communication, business skills, and technical skills.
Clients want quick, clear, and accurate answers that are easy to understand. They want the answer first and will not always ask for details. When a problem occurs, you need to be prepared with a brief statement: "The systems have been available since 10 A.M., the cause of the failure was X, and we are now following up with vendor support on this problem." Know what you want to say and find a way to do so in a few sentences. This builds client confidence quickly.
I was once part of a conference call regarding a consultant's performance issues. During the meeting, the consultant was asked how long a database query took to complete. The consultant replied, "Four or five seconds, or maybe a minute." That answer didn't do much for the consultant's credibility. Accuracy is important, and you need to keep important information readily available. It is far better to reply, "I don't know but will find out for you," than to make something up.
To sharpen your business skills, use this self-practice method: Read tech case studies, critique them, and then determine what was effective and why. This will help you practice the kinds of responses clients expect.
Our consulting firms provide staff with technical manuals and books on business and technology. Business books provide insight into ways of thinking about problems and ways that other people have addressed them. The key here is not to fall into the trap of changing the way you do something every time you read a new book. Rather, compare what you have read with what you do and look for ways to enhance your skills with the new techniques.
Technical manuals provide a better understanding of a product (for example, why something works in addition to how it works) and a better understanding of the architecture (good to know for the proper use of the product). You can leverage the knowledge acquired later to solve problems or to identify solutions. Also, read general books about other technologies not directly related to what you do.
Taking notes while working with a customer is also good practice. It sends the message to them that what they are telling you is important and that you're paying attention. At the end of the meeting, restate what you understand the key points or issues to be and what the specific action items and/or deliverables are. Doing so will help ensure that you're spending time doing what is expected, without being specifically directed to do so.
When it comes to consulting projects, it's a good idea to complete each one with an in-depth overview and answer these three questions:
- Think of ways that the project could have been done better. Were opportunities missed?
- Were assumptions made that later turned out to be invalid?
- What lessons were learned that can be applied later?
Dangerous career traps
Many new consultants fall into the trap of feeling that they are "the best" at something or are better or smarter than their customers. Both of these are dangerous. I tell our consultants to try to be the best, but to realize that there is always going to be someone better or a better way to do things. This perspective helps keep you at your best, continually improving what you do and how you do it.
A true consultant can add value to a project. You don't just look at what you're being asked to do, but question it—ask, "Is this the right thing to do?"
Consultants are willing, and eager, to look beyond assumptions and not jump to conclusions. They also aren't afraid to try something new. I encourage new consultants to develop a small Java or C program in their spare time, download an evaluation copy of a database product and play with it, and keep building their skills.
In the end, the increased knowledge should lead to improved processes (troubleshooting, planning and implementation, even documentation). This leads to increased productivity, even if it is only due to a better understanding of the deliverables expected. And all of this adds value to your career, to your employer, and to the companies that you do work for. Everybody wins.