Build Your Own Fantasy SharePoint Team

Building a Team

Everyone is excited about their new Fantasy Football Teams and Leagues here in the United States. A lot of deliberation and planning go into selecting members of your team. Hours even days are spent pouring over players’ stats and skills before making the final choices.

What about our Fantasy SharePoint Teams? Imagine if you could build your dream team from the ground up.

  • What stats and skills would you pull onto the team?
  • Would you define roles and the skills needed to fulfill those roles OR would you define the skills and then define the roles based on the people with the various skills?
  • Would those skills be different if it was SharePoint Online, On Premises or Hybrid?
  • Would personality traits enter into the equation? If so what would they be?

Here’s a couple I think are needed regardless if you go old fashioned roles based or skills based.

  • Know and understand the tools available in the browser to prevent over development. Exam 77-419
  • Information Architecture / Library Science background
  • Search Engine Optimization
  • Keyword Query Language
  • Understand how SharePoint interacts with other Office Applications.
  • Create Search Results templates for SharePoint 2013
  • Know and understand SharePoint Designer Workflows, …
  • Can work in one or more of the following languages:
    • HTML5
    • CSS3
    • Net
    • XML
    • Understand and can make use of the client-side object model and REST APIs.

It’s only a start.

Add your skills list to the comments below.


Don’t Use the F Word When Describing Enterprise Social

NEVER use the word Facebook to describe enterprise social.

“People will be able to connect instantaneously, just like Facebook.”

“Our employees will be able to have conversations regardless of time of day or location, just like Facebook.”

That F word drives fear of a productivity black hole into the hearts of the CEO, CIO, CFO and most others on the leadership team in your organization. Some of them may have already been on Facebook. Your leadership team is already aware that Facebook can easily suck an hour or two out of your day. That isn’t productive, unless your company specializes in videos of people doing stupid things or produces cute pictures of cats doing stupid things.

If you want to sell enterprise social to the CEO, CIO, CFO or anyone else for that matter, show them how it will save time.

Do contracts take forever to review because you are doing it through email? How much turnaround time could be saved by having the discussion all in one place? Posting links to similar contracts within the conversation? Not only will it shorten the turnaround time for contracts, it will free up your sales team’s time to build more relationships with your clients.

Now we have another F word.

Fabulous!


Don’t Add Social Just Because It’s Shiny

Social is neat, Social is cool, Social is shiny, and it isn’t worth a darn unless it solves a business problem.

There are some organizations that install SharePoint Social features or Yammer because it’s the hip new thing. No training, no leadership buy-in, no business problem to solve. These implementations will be ignored by your co-workers, scorned by legal and lamented by HR.

If you want to prevent a “Social Debacle” within your organization put your ear to the ground. Listen for groups complaining about how hard it is to track things in email, find the most recent discussion on a document or project, and spending too much time in meetings discussing the same things over and over and over again.

Now you’ve found your business problem.

Talk to the group find out what they are doing and what they have tried to get the problem under control. Work with the group to create a place where these discussions can occur and be found later for review. Get the leader of the group or their boss involved early and make sure they participate in discussions and interactions.

If leadership isn’t using your Social Solution, no one will.

Make sure your Social Solution meets your users where they live; in email, on their mobile devices or in another location or piece of hardware. The business problem and how people will interact with your Social Solution is more important than the tool you choose.


Keep Track of SharePoint Permissions without a Third Party Tool

It’s not very high tech, but it works. Create a spreadsheet with tabs for your SharePoint Groups/Sites Matrix and each permission level used on the site. You may need to expand the SharePoint Groups/Sites Matrix to include lists and libraries that are uniquely secured.

Here is an example of one I’ve used.

PermissionsMatrix

View and download a copy of the spreadsheet here.


Peek a Boo Where is My View in SharePoint 2013

It should come as no surprise to anyone that how we switch views in SharePoint 2013 lists and libraries has changes.

To make it easier to spot the differences between 2010 and 2013 let’s do a side by side comparison.

2013

2010

Document Library
In 2013 the Add New Document option is at the top of the library. In 2010 the link is at the bottom.

What to click on to change views
The Library tab is available in both 2013 and 2010.
Notice in 2013 all views are listed. In 2010 you need the dropdown in the breadcrumb

Make the View Menu appear
In 2013 click the ellipse. In 2010 click the dropdown in the breadcrumb.

View Menu from Library tab
Icons in 2013 look cleaner, but basically remained the same.

With another web part on the page
In both 2013 and 2010 adding another web part to the page makes the Ribbon disappear.
Users must select the web part they want to work with before the contextual Ribbon re-appears.
In 2013 the views remain listed. In 2010 the dropdown in the breadcrumb disappears.

Please let me know if I should add something to this side by side comparison for Views.


Your SharePoint User Is Not Stupid

That’s right!

Your user isn’t stupid; SharePoint is stupid.

There I’ve said it.

Let the skies open up and lightning strike me dead.

  • SharePoint is a tool.
  • Tools don’t do anything. They are stupid.
  • People use tools to build things.
    • The tool appears brilliant, but really it’s the builder, or the business analyst, or that team that knows the process/issue.
  • Teach people to use what was built.
    • Remember how intimidating and exciting it was to drive a car or ride a bike for the first time?
    • Did you try to do it on your own the first time?
    • Did you have help?

If you don’t teach your user how to use what was built, you will need to point that stupid finger at yourself, not your user.

You were hired for your job, solving issues with SharePoint (if you are lucky). The sales team you are building a solution for was hired for sales jobs. They are not stupid because they don’t know SharePoint. You are not stupid because you don’t know sales. SharePoint isn’t stupid because tools can’t be stupid they are inanimate (unless you have enchanted tools).

Consider this the next time you want to call a user stupid because they don’t know SharePoint.