Leadership

Five questions to test the sanity of your IT consulting advice

Before you present a client with a plan of action, there are five questions that you should ask yourself. Chip Camden discusses these "sanity check" questions.

 When a client asks for recommendations, it's not always easy to stay focused on their request. One IT topic often leads to another, so my answer to the question of how to solve a very specific problem can turn into a treatise on the history of programming. To stay on track, I ask myself the following five "sanity check" questions before giving a client advice.

1. What are you recommending they do?

Sometimes we become so enamored of our role as teacher, mentor, information provider, industry analyst, or guru that we spend a lot of energy enlightening clients. That's often necessary, but what our clients really want from us is a plan. Even if they don't want us to tell them what to do, they want options -- not theories. Industry standards and theories may support a plan of action, but you should never replace a plan of action with industry standards and theories. Make sure you're giving the client clear options and not just wise observations.

2. What goals would your recommendation fulfill?

Identifying the goals should be the first step in formulating a plan of action, but the goals often get lost somewhere along the way. Personal prejudices or strongly held beliefs sometimes lead our recommendations astray. You might say, "Of course they should use Technology X, because it's so powerful," but is the real reason because you want to work with the technology? One way to unmask those biases is to ask yourself, "Why do I want to recommend this course of action?" The stronger you feel about it, the more you should suspect yourself. Examine your motivations and then bring your recommendations back around to face the original goals for the project as stated by the client.

3. Can the client execute the plan?

One mistake that I've often made is to plan the project as if it will be executed in a perfect world. All of the team members will be able to give 100% of their attention to it, and they'll all be almost as skilled as I am. In practice, everyone will be interrupted by other concerns, they probably won't understand a lot of concepts that I assume are obvious, and I'm probably overestimating my abilities.

It can be very difficult to properly and honestly evaluate the team's ability to execute your grand plan, but you need to go through the exercise. Ask yourself these questions: Is there a simpler approach? Can we build in time for the unknown, as well as for research and training? Can we make some features optional and leave others for last so we can drop them like a lizard's tail and escape from the project when it turns into a ravenous monster? (In other words, you should consider ways to fit the project with escape valves to relieve some of the pressure.)

4. What might prevent the client from heeding your advice?

You may think that the stated project goals have top priority for your client, but you might be mistaken. Rarely will the survival of the company depend on your project, which means that some other consideration can always preempt your project's goals. Individuals within your client's organization may have different views on those priorities as well, and their reasons may have little to do with the success of your efforts or even the health of the company. If you understand the forces at play, you may be able to address more widely held goals and frame your recommendations so they have a broader appeal.

5. What are the chances of failure?

Assuming that the team will be able to execute your plan and that the company will support it, what is the likelihood that you're wrong about the end result? Perhaps I should rephrase that: You will be wrong about the outcome -- how wrong will you be? Of course, you can't know in advance that a solution will fail, but you can consider the probabilities, evaluate the impact of possible consequences, and build in contingency plans for the ones that are more likely and more damaging.

Conclusion

These questions share a common theme: seeing the problem through your client's eyes. Adopt their priorities as your own, understand their motivations, and evaluate threats from their perspective. Be wary of "correcting" your client beyond bringing something to their attention that they may not have considered. Successful IT consultants know that the needs of the client outweigh the needs of the ego.

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!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

16 comments
tuomo
tuomo

A great list, thanks, I will keep a copy - heh! Of course there are always exceptions, especially when working with / in a corporate with very good people, have had that. And then they really were looking more for an outside opinion than a plan, whatever even I charged them of the whole thing. Doesn't happen often but changes the rules a little and you make lifetime friends. One "sanity check" I learned a long time ago, maybe you can't always select your counter-players so before you do your own plans, check with whom, on what level, how many, etc you can/have to count on / influence / include to the plans/project, and so on. All other preparations, designs, selling, etc can come to a surprise halt otherwise - or may even come back haunting you much later / next time. You kind of included this in 3,4 and 5 (1 and 2 is more technology?) but my experience is that knowing the players before any plans is often needed, even CEOs see different IT technologies and methods based on their previous experiences, whatever and sometimes react strongly when/if they learn some group / organization / etc working in different view. And I don't even want to mentions some lower level CXXs, VPs, etc who, right or wrong, think that they know everything (in IT).

Da Saint
Da Saint

While documentation has always been the "red headed stepchild" of IT, you really can't do without it. Working with Small Business/Home Office types, I always ask for whatever technical information they have (which 90% of the time is zero). Part of what I offer on every job is to provide the docs they don't have and really need. Not only does it give me a record of what I've done but it also provides my customer with the kind of information that not only gives them a foundation from which to grow as well as something they can show their insurance carrier in the event of a disaster. It's the "optional service" I offer that hasn't been turned down yet.

Sterling chip Camden
Sterling chip Camden

I'm slowly getting better at it. It's been one of the hardest habits to get into for me.

tracy.walters
tracy.walters

Two other recommendations....probably seem obvious, but: 1. Do the solutions your are proposing have availability from multiple vendors (hardware/software/services)...many organizations require a bid process. If parts are single sourced, it makes it difficult....the client should know it up front. 2. Who is your audience, and are your recommendations written so they can understand it. I tend to write my recommendations with three groups in mind. Executive management gets a short summary with high level goals and timelines at the start of the document, Middle management gets a more detailed section in the middle, concentrating on dates and money, and the last section has detailed timelines, specific implementation details, sourcing recommendations along, with specific achievable goals that those tasked with actually implementing the project can see and relate to. This format also allows me to do the old adage of 'Say it, say it differently again, and say it a third time'

biancaluna
biancaluna

That is great advise, Tracy. The multilayered document is exactly what I use as well, I did a Shipley proposal writing course many years ago and keep my technical writing skills up. I always ask myself - so what, the old so what gauge of sanity is a great method. Never mix up benefits with advantages either. I've used the term Rubik's cube a lot in my responses to Chip's topics, and I shall use it here yet again. There are different views of the "solution" and it is our role to present that in many ways.

Sterling chip Camden
Sterling chip Camden

The part of Tracy's comment that I like best is tailoring the recommendations to the various audiences. Poor presentation can kill great ideas, and "poor" is in the ears of the hearer.

Sterling chip Camden
Sterling chip Camden

What's the last thing you think before you press "Send"?

B_Dillon
B_Dillon

When giving advice regarding a technological approach where there are multiple emerging technologies I always ask, "What is the liklihood that the technology I recommend will not succeed?" The best technological options don't always win out in the end.

Sterling chip Camden
Sterling chip Camden

... how important is the future viability of the technology to this project? If this project is a one-off that won't need to grow much in the future, then a technology that subsequently becomes obsolete doesn't cause a problem. But if you're developing something that you'll want to move forward to new OS versions and platforms, then it absolutely matters.

Sensor Guy
Sensor Guy

The first and last sanity question I always ask myself if "Why am I giving these/this particular recommendations/proposal/deliverable to this client at this time? What's in it for the client and what's in it for me? Booz used to have a great methodological question to ask yourself always: "So What?" The "So What?" test done recursively reduces the amount of client deliverable and proposal content to the proper minimum essence of what the client actually wants, needs and in fixed price deals, what you can afford...

Sterling chip Camden
Sterling chip Camden

Some recommendations get made because they have all the right buzzwords or for some other reason they seem like what you're expected to recommend. "So What?" helps to deflate that.

biancaluna
biancaluna

You may have stated this in a different way, Chip. The reason I bring up policy is that it is never about the technology is it. I've recently made a proposal to a client for an archiving solution which included policy based decisions in the business rules of the archiving software. Sounds like industry standard right? Except that the policies did not exist even in a rudimentary form in the organisation, and as such, I had to build in a layer of influencing in the plan. If I would have come out and said - hey you need to stop your users from saving images of their kittens to your precious primary storage that would have gone down like a lead balloon. But by making the links early on in the piece and the proposal (low value data on the primary means uncontrolled data growth means high backup costs means capacity problems means non compliance to research standards) I was able to plant the seed. It also meant more business for me, as I had previous experience in developing policy. But I built on existing skills in the organisation, and the ones that were missing as you suggested. That way I was able to keep my own motives out of the equation, which were good mind you, I really wanted to help this client to the next level :). But you are spot on, if you feel very passionate about what you believe a client *should* do, you need to question it. I have seen many technical consultants recommend the latest play thing, or high end hardware solutions that could have been provided with intelligence, understanding the business and software. Specifically in the archiving space. So probably the last thing I think of when I press send, after the peer reviews, the so what gauge (so what if this thing does xyz, what does it mean) and assessing it to industry standards and trends is this question - Do I understand their business enough to be able to press send? Have I demonstrated that I understand their business, both the nature of, their strengths and weaknesses. Can this client implement this and can they support it ongoing? Can they effect the transformation required? Does my proposal align to the portfolio and strategic plan? Is there a strategy (formalised or inferred) and a technology roadmap for the next few years that can be seen as a product release path? That way they know what needs to be "plonked" in when. Oh those are a few questions.