As you might have deduced from some of my previous blog entries, I work as a software engineer for a large consulting firm. That firm works on a project basis, in which personnel works at the client site rather than from a central office. As a result I have quite a bit of contact with our customers; I talk to other developers (who work for the client) to cooperate on development; to architects to talk about software design and the IT landscape; and from time to time to the business for requirements analysis and test coordination. I’ve been doing this for a couple of years now and have developed a style of working based on full honesty and willingness to cooperate as much as I can with whomever I am talking to. I’ve found this to be a style that gets good overall results. I’ve had compliments on my way of working from almost every manager I’ve reported to and it has gotten me a number of promotions.

Some consultants have a different way of working. Some consultans feel that the primary concern of the consultant is to deliver “on time and within budget”. Which means that “managing expectations” and “limiting the scope” and “preventing scope creep” are their primary concern rather than weighing the needs of the customer. For example, I recently had a minor disagreement with a colleague from my firm who sees things differently than I do. Some days ago he was in late, so he missed a meeting we were supposed to have with a team we are working with on a project for the client (referred to commonly as “the business”). The business had come to them complaining very vociferously about response times in our common software. The other team (led directly by people working for the business) had come up with some ideas for improving the response times and asked us (i.e. me) if we could investigate the feasibility of one of the ideas and do an estimate for the implementation. We both agreed that as ideas go, this one was horrible — but we both saw the necessity. So I agreed to investigate on our side and do an estimate, under the understanding that the business architects and this colleague should all agree to the solution before implementing.

The colleague didn’t agree with my course of action. He felt I shouldn’t even have agreed to the investigation. It might lead to extra work on our side and at least discussions. Undesirable. Which left me wondering: what the hell are we doing here?

Consultancy, in case you didn’t know, is derived from the Latin verb “consulo”:


  • to consider maturely, to weigh, to ponder; (with dative: ) to look to the interests of
  • to consult, to ask advice of

The meaning of the word tells us two things. The first is our function as consultants: people come to us for advice, to help them achieve goals they cannot achieve on their own.

The other, looking to the interests of those people, speaks to something less obvious: our professional responsibility. People come to us for help and we agree to give that help. That means we have responsibilities to our clients. To do our best for them, to put in our best effort and to be on their side.

Of course, sometimes we have to think of our own interests as well. Sometimes we don’t quite tell a customer that we don’t know something and take a chance on our being able to learn in time. And sometimes we have to tell one person from the customer company “no” in order to keep our schedule and meet the desire of the company overall. But still, even when looking out for ourselves, our professional responsibility remains. We must still remember that we are supposed to be on our customer’s side. The customer is not the enemy.

It gets even worse than sketched above, though. Sometimes our own interest is temporarily contrary to that of our customer. It is tempting at those times to say “screw the customer” or worse: not just say it, but actually do it. At these times even more than others our professional responsibility must guide us back onto the straight and narrow path. It falls to us to find a solution that satisfies both parties as much as possible and not to allow the situation to deteriorate to the point that the customer no longer trusts us and the relationship becomes unworkable.

What is never acceptable for a real consultant is to follow a course of consistently placing ones own interests above that of the customer. We are trusted (and paid) by the customer not to do that. How can we be trusted advisers to anybody if the customer keeps having to watch out for us showing up behind them with a knife?

There is a challenge though, from time to time, in staying the course. A huge hurdle (in fact) for some. At times it takes tremendous courage to be a good enough adviser and trustee to your customer to admit that you don’t know everything or that you were wrong about something or that something will not get done. For instance if a project simply will not be done on time. Or if it turned out that a choice you made as a consultant was simply the wrong one.

It is very tempting for us as consultants at times like these to go into panic mode. To try and cover up and hide the mistake, to try and throw extra manpower and overtime at the project to get it done on time. With as inevitable result that the effort to hide your shortcomings will come back to bite you in the ass at a later time, only worse. Hiding a mistake usually means covering it up with a quick fix or a workaround, which will inevitably break something far worse in the next release. More manpower, more overtime? Tired developers, more bugs, huge problems in the aftercare phase, next release and possibly even a greater delay as you have to postpone the go-live to fix the bugs introduced by developers who wouldn’t have made those bugs if they hadn’t been working fourteen-hour days.

In his book “Extreme Programming Explained: Embrace Change”, Kent Beck talks a good deal about courage as a principle of software engineering. If something does not work, will not work, or would simply be better if completely rewritten you as a software engineer should show the courage to throw it all away and start from scratch — despite the fact that “gut instinct” and “common sense” normally tell you that going backwards is a bad thing. Something similar applies to consulting: if a strategy for a project, a management style or an advice is not working, you should have the courage to tell your customer so and scrap it. Your customer and therefore you will be better off in the end.

Put another way: “consultancy” cannot and should not be the same as “covering your ass”. Consultancy is about helping your customers. Helping them improve their business by building better systems, for instance. Which means obvious things, like guarding the quality of your code and improving the quality of existing code. But it also means less obvious things, like being willing to take risks in order to reap rewards and benefits for the customer (even if the customer might not see it himself). Sometimes you just have to take a risk and refactor an important piece of software to improve it. Sometimes you have to take a risk and trust the judgment of a junior because he has a good idea or even just because trusting and supporting him now will allow him to grow into a far more valuable employee later on. And helping customers also means branching out: learning their business so you can meet them halfway when talking about goals, desires, requirements and designs. It means being honest about when a schedule is unrealistic or unfeasible or when deadlines will not be met. It even means leading them to the right conclusion, from time to time.

And sometimes, despite the fact that missing a deadline may look bad towards upper management and you fear it will reflect badly upon you, it means sitting down with the customer and deciding that missing the deadline is necessary in the interest of quality. Because your customer will be better off because of it in the end and that (when all is said and done) is the final goal.

After all, if you don’t want to help your customer…. what the hell are you doing working as a consultant?

“Consultancy” != “Cover your ass”

13 thoughts on ““Consultancy” != “Cover your ass”

  • Pingback:My Mate Ben – Jamie Dobson

  • December 11, 2008 at 10:33 pm

    Thank you, Sidney, for this exampleof your usual, great insight. It would be foolish of me to argue the wisdom of what you say, so I will not. 😉

    The details of the specific incident aside, though, I do want to make it very clear that I stand by the point of my original post in general: consultancy is not about covering your ass, but about earning the trust your customer has placed in you.

  • December 10, 2008 at 7:34 pm

    Some notes from the POV of a colleague familiar to the case at hand: I believe the described situation relates much less to the “Cover Your Ass-mentality” Ben argues, and more to a question of authority, in this case a project manager-consultant versus a subject matter expert, SME. The moment the SME decides a course of action (i.e. helping the client by agreeing to an investigation), he steps on the authority of the consultant, who firmly believes that decision to be his responsibility and his alone. The consultant does not entrust this authority to anybody, because doing that threatens his standing and his control over the situation.

    A different aspect of consultancy comes into play here, politics and the hidden agenda. I think it is an ideal to be free of either, but the reality is, we have to deal with both. People will do everything to protect their interests, be it a certain place in the hierarchy, a certain degree of wealth or the favour of a particular stakeholder. And people will protect their positions if they are threatened. In this case the threat is the SME taking a decision which was not his to make according to the consultant. If that protection requires a move counter-productive to the client, so be it.

    On a positive note, I firmly believe there are ways of dealing with this kind of destructive behaviour, while still doing consultancy in a positive, constructive way. In my experience it does require a little mud wrestling, and you’d have to be prepared to get dirty. Plus, the risk exists that you fall into temptation and commit the same errors of judgment you were supposed to resist. The prevent this, your mindset must be slightly rebellious, but definitely committed and disciplined.

    If a project manager-consultant is lucky enough, he might find himself in an ideal project situation: having strong, pro-active, intelligent professionals on board, who work well as a team and as individuals, who can be trusted with all that is required to achieve a common goal, without the need of detailed instruction. If he’s really, really lucky, he gets to grow such a group from the ground up. The situation Ben described concerns failing to recognize the luck one has to be in the former, and going about the wrong way in doing the latter. All because one’s position and standing needs to be protected.

  • December 3, 2008 at 3:51 pm

    Hello Adrian,

    Thanks for your comment.

    If you read my 2 replies above I don’t see any conflicts with how you feel about what a “good” project manager should do and my 2 reactions on Ben’s Blog article. In other words, I agree with you(not with the “pessimistic” part though, I see it as “realistic”).

    Also, I think your third point(of how a PM should act) is what happened to Ben except the gently part I am afraid..

  • November 29, 2008 at 10:18 pm

    Rick, your comments:

    “Fact remains that managing a group of individuals who decide form themselves what jobs they do will make a project managers job a hell. No (good) project manager will accept and allow that to happen (at least I wouldn’t).”

    “In case of the last you will be corrected by any project manager(good, bad or ugly) to stick to the planning instead of deviating from it.”

    seem to assume that individuals will always decide to deviate from the plan, which I find very pessimistic.

    I’ve always felt that a good project manager tries to give as much responsibility to the developers as possible, whilst: 1) always knowing exactly what stage they are at; 2) what they are working towards and 3) roughly how long it will take to get there. It should be clear to the PM if something is going wrong and they need to (hopefully gently) readjust the direction of the developers.

  • November 29, 2008 at 8:07 am

    Hiya Rick,

    How are you mate?

    I won’t disagree with any of your points there. However, some PMs, good, bad or ugly, do like deviation from plans. I don’t mind it, focusing purely on value. My clients seem to love it…

    Watch out for the master:

  • November 27, 2008 at 3:09 pm

    Hey James,

    That has been a long time.

    “As a project manager you should be aware of the tremendous motivation that autonomous behaviour brings.”

    In my opinion this is heavily dependant on the developer your are facing and from experience I know that developers and consultants can be frightend by the fact they are not guided or coached in what to do and when to do it.

    Secondly, I think this is greatly dependant on the client your are working for. If it is a big account with countless (big)projects I guess the space to move freely is bigger then a new client with 1 big “high exposure” project.

    In case of the last you will be corrected by any project manager(good, bad or ugly) to stick to the planning instead of deviating from it.

    Nice to talk to you again(via this blog).

    Regards, Rick

  • November 26, 2008 at 9:26 am

    Thank you, Jim. As always, your appreciation means a lot to me.

    PS – great consultants always break the rules… don’t they?

    If not that, then looking for a rule to break. 😉

  • November 25, 2008 at 11:36 am

    Good stuff Ben.

    Rick: “But! I also understand the opinion of your project manager. Fact remains that managing a group of individuals who decide form themselves what jobs they do will make a project managers job a hell. No (good) project manager will accept and allow that to happen (at least I wouldn’t).”

    I am a good project manager (track record, conferences, more work than I can do, etc) and not only do I allow people to decide for themselves, I actively encourage it (which maybe Ben can testify to). I do this via trust, practices that create breathing space, and by holding account individuals when they get it wrong. As a project manager you should be aware of the tremendous motivation that autonomous behaviour brings. In fact, I would challenge your statement that no good project manager would allow that to happen and say actually, only a bad project manager would allow that not to happen. Software professionals are some of the smartest people you will ever meet – don’t treat them like children. Use their desire and creativity to create value but couple that with discipline.

    What one man considers a hell (the illusion of control) another man considers a heaven (chaorder). I think we all need to have a real think about what software project management really is. From a deep understanding of people and systems come opportunities to add real value. Ben has learnt this lesson very well. He’s a beacon that other engineers should be guided by.

    Very good Ben. J

    PS – great consultants always break the rules… don’t they?
    Deep understanding:

  • November 17, 2008 at 4:12 pm


    No, not yet. Since the colleague described did not agree, the investigation and estimation were not done for a while. And the business still has not received the results. 🙁

  • November 17, 2008 at 3:41 pm

    Hey Ben,

    I know your feeling and even had the same experience a couple of times. I agree with the part that we should work “with” the client instead of “against” the client.

    But! I also understand the opinion of your project manager. Fact remains that managing a group of individuals who decide form themselves what jobs they do will make a project managers job a hell. No (good) project manager will accept and allow that to happen (at least I wouldn’t).

    So I have a question about the situation you describe above. Did you also give a time estimate for your investigation? And did you also tell ”the Business” this “Investigation” would result in “x” weeks of delay for the deadline?

    All in all, nice blog article (finally one I can read (and understand 😉 ))

    Kind regards,


  • Pingback:Gridshore » Commodity and Ethics in IT, why a PoC is better than a RFP Process

  • November 15, 2008 at 8:02 pm

    I fully agree but there are always two to dance the tango. I mean that it has not to come from one side, a good project is based on trust and partnership. You should never step into a project if there is no partnership and trust, but to often higher management believes it will grow while the customer has no interest at all in a long term relationship.

    I know your situation and your customer and here i can say that its truly a partnership and the behaviour of your colleague is not even ethical, it is even dangerous for the relationship. A good manager would signal it and had a good talk with this person.

    Keep up the good posts
    I like them

Comments are closed.