Working in a SharePoint box

Recently I have been helping to launch a new Office365-based intranet.
While we set out with the idea of “out of the box” (a sound strategy, knowing my earlier experiences with extensive customizations) we have had to create some custom things to meet the requirements of several stakeholders.

I was therefore very interested in Clearbox Consulting ‘s evaluation of 26 “SharePoint intranets in a box“.
Unfortunately this report was published when we had already progressed very far in our intranet journey, so there was no reason to buy it.
Still, it kept nagging me because I was really curious if we could have used one of the “out-of-the-box” solutions.

So you can imagine my surprise and elation when Sam Marshall provided me with a copy just before Christmas, as well as a discount code for the readers of this blog.

What is this report about?

It compares 26 products of companies claiming to have a ready-made SharePoint intranet. This means that you do not have to do any developments yourself. It is just some configuration and a little branding.

The researchers have made the evaluation by comparing a set of standard scenarios that most intranets will need:

Content of the report. (Screenshot from the website)

Strengths

The major strengths are:

• Many offerings compared – I never knew there were currently 26 different products!
• The evaluators are all experienced intranet peeps who know what they are doing.
• The evaluation is based on recognizable business scenarios.
• Consistent and objective evaluation. (We could never have done it, since we would undoubtedly be biased by our own requirements)

To think about

1. The cases provided are all very common in the intranet world. However, you may have some unique requirements that are not mentioned here. In that case, you may need to create your own filtering to find out who would be the best in-a-box-partner for you.
2. As mentioned earlier, SharePoint and Office365 are changing very rapidly, and I do not know a. how well all vendors can keep up, and b. if and how quickly SharePoint developments will catch up with the vendor’s unique features. (I heard “Corporate News”  is on the Microsoft roadmap for 2017)
3.  I expect new vendors to appear as well as consolidations.

So, I therefore hope and expect that there will be regular updates to this report…

Who should read this report?

• Anyone who is starting on a new intranet should definitely read this.
  This may help you to decide if SharePoint would be a good option for your organization. You may think SharePoint is too much and too big, but an out-of-the-box solution may just offer what you need without too much hassle.
  If you already know you are going the SharePoint way, the report may help you to determine if a ready-made solution would be useful. Even if you think you know SharePoint well, you will learn a few things that may be relevant for you now or later.
  You may decide not to go for a ready-made solution, or even not to go for SharePoint at all.
  The report may also trigger you to refine or extend your requirements. For instance, we all have “Company News” on our radar, but have you thought about if and how SharePoint can be used for ideation? If Communications is your major stakeholder, they may not immediately think of the need for transactions. You may want to check with all stakeholders if they have thought about those things.
• Anyone who has to decide on the need for custom development.
  If none of these vendors mentions what you are setting out to do, you may indeed need to develop it yourself. But if they all provide this functionality, it is probably available as an app somewhere.
• Anyone who is working on their intranet or digital workplace roadmap, to determine whether it makes sense to move to a ready-made platform in future.
• Anyone who is curious what intranets-in-a-box have to offer.

But isn’t this a lot of money?

No, it is not.

1. That amount of money will buy you only a few hours of consultancy.  If you want to set up your own requirements to test against, agree on it, find and talk to all the vendors, have demos and evaluate all the results in a consistent way you will need much more time than “just a few hours”.
   Besides, the evaluators have not been biased by their own requirements.
2. I can offer you a 10% discount if you use the code “IIAB2CBOX10” on the product page .
3. You can probably get away with charging this (< 500 € / £ / $) on your credit card and submitting it as expenses 🙂 .

Good to know

I have reviewed this report for a number of reasons:

1. I was interested in the topic because I was curious if the intranet I am working on could have been done out-of-the-box, which might have saved us a ton of time and hassle.
   (Answer after reading the report: I think we really needed the extra work we have done to meet the requirements.)
2. So far, I have been the only “practicioner” who has reviewed this report. I think it is important that someone, who is actually in the middle of a SharePoint project in a company, shares their view.
   You will find more reviews on the Clearbox blog.
3. I have known Sam Marshall personally for a number of years. I also know most of the people who have worked with him on this report. I have great respect for all of them. Therefore I trust this report.
4. This has been a Christmas present so I have had the time to read and think. 🙂

So, everything came together very nicely this time.

Title inspired by “Living in a box” by Living in a Box from 1987.

 

 

Minimizing minor versions

In my earlier post I talked about minor versions (drafts) in SharePoint. Since the concept is not well understood and you can not limit the number of minor versions, they can cause issues in your team sites.

How to know you have many minor versions?

First of all, your Site Collection Usage Summary > Documents will show you if there are documents that use a lot of space because of their versions. You will need to check the document library settings, and/or create a view including the “version” column, to know if this could be caused by many minor versions.

Next to that, there are reporting tools that can check all libraries for their settings, including versioning settings, or can give you a report of documents with many versions.

How to check if minor versions can be removed?

Talk to the content owner. I have found that the content owner is not always aware that versioning has been enabled, does not always know how it works, or that versions eat storage space. Once they understand, they will generally be cooperative.
(Microsoft, it would be nice if you would show “versioning enabled” in the document library tile – remember? )

For site (home)pages, keeping many versions does not make much sense. Most issues occur with site owners who can not edit their page (because it has been checked out) or with web parts that have been accidentally closed. I have never needed to restore a page.
Limiting versions to 5 major and  minors on 1 major version is usually sufficient. (I call that 5/1)

Good settings for versions when there is a process. This setup keeps 5 major versions, and drafts only on the latest major version. As soon as you create a new major version, the old drafts will be removed.

If you have a formal document publishing process things may be different, but again it helps to talk to the content owner about the exact process. Quite often it is not necessary to keep old drafts of documents once a new version is published. Especially if nobody adds comments about the changes, old drafts add no value.
Setting the minor versions to “on 1 major only” can often be done easily without too much resistance once the content owner knows what the versioning settings mean.

How to remove minor versions?

1. Automatic – The best way is to limit the number on the 2nd box to 1. This will remove the earlier minor versions on earlier majors whenever you publish the latest draft.
2. Manual – All minors for the document.  Look at the Version history of the document and select “Delete all minor versions”. The versions will go to the Recycle Bin.
3. Manual – Individual versions. Look at the version history of the document and remove minor versions one by one if you only want to remove a few.
4. Workflow – Run a workflow that removes minor versions.

You are allowed to remove minor versions  – how to proceed?

When you have established that you can change the versioning settings from unlimited to e.g. 5/1, you may want to do the following cleanup next to free up space. You can also wait until all documents have been edited, but that may take more time than you have.
This is the manual method because you will do a selective cleanup:

1. In the document library, create a view that includes file size, version and modified date.
2. Identify documents that are large, documents that have many versions (generally, having a version “20.11” is a clue for more minor versions) and documents that have not been modified for a year or longer.
3. Delete minor versions for large documents.
4. Delete minor versions for reasonably sized files that have many minor versions.
5. Delete minor versions for old final documents. These are unlikely to be edited anymore so the drafts will no longer be necessary.
6. Switch versioning settings to limit the minors to 1.

Deleting all minor versions for a file. This is shown in “version history” for each document.

Please note that switching to “only major versions” does NOT remove the minor versions that are already there, not even when you edit the document.  You have to remove the superfluous versions from each document first.  So if you come from a situation of unlimited major and minor versions, always set the minor versions to “on 1 major only”.

See also my earlier post about versions.

This all may seem like a lot of hassle, but if you, like me, have been struggling with freeing up storage space, every little bit helps!

Image courtesy of marcolm at FreeDigitalPhotos.net

Minor versions, major problems

“Hey, do you see that? We can keep versions.”

“Oh nice, that is useful.”

“Apparently we can do major and minor versions.”

“What does that mean?”

“I don’t know, but let us select them both.”

“I see you can also set a limit.”

“Nah…let us not do that. Let’s keep them all, just in case. Better safe than sorry.”

And that is one of the reasons why you, dear site collection administrator, are faced with a site collection that is bursting at the seams, if you are using an older version of SharePoint. Each version consumes the space of the document.
Office 365 saves versions in a different way. Dan Adams has described that well.

There is a time and place when versions should be used. This is my take on things:

When to use major versions?

For document libraries that are highly collaborative, I recommend to use 2 or 3 major versions to prevent accidents with online editing. I have had to ask for a backup and restore several times, because someone messed up an Excel file and they did not have an earlier version to restore.

For document libraries that need to keep track of version history for audit reasons you will probably need to keep more than 3 versions, but major versions should be sufficient.

For lists, I would suggest to enable versioning if your lists facilitates a process or regular updates and you want to keep track of history.

When to use major and minor versions?

Minor versions or drafts are useful if there is a publishing procedure in place:

• The current official document is online.
• Someone needs to review and update the document on a regular basis, or can propose a change while the existing document is still the official one.
• This reviewed, updated or changed document version is added to the library (via online editing of the official document), and kept invisible to the general audience until it has been reviewed, approved and published as the new official document.

This is a common scenario for policies, procedures and lots of other formal documents.

In publishing sites, the Pages library has unlimited major and minor versioning enabled by default. This is useful for sharing a page edit with other contrubutors before publishing the new version of the page. Although page versions do not add much to the consumed storage space,  I always limit the versioning whenever I create such a site.

However, there are some things you need to know before you start working with minor versions.

1. It is not immediately obvious IF versioning has been enabled, and if so, if it is major only or major and minor.

You need to go to Library settings > Versioning settings to find out. I wish there was an indication on the tile!
If you have a formal publishing process, I would encourage you use the visibility settings as shown in the screenshot, and please read all texts well.
Content approval is optional. If you enable that, you can further limit visibility to approvers only.

Suggested settings for versioning if you have a publishing process in place.

2. It is impossible to limit the number of minor versions for a file.

You limit the number of major versions that can have minor versions. The number below should therefore always be smaller than the number on top. But that means that there is no limit on the number of minor versions.

Major and minor versioning setting. Read well what it says!

3. Allowing minor versions makes the user interface more complicated. 

Users have to choose between major or minor version, and I have experienced that not everyone knows the difference. (I once noticed a final project proposal with version 0.59. When I asked the project manager he said he always did it this way because he did not know what it meant.)

This dialog box can be confusing if you do not know the difference between minor and major versions.

4. It takes some effort to get rid of minor versions.

That will be the topic of my next post.

Have you read my earlier post about versions?

Do you have other scenarios where you use major and minor versions? Please let me know!

Image courtesy of stockimages at FreeDigitalPhotos.net

 

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/