Ah, we need consultants. We have to have them. Our projects require them. There is just too much work for our internal staff. So we work with them. A necessary evil or a wonderful experience - it can be one or the other. PURE .... !!! Or Pure heaven. Or neither just a good experience.
I'm a developer so this list will lean towards the development side of things. However, I believe a lot of this can be applied in any area.
I have worked both as a client and a consultant. It can be frustrating both ways. However, I've worked the longest as a client. And this is my client side rant!
Great consultant
My favorite, and it's a pleasure to work with these guys (Of course this list is + good consultant list) :
- Ask why. There may be a great reason why something is done. There may be a crummy one. Because that's the way we've always done it is a bad answer on my part. So show me a new way! I'd love to share. Think outside of what is normally done.
- Follow industry standards. MVC is a very good thing to know and understand.
- Share information. It's a give and take. You DO know more than I do in different areas. I probably know more than you in different areas. The best time I have with consultants is when we can share our knowledge.
- Teach me something new! That's the best thing ever!!!!
- Spend time to educate me on what they've worked on for my company.
A good consultant list:
- Great communication skills. Listen first, and then make suggestions.
- Admit when they don't know something, and ask for help.
- Follow customer standards.
- Once there is a code review, correct all your code - even other programs prior to submitting for a new code review.
- MAKE suggestions. Present your case. But then if the customer - me - decides on a different approach take it. Don't spend days on debate. The project needs to move forward.
And to the rant!
A BAD consultant:
Thinks that they always know more than the client. Yes, they might. But they need to present alternatives instead of never changing.
Do the exact opposite of all the things listed for a good and great consultant.
- Debate EVERYTHING! Don't let the small things go.
- Don't listen to customers ideas. Don't take the time to understand their customer's process.
- Write code that is hard to maintain.
- Don't think about the BIG picture. Re-useable code to them means that it is usable only for their project. And won't be used again.
- Don't write re-usable code.
- Cut and paste instead of writing subroutines, function modules, and/or classes.
- Rush the code to try to finish by dates. The rush code means rework for me.
- Use coding techniques that are non-industry compliant and then say it is simply a difference in coding styles. There is really no reason for them to change. AHHHHHH!!!!!
- Doesn't share the information.
- Refuses to listen.
- Just takes a template and tries to apply it to every client.
- Doesn't take into account the client's needs. Some know very little about SAP. Some know a lot.
- Use the reason that they don't know a way of coding as a good reason not to do it. Don't know it? That's OK learn it.
- Ask how prior to doing any research. There is google. There is help documents. There is SCN!
I'll take the less experience consultant every time as long as they take the time to listen. Respect goes both ways. Guess which consultants are asked back to work with me!
Oh and why write this blog? It's in response to a couple I've been reading and debating. So if you have the time, stop and read these as well. They are interesting and present some oppisite viewpoints.
Choosing the 'best' among good designs - an illustration
Thanks to Marilynn Pratt, I'm adding some more links. I completely forgot about the BPX element. However there are "bad" BPX folks just as much as "bad" technical consultants:
BPX Skills Webcast with Jon Reed for ASUG and BPX
BPX Skills Webcast with Jon Reed for ASUG and BPX Voice only - This will help anyone / everyone who ever thought about being a BPX person. One of the interesting points is "Ability to work as the “liaison” or “missing link” with functional and/or technical teams from the opposite side of the aisle.". That person is usually missing from a consulting team. That would be wonderful to have. (And of course this point helps out my rant.)
BPX Certification - This is a WIKI on how to get the above skills. Fun place to add your thoughts and build out a great resource for BPX.
BPX Community - And so - you think all of this sounds good. Take a look at the BPX community. Our missing link on most the projects I'm on. <We have some really good internal ones - not as many consultants. >
And check out Marilynn's BPX- Skills Focus with Jon Reed - with all the above links. Without my personal comments - of course 🙂
I couldn't help it. I had to add the BPX things to the end of my blog. It just fit so well with what I was trying to say! Enjoy.
