KISS: Keep Intranet Statistics Simple

I may be irritating KPI-addicts, mathematicians, or other people who like counting, measuring and comparing, but  what gets measured does not always get done!
Of course that requires some explanation.

When we moved from a custom-built intranet to SharePoint, we had to think about usage statistics. We were accustomed to measuring usage by company unit,  which allowed us to see which countries or functions used the intranet the most, and where we had to spend more time to increase adoption. It turned out that a link with our Yellow Pages was impossible in our SharePoint implementation, so we commissioned another party to develop this for us.

When our implementation partner returned with their proposal, their eyes sparkled with dollar signs. They proudly proclaimed that this would be their largest Business Intelligence deployment in Europe!

At that moment, all kinds of alarm bells should have started ringing.
Unfortunately, we thought that this was actually a cool idea.

What did we want?

We spent a lot of time specifying our requirements.

• As an intranet team we needed information about usage of portal, sites, pages, and documents, about referrers and referrals, by location, country, continent, company unit and discipline, and everything had to be exported into html, xml, csv, excel, pdf and a handful of other formats.
• Our content owners would also have nice statistics such as distribution of visits by country and discipline (very useful to see if you were reaching the intended audience), the most popular documents and “just” the number of unique visitors and clicks on their content during various time periods.

How did it work?

When it was finally working (many months later than the launch of the new intranet), we got lost in a slow loading slurry of numbers.  With every report we wanted to make, we had to spend an hour calculating, and/or had to read the manual to see how these numbers had been defined. As the company changed, and businesses were divested or merged, the mess kept growing because all the old data was still in the system and contaminated the results.

Because we stored a large amount of data, the system became slower and more sensitive to disturbances. We had to remove data on a regular basis because the server was full. Our service providers were not  familiar with these custom statistics so they could not solve the problem. At one point the daily update took about 20 hours. Try explaining that to your users, especially if the 4 hours uptime occur in their night!

So, what have we learned?

1. If you suddenly are someone’s largest project, in not exactly the right discipline (Business Intelligence? For intranet statistics?) please think again. Is this the right partner for you, or are your goals too ambitious for your purpose?
2. Focus on what you REALLY need. We also specified lots of “nice to have, just in case” functionality.
3. Make some scenarios for the future: can this be maintained and supported over time, what happens when major changes occur in your organization, or if you are storing many years of data.

And now, out-of-the-box functionality suddenly sounds very desirable :-).

Cartoon courtesy of Andrew Gilleran: http://www.gilleran.net/sharepointireland/