The Ongoing Evolution of SharePoint Reporting

Nothing gets the crowds excited like spending 70 minutes listening to someone talk about SharePoint reporting. As I stood at the front of a full room this week for my second SharePointFest DC session, I joked that reporting “is the single-most exciting topic in SharePoint” which landed with a bit of a thud in a field of crickets. This is serious stuff – people should not be making jokes, apparently. Thankfully, people lightened up a bit, thanks in part to a laugh-track handled deftly by Messrs Dan Usher (@binarybrewery) and Scott Hoag (@scottmhoag) at the front of the room.

I’m exaggerating, of course. I actually got some great feedback on what is an extremely important topic to every SharePoint administrator, and had my session immortalized by Julie Morris from Bamboo Solutions, to boot, who took time away from her professional inline skating career to attend my session.

As with most topics I tackle, I took a very project management-centric position on the topic, sharing some of my own deployment and SharePoint management experiences inside and outside of Microsoft and going all the way back to my days as a technical PM in charge of all of the front-end business intelligence and reporting tools for the consumer team at Pacific Bell.

Reporting is at the core of every management strategy, and your governance strategy. Without measurements, you cannot improve. It’s as simple as that.

At the end of my presentation I made two somewhat controversial statements that a couple folks came up and discussed with me after my session:

• Do not build your reporting requirements based on what you know to be the limitations of the platform.
• SharePoint out-of-the-box will never meet all of your reporting requirements.

Now, neither of these statements is meant to be a slight on the reporting capability of SharePoint. Quite the contrary, I think Microsoft is moving in the right direction with a heavier emphasis on business intelligence extensibility rather than try to create too many standard reports. But as for the points I made:

My first statement can be applied to all governance planning activities – you have hard and fast rules by which you must comply. For example, SharePoint has certain known limitations, such as the number of list items or the size of site storage. Having reports in place to help you monitor and maintain these limitations will help keep SharePoint performing well. But your industry or even your corporate or IT governance standards may require much more detailed information, some of which may require you to aggregate content across sites, site collections, or even across multiple farms – and SharePoint simply does not provide this kind of aggregate view and trending data over time. My point here is that you should not build your reporting requirements around the limitations of the platform, but instead be aware of the limitations, and address the gaps through customization or 3rd party tools.

My second statement is simply based on my experience. While SharePoint out-of-the-box reporting will provide some key data, my experience has shown that most organizations already have a fairly clear concept of the data they need to accurately measure and maintain their enterprise platforms, and as SharePoint adoption increases, custom dashboards and reports are the next step. My advice is to plan for it up front.

The bulk of my presentation walked through 5 key reporting areas which every organization will need to address as they plan out their SharePoint management strategies:

• Permissions
• Troubleshooting why users cannot see the content they should
• Reporting for different types of compliance
• Auditing who has access to sensitive content
• Usage/Activity
• Finding what content is, or is not, being used
• Planning for future growth
• Understanding hardware requirements
• Storage
• Monitoring growth for performance reasons
• Understanding hardware requirements
• Reorganizing taxonomy based on Storage needs
• Auditing
• Needing to show who accessed what and when, to adhere to internal or external compliance requirements
• Performance
• Monitoring page load times to uncover problems
• Planning for increased usage

My slides are included below, and walk through each of these categories to help administrators understand some of the differences between versions. As shown when I asked the audience which version of SharePoint they had running in production, many within the crowd had multiple versions of SharePoint within their organizations – and so it was important for them to know the differences.

I should point out that most of the OOTB reporting exists at the Site Collection-level, and remains the same in Office365 (with slight branding differences). In a future post, I’m going to walk through some report and dashboard builds, extending some of what I’ve outlined here.