“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.