On Consultants

by john on January 22, 2003

I’m currently going through the process of unwinding a team of consultants who I have had working on a project since the beginning of last year. This project, an enterprise wide application implementation, has been the first project where I have employed a consultant for longer than three months. It will also be the last.

The reasoning behind augmenting my team with consultants seemed sound at the onset. New application, huge global issues, and a ship to keep afloat with my current people. We instituted a model where the consultants would implement to a group, hand-off to my team, then roll on to the next. The team we brought in are fine people, and we have made decent progress, although not as much as we had forecast – but that’s really been more of an application issue.

The budget we had for implementation last year was extremely tight. So much so that in hindsight I should have raised more red flags than I did. Hell, I should have raised the white flag. But we marched on. As we built our plan for 2003 it was apparent we just couldn’t keep that burn rate going – we had to cut it off despite having a ton of work to do.

As usual Scott Adams has been spot on recently:

Here is what I would do differently with the benefit of hindsight:

Before hiring a consultant consider carefully the endgame. If your project is one where the skills your team will acquire during the project can be spun off in other areas, especially on the revenue generating side, then build a model for hiring more people instead of consultants. As an example let’s say you work for a software company who builds products that could be used by companies who have implemented a certain CRM product. Let’s say it is that CRM product you are looking to implement internally. Hire more people and build an implementation plan that focuses on the CRM application and the integration of your own products. By the end of the project not only will you have the implementation done but you will now have a team of people who are likely the leading authorities on integrating and implementing the two applications. You have built an extremely valuable team.

The resource will vary depending on the number of consultants you hire, but be sure to have someone on staff who is responsible for the consultant’s work and who has been budgeted with the time it will take to do it. it is all too easy to fall into the trap of simply reading the project updates each week. Don’t do it! Put someone in charge directly in their midst.

Chunk your projects out both in terms of time and in the number of consultants. Ensure no project goes longer than a quarter with no more than three consultants on each project. This means you will need to break the problem down into sub-projects but that’s a good thing.

Look for a consultant company who will not only provide you with project updates but comes with a system (if you don’t already have a solid one) that improves communication of their projct across the organization. I mentioned one possible way I’d like to see this done in Weblogs @ Work.

Finally, take a look at the consultant hiring practices of the Minnesota Department of Transportation and do the opposite of what they do. That story just broke this weekend here in Minnesota and there is going to be hell to pay.


Henry January 25, 2003 at 1:19 pm

From my own CRM implementation experience (as well as lesser projects) I don’t believe consultants are incentivized properly. Usually their number one goal is to sell more work to you after the project is over. Unless they have another project waiting for them elsewhere, in which case it’s to rush your job (getting paid the full amount, of course) so that they aren’t late to your next job.

When dealing with consultants I usually tie them to a contract with 1) measurable deliverables with mutually agreed upon deadlines, 2) liquidating damages if they pass the deadlines and 3) a bonus if they deliver what I want on schedule. The bonus is effectively what I agreed to pay them for the expected man-hours of the project. If a consulting firm won’t agree to those stipulations — and most big firms won’t — I refuse to use them.

john January 26, 2003 at 6:56 am

I agree Henry and the reason why I sugget limiting the length and scope of projects – the longer the project the more impact changes in the business will have and the more unlikely it will be that a project can be completed as initially scoped – hence the reluctance for them to sign u As an example we’ve had two reorganizations in the last year that have effected our schedule greatly. Key people leave, objectives changes. Over the course of anything longer than a quarter all of this will happen and if I was a consultant I’d be hesitant to sign up for it too.

I talked with an ex-consultant who works for us and she told me that when she was a consultant spoecially in training her main objective was figuring out how to turn that $1M contract into a $4M one. Certainly not the incentive that benefits the client.

Previous post:

Next post: