Consulting 102

Marvin Bower (1903-2003) outlined the criteria for an outstanding consultant: “Mental equipment -- the successful consultant has outstanding analytical skill and the ability to synthesize his thoughts readily in reaching conclusions, He is a quick and effective learner -- imaginative and creative.”

Why does a company hire a consultant?

Your next project resulted from a company making a decision about a few things. A decision to implement a given technology starts the process. Then the company looks at their staff and asks a few questions.

Does our internal staff have the knowledge, skills, and abilities (KSA) to accomplish the project successfully? If the staff has the KSA, do they have the time? If the KSA and time exists, do we want our staff to make the effort to tack on yet another skill set in a specific area – a skill set that might not ever be used again? Perhaps the time element is viewed another way – the project is a high-burner – it must be done and now!

Maybe management doesn’t trust their staff. Or maybe that same management just wants some outside perspective. Sometimes the answers are clear cut; other times the decision path is not so clear. And then, you can always compare my thoughts to some famous thoughts on business consulting – while we might be tech-oriented, make no mistake, we are in business first.

At any rate, here you are going into an unknown environment to accomplish a set of tasks and you may or may not have the support of the internal staff. In some cases, you might be facing classic passive-aggressive staff behavior. This is especially evident when someone’s favorite application or system is being replaced. Oftentimes this threatens a job. Or the perception of losing a job. At this point you may wish to educate yourself on Maslow’s Hierarchy of Needs – and then apply that concept to what you might see as a consultant on day one walking into a new project.

What is the point here?

If, like my current project, the internal staff is bending over backwards to help and be successful, then you should have no issues provided you don’t start lying to them. You can just do the Honest Abe thing and work your process. A couple of things you should always do:

Make it clear to the client staff that you cannot be successful without their participation – after all, they know their environment, not you.

For email, create a local DL in your email and use it for EVERY email that is project related – then EVERYONE knows – and no one person is singled out.

But what if you run into the opposite scenario?

The Bad News

There is no silver bullet for the bad scenario. But, some preparation can help you overcome the obstacles this scenario will place in your way. At the delivery level, you must make every effort to quickly become part of the internal team, and a leader of that team. But there might be times when a customer is simply dysfunctional at echelons above the project team level. You can be a great part of the project team and still have a miserable experience.

What to Do?

Never argue. State your case in technical terms. Make sure that your communication process is not “personal” – the use of pronouns needs to be replaced by the company entity. The “team” is accomplishing, not you, and decidedly not a single individual in the client company.

Obviously, having your technical and project process firmed up will assist because you won’t have to think about those aspects. Know your DISC and Myers-Briggs. Work on your skills there to identify the different behaviors and personality types. Perhaps a simple change in communication style will smooth things out. My boss in Korea was a HUGE C (as in DISC). It took me a few head-butts, but I eventually figured out how to communicate with him, and after that, no problems.

Focus on the technical, let the PM handle the other parts. Communicate with your PM. If you are having “issues” then the PM is the first person who should know about it/them. Have you run into the aforementioned dysfunctional management? Let the PM handle it. Or turn to your manager and beg/ask for help and guidance. After all, that is why they exist.

Issues that arise can almost always be blamed on bad hardware, the vendor documentation stinks, or some other lame excuse, but NEVER blame a customer staff member- even if they are to blame. However, another NEVER is to accept blame for something that you did not do. Rolling over does not make things better – it just causes whatever it was to occur again.

A twist on that is to deliberately give credit to the individual(s) who are resisting the project whenever you can. That way they start looking like a project hero, which makes everyone feel better about themselves; and because it came from the Object of Hatred, they are more likely to back off.

What’s the Bottom Line?

Evaluation of personality styles, and how to communicate with those various types. Personal integrity counts very high. Knowing why you are there, and what it is you are doing as part of the project team. Back in a previous lifetime, this was known to me as “be tactically and technically proficient.”