All Consultants are Evil doers meant to KILL your system
Do I have your attention? YES! The title worked.
So here I go… I have done both been the evil consultant and the customer. I am the customer right now.
Quickly – for me – why am I writing this blog? I’ve left one too many comments and would love to generate a discussion here.
Let’s start with the Evil Consultant (EV fort short. In-house IH for short)
IH: Hi Mr consultant, I’m so happy to work with you. (Meaning why on Earth would they bring in a consultant?)
EV: Sure. I’m happy to work with you too. (Meaning – you idiot, I’ll tell you what to do.)
IH: So have to had time to look over the new project. Do you have any questions for me? (Meaning, of course you do, you don’t know our system or our way of doing things.)
EV: <Getting a little mad> Of course I have. The problem is that I’ll have to rewrite all the old code. It is inefficient and doesn’t use objects. So I had to double my hours. (Meaning your programs are horrible)
IHr: Yes, that was one of the early programs, but can’t you just use the basics. We don’t have anyone on staff who knows objects. <Kind of worried now. What is this idiot thinking we can’t support that.>
EV: Well you’ll have to learn then. He goes on to program a complete system. It runs great in development, so he is on his way to his next client.
In-house developer: <Project has gone to production> Oh no! It’s crashing! We don’t know objects, we have no idea what he did, and this is critical to our business. No holiday for me and some very late nights fixing this while learning basic objects.
Sound familiar? Maybe with a different twist? The consultant stays there when it goes to production, but when he leaves it breaks? All the sudden your production system is running too slow? Oh boy, so not good. I bet we all have some stories to tell.
The good consultant (GC) / the Evil in-house developer: (EH)
EH: Hi Mr. Consultant. I’m so happy to work with you. (Meaning I hate you, and wish you were gone. You idiot.)
GC: Hi, I’m happy to work with you as well. (meaning this could be a fun job)
EH: Well here are all of our standards make sure you follow them exactly. I will be watching you. I also code review all your work, and nothing will slide by me.
GC: Well I’ve noticed that you are using for all entries and are not using joins. I think I can prove to you where some joins are more effective. I could also help you learn something about objects while I’m here. I’ll make some time for it.
EH: What did I tell you?!!! (Idiot) Just follow our standards and we will get along.
Sound familiar? I bet it does.
So what would I suggest?
In my infinite wisdom, you know since I know everything. (wha ha ha – that’s my evil laugh) Objects are actually an older technology. New programming techniques are coming quick with HANA. I’m an In-house developer. So if/when we bring in outside consultants, I want to pick their brains. Will I let them do everything they want? WILL I? Not my call. It’s my bosses call, but I’m guessing we will have to compromise a bit. Also if they are leaving me any code, I want to sit with them and completely understand it. That can’t happen without some give and take. We don’t have to be friends, but it would be nice if we respect each other a bit.
OK – now there are some truly bad consultants out there. There work is below even the lowest standards. My advise, if you aren’t the boss get with him immediately. If you are the boss, send them packing.
Some horrible customers (In-house developers) – well it is up to you Mr. Consultant if you want to put up with it or not. You can always look for a different gig. Or you can try to make those horrible customers be better. (Not always possible)
Here’s something to think about. You’re consultant is amazing; however, she is horrible with people skills. Would you keep her around?
Last but not least – some assumptions:
- In-house developers do not keep up with the latest ways of coding. Not always true, but remember we have to get things out quickly and sometimes it is easier to use something we know than what we are learning.
- Consultants are inflexible. Well they wouldn’t get very many jobs if that was true. They are just like the in-house programmers.
- In-house developers are inflexible – demand consultants follow standards. Not true, they may say that but give them (us) a reason to do something different that is better, and we will. We will demand to understand it.
- Consultants are horrible. There code is inefficient. Some are – get rid of them. Some aren’t. Some are exceptional. Remember they probably have a higher ratio of people staying up to date with the newest technology. Of course they have the higher ratio of new developers as well. Be careful.
And so – now have fun with this one! What is the worst and the best that has happened to you? I may start the comments too! Of course leave names out. And never post something that you wouldn’t mind your employer reading.
OH – BTW I’m great at ranting. But here is my point. If you are a consultant don’t assume your customer doesn’t know anything. If you are a customer be able to be flexible. And really this was just a rant. And I’m leaving it open for others to rant as well.
I was a consultant sent in to help with the installation of SAP. There was a In-house developer who had been to some classes and was sure he knew way more than I did. I was trying to teach as well as work on the installation.
He was doing the code review of all my programs. He wanted to do logical data base reads such as get marc. He didn't like BAPIs and thought BDC's were easier to code. He didn't want to learn LSMW. And he had no desire to learn from me. After all - he knew it all.
I quickly had my team lead move me to a different project. I have no idea how that one turned out. I bet it was interesting.
Hi Michelle,
Nice rant - but i don't seem to see your points.
I too have been on both sides, although most of the time, i've been IH.
I don't follow your assumptions on IH not picking up new technologies. At least not as opposed to consultants (evil or good). In my experience, ongoing improvement and continous learning are more a question of personal interest, individual capability and employer given opportunities.
I have known consultants, who had a collection of code-goodies for a number of problems, created, gathered or assumed otherwise but had no intention of getting better. And of course, i've known some, who were absolutely top level.
I don't think that Consultant and IH are natural opponents.
Good IH as well as good consultants try to benefit from each other. On the other hand,
a poor IH will always defend his/her territory and therefore will tend to be less aproachable with new ideas. The same holds true for poor consultants. They will always cling to their hard gained knowledge and fend off everything new or different.
Best regards - Jörg
Totally agree. 😆 I must have been rambling a bit. The good in-house and the good consultant work the best together. Otherwise you have to try to work around each other. My rant is on both sides. Actually I got more training on the In-house side. So my point is work together darn it! No assumptions on either side please.
OK - so my next vent:
I was a customer. I like to feel like I know some of my stuff. Not all - I can never stop learning. It was decided that to help create the technical design a contractor would be brought in.
He was very condescending. He didn't listen to the business issues I brought up or my ideas. He just kind of said his way was better.
However, I was on the project with him so I had to try to not make waves.
His solution was to create a lot of background processes that would update the Z tables needed for on-line processing immediately. The background process would run every 5 minutes looking for changes and updating the tables.
It worked. On development and even on quality. It got to production and worked some of the time. By that time there wasn't a budget to keep him on and quite frankly, I was glad.
So I could show timing was an issue. I want back to the original design and pulled it apart. I was able to do the updates to as needed via user exits, BADIs, and enhancement points. It was not easy, but it came up with a solution that updated things immediately. (And it addressed my original concerns with my consultant. AHHHHHHHHHHHH!!!! A lot of rework. And of course no one remembered I brought up the concerns earlier in the process.
Was his logic right? I don't know what it did didn't work for us. So I would say no.
The absolute worst vent. The consultant that doesn't know anything about ABAP. They are juniors that are presented as senior developers. They miss something as bad as select single *, in the middle of a loop, when only one field is needed from a big table.
They don't know what I'm asking for when I say something as simple as RFC.
Those are the days I could sit down and cry. I am working mega hours, and usually I simply toss the code and start from the beginning. And of course if I say anything - I just don't know what I'm talking about.
OK - enough venting today.
Have I said I love my new company? That doesn't occur here.
I do love a good rant and could've written an equally long one too. But I have some work to do (because it can't be trusted to the consultants 🙂 ), so will be short.
Personally I've seen unprofessional behavior on both sides. But what many consultants fail to understand is that IH people are the ones who know the business well (usually) and they will also be the ones to get stuck for a long time with whatever solutions are implemented. For them the system is their baby, but for the consultants it's merely a foster child.
Also consultants are there to do exactly that - consult. So present the client with different options, explain pros and cons, explain what do you recommend and why and step away. And whatever the client decides - as a good waiter, just murmur "excellent choice" and carry on. Bad things happen (for both sides) when for some reason consultants become too attached to one solution and start pushing it too much or take it personally when their solution is rejected.
For IH folks - you are extremely lucky if you get a consultant from whom you can learn something. Not taking this opportunity (even if said consultant is not the nicest person) would be foolish. (BDC easier to program than BAPI - one must be smoking something.)
But the most important note - since "fish gets rotten from the head", most of those issues really are the managements fault.
P.S. Quite surprised no one pointed out yet that it should be "Mr./Ms.". 🙂