“I hate consultants.”
When I heard those words spill out of my lunch companion’s mouth as soon as we sat down, I knew it would be a long lunch meeting.
Some background
When I was an independent consultant I spent a lot of time in business development mode. Lots of time going to networking events and meeting new people. I enjoyed that (and should be doing it now even too)…but some of the people you meet while out and about can be very surprising.
Take “John” (name changed) as an example.
I met John through a friend as a request by me for an introduction. Upon an introduction during a luncheon, John was pleasant, cordial and professional. We seemed to have a lot in common and we knew a lot of the same people in town. After the luncheon, John and I exchanged emails and agreed to meet for lunch the following week.
John was the CIO of a medium sized manufacturing business in Dallas. The company had been struggling for years to break even each year with some years seeing a profit while other years found the company loosing money. During our initial introduction and subsequent emails, I made it clear to John that I was a consultant focused on technology strategy and IT and had helped many organizations like his use technology to meet their strategic goals. So…he knew I was a consultant but I was also very clear that I wasn’t having lunch with him to try and sell him my services.
I met John at a local restaurant for lunch. We met at the front door, shook hands and traded banter and waited for our table. While waiting, John told me more about his company, the troubles they’ve had for years and how difficult it was to keep the company afloat.
We were shown to our table and ordered and picked the conversation back up. I asked John if he’d brought in any consultants to help him understand what changes might be needed to help the business become more profitable.
His answer?
“I hate consultants”.
He continued to describe consultants as a plague (his word!) and cheaters/liars and thief’s. Strong words.
I asked John why he felt this way and was informed that he had been burnt by consultants in the past and after hearing the backstory, I can understand why he had strong feelings against consultants.
The Spark
The story I heard from John was a familiar one.
A consultant was hired to come in and help with technology selection, implementation and development of custom functionality. The consultants role was to provide guidance during the selection process and manage the development and implementation after selection.
John tells me that the entire engagement was a debacle. He hired a consultant that had a great deal of experience implementing this particular type of software but little experience with technology selection. First mistake.
The consultant comes in and helps work up a technology requirements document and helps the company select and purchase the software platform. John tells me it just happened to be the software platform that this consultant was most experienced with. John also tells me that the platform they chose didn’t really fit that well but, because the consultant told them it could be easily customized, it would eventually fit the organizations needs. Second mistake.
After selection, the implementation phase began with the consultant acting as the implementation manager with a focus on implementation as well as software development for customization. The development was done by the software vendor and managed solely by the consultant. Third mistake.
John tells me that the software project took twice as long as originally expected/planned and cost three times more than originally budgeted. And it didn’t do what he needed it to do. About half-way through the project, John fired the consultant and the developers and brought all development and implementation in-house.
This project was the spark and kindling for John’s hatred of consultants.
Revisiting the Project
After John finished his story, I nodded and told him I’d heard it many times before. I politely asked if I could revisit the issues and point out some errors that might have contributed to the project failure.
Thankfully, he gladly accepted the offer and listened intently (or at least pretended to!) while I pointed out the three main errors I saw in this technology selection and implementation project.
First, I pointed out the issue of hiring a consultant with zero technology selection experience and tons of implementation experience on one platform. This is bound to lead to a bias towards a particular platform, especially if the consultant(s) don’t have a wide range of experience on platforms and a strong background in technology selection projects.
Secondly, I pointed him to the selection of a platform that didn’t really fit the organization’s needs but ‘could be customized to fit’. Everyone knows this is BS and that the approach fails 90% of the time. If you’re selecting a platform, select the one that fits the best…you may need to customize the software (or change your process) but do your due diligence to pick the platform that is the best fit for you.
Lastly, I pointed out the biggest mistake of letting the consultant choose the out-sourced development partner and manage the development without any involvement by John or his IT staff. This is a huge mistake as it takes the IT organization out of the driver’s seat completely. Where’s the oversight? Where’s the project governance? Oversight isn’t something you do for 30 minutes every Tuesday morning during the status meeting. Have a project manager managing the consultant and/or developers.
When I finished my quick review, John said something that surprised me.
He wanted to bring me on (as a consultant) to help him reorganize and rebuild his IT group. I accepted of course…but I told him I’d be just as honest and forthcoming while working with him as I’d been during lunch.
A bit of an ego stroke (for me)
Over the next six months, I helped John fix his biggest issues and helped him plan for rebuilding his IT group. These plans included building proper project management skills and procedures as well as increasing his team’s ability to efficiently manage IT Operations.
My proudest accomplishment while engaged with John’s organization is actually the easiest work I did with him. I introduced John to a young lady who would eventually replace him (after his retirement) as the next CIO of that company.
I’m happy to report that the company is doing well (reportedly because they are leveraging operations and technology for competitive advantage) and are happily using consultants and contractors to fills knowledge & skill gaps. I like to think this success is in part due to my involvement…at least I’ll keep thinking so 🙂
The Moral of this story?
Think about the mistakes highlighted above….have you made any of them on projects? Are you making them today?
Don’t blame the consultants for project failure. Look at your involvement and try to understand what you could have done better to set those consultants up for success.
CIO’s in the past have loved using consultants and contractors because they could have someone to blame if the project went badly. The New CIO can’t shirk that responsibility any longer….if an IT project fails, it’s on your shoulders.
At the end of the day you have to ask yourself this question – Who hired the consultants? They didn’t come in and work for free…they had some direction from the CIO and IT group….so both parties are equally responsible for project success or failure.
Next time you start to think (or say) something negatively about a consultant or a contractor because they couldn’t get the job done…think again. Perhaps it’s as much (or more) your fault that they weren’t able to succeed.
Don’t hate the consultant….figure out what mistakes were made and move on.
20 responses to “I hate consultants”
[…] more: I hate consultants | Technology, Strategy, People and Projects … Posted in Consulting | Tags: and-meeting, and-should, business-development, but-some, […]
[…] more from the original source: I hate consultants | Technology, Strategy, People and Projects … Share and […]
RT @businesschange: #baot Reading: I hate consultants http://ow.ly/16rxsq
great article, eric. good advice for consultants and CIOs alike.
RT @ericdbrown: Was just told my post titled was offensive RE: "I Hate Consultants". FYI – It's meant to be – http://bit.ly/91oQP0
RT @ericdbrown: Was just told my post titled was offensive RE: "I Hate Consultants". FYI – It's meant to be – http://bit.ly/91oQP0
I hate consultants: http://is.gd/7ejHX (me too 🙂 but this is a good story of how NOT to use consultants)
RT @businesschange: #baot Reading: I hate consultants http://ow.ly/16rxsq
[…] here: I hate consultants | Technology, Strategy, People and Projects … Posted in Consulting | Tags: and-meeting, and-should, business-development, doing-it-now, […]
Awesome blog: I hate consultants | Technology, Strategy, People and Projects – Consulting http://ow.ly/11utn
I hate consultants http://ff.im/-f0OOl
I read with interest your article which must compliment you on, fantastic read. Sounds so familiar. As a software consultant myself, thank you for this posting and just hope companies planning to implement a new application, do take the time and thoroughly research within their own industry, know what they want and how much they are prepared to spend before hiring someone who “comes highly recommended”. Cheapest quote is not necessary the best and to ensure their costings stay within the budget/contract.
My background is 20 plus years as product support on applications purchased in box and “off the shelf accounting software”- over the years built up a niche in the market place whereby not only sell upgrades but also specialize in third party applications as “add ons” which work seamlessly between accounting product and the new application viz: point of sale, data management and crm packages.
Countless times have been called in as mediator or as a support person “after the fact” overseeing “third party applications” – and my findings are that the consulting company is so flattered to be wooed to a new project, they tend to not do their specs correctly, to be fair this is not always the case. This is when the fun begins, consultant’s staff are not qualified, misinterpretation of requirements gets passed along the line to developer, implementation begins, beta testing crashes, fingers are pointed, support team not available or work outside the hours of the client and in the middle sits the client with little or no software experience, screaming out in frustration unable to run their business. This is why consultants need to ensure they know their game, explain to the client of the pros and cons of changing platforms, installing add ons and when additional requests for more features these “pretty features” come at a cost.
Thanks Tracey – good to see you.
Excellent points Gillian – thanks for sharing!
[…] This post was mentioned on Twitter by Paula Thornton, Owen Greaves, Eric D. Brown, Eric D. Brown, MBO Partners and others. MBO Partners said: Awesome blog: I hate consultants | Technology, Strategy, People and Projects – Consulting http://ow.ly/11utn […]
I hate consultants! Nice analysis from Eric Brown: http://tinyurl.com/yj4hdvs
RT @mbopartners: Awesome blog: I hate consultants | Technology, Strategy, People and Projects – Consulting http://ow.ly/11utn
[…] I hate consultants by Eric D. Brown […]
When people fail, they often blame someone else and make him/her scapegoat for their failure. Here John blamed consultant but actually he should have found himself weak and ineffective. I mean, John was the “effect” instead of being the “cause” of the situation.
The Consultant might walked off dejected but indeed John made that Consultant more powerful than himself. He said, “My Consultant messed up and is a thief, “which is just another way of saying, “My consultant determines if I succeed or fail.”
Had John taken responsibility, he would have said, “I need to train my Consultant so he doesn't make mistakes”.
If he wished to succeed in his business venture, he had to end the blame game and accept responsibility. He only get ahead when become “cause” over the situation and not the “effect”.
[…] in the past, and we can get attached to things that make no sense. We can all shy away from looking back our mistakes or having the tough conversations to avoid leaving our comfort […]