IT pros looking to cash in on the rising demand for IT consultants, know this: IT consulting isn't all golf meetings and extended lunches. In fact, it can often involve thankless work fraught with unexpected detours, murky goals, and the occasional sudden jettisoning of your project.
But it can also be exceedingly fulfilling and empowering to improve the fortunes of your clients. Build a respectable business as an independent IT consultant, with a healthy client roster, and it can be lucrative as well.
While there's no script to follow in becoming a successful IT consultant, several hard-learned lessons can help guide your way. Anyone considering breaking out on their own or trying to take their already established consulting business to the next level should heed the following 10 commandments of IT consulting success.
1. The client is the hero -- and the hero defines success
Every consulting gig is an adventure. Bureaucratic hurdles, technical constraints, unsavory politics -- delivering the right solution, on time and on budget, is a significant challenge every time you sign a new contract. But before you embark on this journey, remember this: The client is the hero of this adventure, not you, not your company, and certainly not some shiny new technology that’s caught your eye.
When consulting, your role is mentor. And your goal is to guide your client in a manner that ensures they prevail on their own terms. The success of your gig is defined by the client, not by you or your company. That may sound simple, but it’s much more complex because client success is defined by the goals and expectations of three parties: the person at the client site who champions the cause for which you labor, the users of the resulting system, and the patron with financial responsibility for the project.
Suppose you're working with the IT manager (champion) to build a new system for the production manager (hero) for use by inventory specialists (more heroes). The stated business goal is to speed up inventory operations, and the project is funded by the CFO (patron). Deliver a solution that speeds up operations as everyone initially agreed, in a sufficiently quantifiable way, and the project succeeds, right? Not quite!
The champion will also want to limit the impact on his budget and equipment. The heroes will also want simple interactions that are metaphorically similar to their existing process, on devices they can reliably use one-handed, and that will allow all of them to work on the same order at once without issues arising. And the patron wants to see ongoing proof that her investment is paying off.
Success is now defined as the technical goal plus your ability to find a way to support the new system within existing capabilities, as well as your ability to engage heavily with users for UX design and measure and report before-and-after metrics that demonstrate ROI at each iteration of the project.
2. Listen for the unexpected
When starting a consulting gig, there is always too much to absorb. What is the nature of the technical environment? Who are the people on site with the greatest insight into the problems you need to solve? Where are there opportunities to rework processes to better ends? What technical and bureaucratic constraints are you dealing with? How much of what the client hopes to accomplish is a pipe dream?
Your first duty is to actively listen, so your understanding of the project, the players, and the environment is shared. But you need to be discerning. Much of what you hear will be run-of-the-mill, and some will be outright speculation and fantasy. Absorb these, but don't dwell on them. The ordinary parts of the system may hide surprises, but you can't dig into every detail right away. Instead, keep the conversation going to cover as much of the high ground as possible.
While you are doing this, make special note of any unexpected or unusual issues that arise. These can be both a problem and an opportunity. For example, having to talk to a back-end ERP system is fairly ordinary, but having to talk to it by directly manipulating its database is not, and it may cause significant bottlenecks and interface issues.
3. Reserve judgment
Don’t shoot down the client’s ideas on technicalities right out of the gate simply to look smart. The point isn’t to tell them why their idea won’t work; the point is to understand where they are trying to go with their idea, and to find a better way to help them get there. There will be time to get into technical details as the gig evolves, but the outset is for absorbing the bigger picture. Debating details or shrugging off what you perceive to be a “bad” idea will blind you to the kernel of a good idea hidden within.
For example, let’s say the idea of simulating the entire complex production environment in the cloud is proposed as a way of testing deployments. Likely, doing so would be unfeasible for technical reasons, but it has the kernel of a good idea buried within: perhaps we can deploy to the cloud instead of the existing complex production environment? The possible answer: not yet -- but it could be a good move worth putting on the table.
4. Technology is not holy
There is nothing special about a particular technology that makes using it more important than achieving the client’s success. Resist the temptation of shiny things that do not matter. Instead, advocate for the practical tools that do matter. Industry awards and accolades are far less important than a functioning system. Consider the client’s constraints and future plans to use the right tools for the right jobs, with respect for both.
For example, your team knows that HotTechTool2020 would be perfect for this new system. It offers the performance you need, supports all the latest browsers, and could cut development time by half. But it requires new production hardware and takes several months to learn to use well; furthermore, none of the client's developers have even heard of it.
While the hardware costs might be surmountable, the client's developers are comfortable with OldTechTool88 used by the current system, and the client doesn't think it could find enough hotshot devs to keep your newfangled solution going once your team is done. After some discussion, you all agree that upgrading to OldTechTool1999 is a more sustainable path.
5. Respect the client’s privacy and reputation
The client may not want their competition to know they’re working with you, much less what you are working on. Respect the client’s privacy and reputation with silence; never mention the client’s name without permission; even then, do so judiciously and to mutual benefit.
Simply talking glowingly about those you're working with at the client site can haunt you, as you never know who is looking to steal away talented people. A conversation in a hotel bar could well lead to your champion being poached, and now your project is suspended indefinitely.
6. Momentum is everything
It takes time to understand a technical environment and to absorb the implications of any change you might make to that environment. Give the client, and yourself, sufficient time between discussions to allow for dissemination and internal discussion, as warranted, but be mindful of momentum. Often when the process slows down, it is because the next decision or commitment is larger than expected or anticipated, so don’t wait too long to reconnect. Take smaller steps if necessary, but keep moving.
Suppose your proposal for the first set of deliverables has been submitted, and you're waiting for the patron to approve it. And waiting. And waiting. After several days, you're still being told that the proposal is under consideration, but your grapevine is telling you the patron is reeling from sticker shock and questioning the sanity of everyone involved.
Often this will be because the client has never used an outside consultant before, and the size of the first commitment is scaring them. Re-engage with the client, verify and validate their reactions, and lead them into a discussion of smaller, less scary first steps, to maintain momentum.
7. Communication is king
Efficient, responsive communication keeps the connection strong. Don’t waste everyone’s time with unnecessary meetings. Don’t waste the client’s time with unnecessary requests. And whatever you do, don’t waste your own time with nonproductive activities, even when requested by the client.
For example, it's not unusual for clients to request detailed activity reports, time sheets, daily status updates, and any other number of periodic administrative reporting activities -- because that is how they are used to managing internal projects. Most of these are a waste of your time and theirs, and you can often prove it merely by totaling the time required for paperwork and meetings and presenting that total not as a drain on productivity, but as additional overhead. Saying, “All this paperwork costs the team 10 hours a week each,” is less impactful than saying, “The administrative overhead is costing you the equivalent of an extra team member; let's discuss what is truly necessary.”
8. Honor your reputation
Your reputation and your company’s reputation are primary assets. Respect that, and yourself, at all times. This includes not only what you take on but what you don’t. Make no outrageous claims on your website or in private, make no discomforting promises. It is better to say no to a project and keep your reputation than it is to say yes and lose integrity.
The most common -- and seemingly benign -- mistake of this type can be vendor affiliations, which are a double-edge sword for your reputation. If you claim affiliation with a specific vendor's products, everything you say may be viewed as a sales pitch originating from the vendor. Morever, the waxing or waning of the vendor's reputation will reflect on you, for good or ill. People will also likely doubt your ability to deliver on jobs that don't use the vendor's products, and there will always be the underlying question of whether you are using the right tool for the job or settling for the best the vendor has to offer and ignoring better options.
9. Believe in the truth
Speak the truth as you see it, even when the client does not want to hear it. Truth should not be a hammer; it should be a window.
No one wants to hear bad news, let alone bad news that is the result of their actions. But sometimes, you have to deliver the bad news anyway.
Remember that it is not your place to shield clients from unpleasant facts. Simply present the information in a neutral fashion without your interpretation or conclusions, and let the client draw their own conclusions. It is far better to say, "There is an issue with Invoice vs. Quote discrepancies caused by unexpected charges," than it is to say, "The VP is altering invoices to favor his friends and punish his enemies." The former is a presentation of facts, while the latter is a conclusion and accusation.
10. Love thy client as thyself
Every project ends, eventually. Sometimes the end is planned. Sometimes you can see the end coming. But sometimes it is a complete surprise. Regardless of the circumstances, remain grateful for the trust and work received, make sure the client has all of the information they need to continue without you, and always maintain a professional, helpful demeanor.
A contract suddenly ending is rarely about you, so don't react to it emotionally. Love thy client, and let them go in peace. You never know what will come, but gratitude and serenity will more likely keep you in their sights for future contracts.
- Download: The professional programmer's business survival guide
- Download: 29 tips for succeeding as an independent developer
- Download: InfoWorld's quick guide to Linux admin essentials
- 14 nightmare clients -- and how to defang them
- 13 insider tips for acing your job interview
- 10 hard-earned lessons of a lifetime in IT
- The 14 mistakes that will kill your independent development shop
- 15 tips for success as an independent software developer
- Boom or bust: The lowdown on code academies
- Fatal distraction: 7 IT mistakes that will get you fired
- The best of the worst: The dirty IT jobs hall of fame
- 15 technologies changing how developers work
- 12 ethical dilemmas gnawing at developers today
- 15 workplace barriers to better code
- Bloopers, breakdowns, and bad jobs: The IT chronicles