How to Evaluate a SharePoint Consultant...

This is a BIG topic because SharePoint is not an application, it is a universe.  Really.  There are, and should be, consultants for many different aspects of SharePoint deployment use and development, including:

1. Training consultants

2. Business strategy, policy, governance and integration consultants

3. Project management consultants

4. Legal consultants

5. Line Of Business integration consultants

6. Business Data Catalog consultants

7. Business analysis consultants

8. Document management consultants

9. Operations and infrastructure consultants

10. Deployment consultants

11. Storage management consultants

12. System administration consultants

13. Master page consultants

14. Branding consultants

15. Migration consultants

16. Search indexing consultants

17. metadata management consultants

18. Consultants to manage teams of consultants

Usually when someone is writing about the way to choose and evaluate SharePoint consultants, they are thinking about a pretty narrow section of the possible skillset that goes into a SharePoint environment.  Most likely they are thinking about SharePoint administration or development.  This is because the people writing are most likely developers or administrators, which is fair.  But there is much more to the story.

The very best branding consultant may have very little expertise with SharePoint at all, at least not beyond the creation and management of Master Pages.

The best business analyst or project manager may only have a rudimentary understanding of SharePoint beyond a Power End User's level of technical expertise, and a healthy understanding of the various professionals that might go into a major deployment.

So, after 30 years of being a consultant, and being a corporate leader who hires consultants, here are my brief rules of thumb:

1. Check the person's references.  Very often the consultant will say "I ran a really big SharePoint initiative" when in reality they were one of the developers or administrators.  Give credit where credit is due, but understand that they are not going to be in a position to understand the larger business issues involved in making SharePoint happen.  Most SharePoint deployments are technical successes and business failures, when they fail.  A developer, administrator or architect is not likely to be able to help you mitigate business risks beyond ROI calculations and making sure requirements are met.  These are very important, don't get me wrong, but they are not the whole story.  So check the person's references if at all possible.  Make sure that the reference describes the consultant in the same role as the consultant described.  Make sure things went well.

2. If at all possible, ask to review the consultant's portfolio.  If the person is a branding or page consultant, then they should be able to show you a portfolio of their successes.

3. Check the consultant's successes with similar, and different technologies.  You do not want a consultant who is a SharePoint "one trick pony."  SharePoint is a great tool, but it is not the only show in town.  If the consultant can't discuss other viable solutions to whatever problem you face, then they are going to have blind spots.

4. Evaluate whether or not the consultant can work with real people in an everyday setting.  People are almost always hired for their technical and professional skills, but they are almost always fired for their lack of social and people skills.  If you hire a consultant who is long on technology and short on people then you are going to regret the decision.  One of the primary purposes of a consultant is to train up the people on your team by transferring knowledge to them. If the consultant hoards information and works in a vacuum, then you are going to be miserable.

5. Ask the consultant to explain how they will approach your problem. If they spew out a stream of technobabble, then they are not going to be good communicators when they assist you.  Consulting is all about communicating.

6. If the consultant has certifications, make sure they matter.  I am a PMP certified project manager, and I can tell you that it is quite possible to have this certification and be a lousy and untested project manager.  My practical experience is far more important.  Successful management of a 500 million dollar outsourcing project is far more predictive of success on your project.

7. Make sure the consultant is a truth teller.  If the consultant tries to tell you what he/she thinks you want to hear, then your situation will be worse for having them join your team.  Make sure you can trust the consultant to tell you when the emperor has no clothes.  They need to tell you politely, but they do need to tell you. 

8. Make sure the consultant has a ready made, built-in exit strategy.  Consultant should never be around for very long.  The consultants plan of attack must take that into account.

9. Ask the consultant to describe their engagement cycle.  If they can't effectively describe their method for entering the consulting engagement, establishing rapport, assessing the situation, proposing and validating a solution set, delivering a solution, and exiting, then they are going to be pretty random when they are on the job.

10. DO NOT hire a consultant who has not actually done the work before, and done it successfully.

11. Make sure your consultant has realistic boundaries and a realistic understanding of their own limitations.  If you have a consultant who thinks he/she can 'do it all,' then they are not a good pick for your project.  SharePoint is too big for any one person to do it all.  If they think they can, or even think they can do a big chunk of everything you need to have done, they may be big on ego.   The last thing you want is to hire someone who will hunker down, bight off too much, and grind to a halt as they try to overcontrol the technical aspects of the project.

12. Ask the consultant to describe their biggest failure and what they did about it when it happened.  If you have a consultant who can't describe a significant failure, then you have an inexperienced consultant.  consultants take on the big risks.  Failure is part of the deal.  The big question is how they handled themselves.  did they run and hide, or did they run toward the problem.  did they get the project or effort back on track or did they bail out?  If the consultant can't describe a major failure then they are inexperienced or defensive-- neither is good for you.  If they blame the failure on others, then they are not going to take ownership for their work when you hire them.  they should be able to clearly and cleanly discuss their own failure with emotional distance and a sense of closure.  You don't want a consultant who can't objectively evaluate their own work and own up to problems.  If they can't own their problems then, when they are working for you, they will hide their problems until the last possible minute.  When the problem is finally revealed, they may shut down emotionally or run.

Comments

[Steve]

While I generally agree with your points you have to admit that an average-sized organization would have to hire a rather large staff 18 of them doing consulting, another 25 for coding, 10 more to maintain the infrastructure and 5 others to perform the actual user training. If that would be the case SharePoint has completely failed to address the mere meaning of its existence. Has it?

I am working for a 2.500+ poeple organization that has a rather large MOSS deployment and we are doing fine with a staff of 12 SharePoint experts.

[mark@vitalskill.com]

I agree with your comments entirely. In fact, your question inspired an additional blog posting! I would like to add you to my growing network of professional contacts. Are you in Linked In?

[Steve]

Hi Mark,

you can view my preliminary Linked In profile at http://www.linkedin.com/in/stevegraegert (just signed up) and my full profile at Xing .

Greetings

[Steve]

Hi Mark,

you can view my preliminary Linked In profile at http://www.linkedin.com/in/stevegraegert (just signed up) and my full profile at Xing .

Greetings