2013-10-21

Before you begin any evaluation, do yourself a favor and stay away from the inside of your head.  Write down or type out your criteria and track it from there.  Doing this is one of the easiest ways to help prevent biased decisions or forgotten factors.

When evaluating 3rd party tools for SharePoint there are six quick steps that you can use to get you from idea to deployment and ultimately, user adoption.

1. UNDERSTAND “WHY” YOU REALLY NEED SOMETHING IN THE FIRST PLACE

  • What are you trying to accomplish?
  • What is that tool going to do for you?
  • Do you have a plan in place for how you and your users will use the tool?
  • How will you maintain the tool and will there be updates, patches, or upgrades needed?

2. KNOW HOW TO IDENTIFY THE BEST TOOLS

3. RESEARCH, RESEARCH, RESEARCH (DO YOUR HOMEWORK)

  • Read reviews, ask questions, from others in the industry
  • Connect with consultants and get feedback if possible
  • Ask others in your organization for their opinion, you know  “water cooler talk”
  • Look for the good and the bad reviews (e.g. SharePoint 2010 Review)
  • There is always helpful information to give you clues on things you may not have known to look for or consider.  Don’t spend too much time trying to find reviews, rather do an evaluation period that provides enough information that you can then make an educated decision on.  After all, the goal of the research is to provide you with detailed information worthy of aiding you in making a decision.  If you find that not enough information is out there, use your best judgment, then make a decision.

4. EVALUATE YOUR RESULTS

  • Give yourself a rating or scale to work with
  • Find at least two tools that do the same or similar thing if possible.
  • Rate and ask the hard questions. Use a scale when rating tools and whether or not you need them.  The scale should include some simple things about your position. Is it better to develop in house? Do you want to spend a lot of money on this? How much ROI are you looking for? Ask yourself these and any other questions you may come up with.  This scale does not need to be too in-depth, but may help provide an overview of the key decisions you need to make when evaluating the tools.
  • Ask someone else to review your scale when you finish as well.  Look for the output, what problems does this solution really solve and how easy is it to implement?

Tip of the day: Don’t buy a tool you don’t know and haven’t tested. Always test it out in a farm outside of your environment. If you don’t have one, find a friend or colleague that does and have them test it for you.
NEVER put something into production untested.

5. PLAN YOUR IMPLEMENTATION APPROACH

  • Understanding how to implement the tool is almost as important as finding the tool itself.  What good is it to find something that says it does XYZ, but you struggle to even get it deployed into your environment – or you don’t deploy it correctly?  With the latest advances in SharePoint 2010 and 2013 this is being simplified in some regards, but there are still cases where deploying the solution is just half the battle.
  • Ensure you have a communications plan in place
    • i.  Help users understand the tool, what it does and how they can access it.
    • ii. Provide some FAQ’s or documentation if possible on the tool.  Doing this could eliminate lot of extra help desk tickets from being created later on.
    • iii. Understand what inputs can really promote of deliver the correct outputs from the tool.
    • iv.  Don’t stick features and solutions out there because they sound good or came with a bundle of stuff, find out if you really need it, and if you do, figure out the best implementation approach to effectively and productively use it.

6. MAKE THE DECISION

  • The biggest issue with all of the above is that you can do it and still end up not making a decision.  So if you do all of the above, make a good decision and work from there.  Again, nothing is perfect, but if you’ve done the above and still feel that you have a good case for needing the solution, then go for it.

About the author 

Eric Harris