My second SharePoint intranet

This project was started in 2015 and launched in 2016.

The situation

The old intranet was built on SharePoint 2007 (on-prem) and bursting at the seams. Each business had their own site collection, with many subsites underneath. Each site collection could only hold 2 GB (!) so it was a constant struggle to keep within those limits.
I was the functional owner of a number of site collections and most of my posts from that time deal with keeping the storage space within its limits. So I shaved off versions, migrated stuff to archive collections or even shared drives, optimized presentations and what not, in order to keep the ever growing collections within limits.

The different business were quite autonomous in their approach, so some site collections had been nicely reworked with SharePoint Designer, and some had lots of workflows. There was an attempt to have common procedures, but this was all voluntary and not mandated.

All business and ICT folks who were involved with content, support and system maintenance really wanted a new intranet!

The project

After many years of project proposals we finally got approval to start creating a new intranet, based on SharePoint Online. This was not so much because the budget holders thought they needed an improved intranet, but because support for SP2007 would stop and the business wanted to move more applications to the cloud.

A Microsoft partner was found and off we went! At the beginning I was not really involved, which frustrated me. At a certain moment I just inserted myself into the weekly progress meetings and started asking questions and giving advice. After all, I had more direct contact with users of the current intranet than anyone else in the project, so I thought my input could be useful. Some weeks passed and I was considered one of the project team 😁

Mistake #1: Majority of budget went to News

We spent the majority of budget on creating a custom News function, which would be targeted and personalizable. It consisted of one page per news item in a special page format, a (too large) number of tags, and a publishing flow. Especially the targeting and personalization took up most of the work, as it had to be build and was rather complex.

When we launched, it was not fully ready but most of it worked. Improvements were on the roadmap.

The project team then attended a Microsoft event and heard that Microsoft would launch SharePoint News a few months later. We collectively cried a bit 😂

Mistake #2: Agile development, Waterfall operations

This project would be a pilot for introducing Agile methodology into the organization. We got trained and it went actually quite well. I like having many short improvement cycles, it suits my working style. When I was creating “Business solutions” at my former employer, I also worked like that, knowing that ideas and requirements would change as my customers learned more about the capabilities of SharePoint as we progressed.
(I know there’s more to Agile but this stood out for me)

At launch, the intranet was a Minimal Viable Product. We had a roadmap to improve it over the next months. Only…due to cost savings the improvement budget was cancelled, which was a big disappointment and not a good way to deal with Agile. It turned out that an MVP is a good, but vulnerable, concept.

Additionally, no budget was provided (let alone left) to provide adequate documentation, as that is “not Agile”. That did not sit too well with the operations manager who had to provide the support, but we thought we could manage, as both an important developer and myself were in-house. I wrote about this mistake as well. (TLDR: the developer left shortly after launch…)

Mistake #3: Custom design

The idea was to make the intranet look like the corporate website. I do not always like this, as the purposes and audiences are completely different and one generally changes the website design more frequently, leaving the intranet with an “old” look-and-feel. I have ranted about this earlier. 😁

It meant that, for communication sites, we had

  • a non-standard font size, rather large
  • a Promoted Links tile that had slightly different behaviour (dimensions, hover-over) than regular, causing tons of confusion with people who looked on Microsoft Support or YouTube for instructions
  • 65% white space, which drove people nuts because they had to scroll a lot to see the content they had to work with daily
Example of a page with customizations.

We had custom page templates to allow these features.

For team sites, we had custom content types, created to make a difference in stages of a document, as well as hidden tags to help Search. These were also organization-based. Then we changed the organization. Do I need to tell you about the consequences? Fortunately, not many people were aware of the custom content types, most people just used the default and never looked back…

In my post about my first intranet I already mentioned the joy of customizing SharePoint, so I will not do that here. Let’s keep things cheerful! 🥳

Mistake #4: Migration mistakes

The project team initially decided that we would only centrally migrate content that was no older than 2 years. Older content could be migrated by the owner if they thought it was necessary. However, the business insisted that everything should be migrated, as it was too much work to filter out the relevant content and “we had enough storage space now”. So even very old files that I could no longer open in our SP2007 environment were migrated, and still could not be opened. What a waste!

Additionally, the “migration factory” (as the migration team called itself) often forgot to include the new page templates and/or to remove the old page templates. This led to frustrated users who could not use the new templates, and to frustrated support people as people kept using the old templates so we did not get the uniform look-and-feel that we wanted. It was up to Support to adjust all mistakes as these would generally show later.
Permissions were migrated as they were, and not (as we preferred) on the site level only (to allow the business owners to review any more detailed permissions).

Of course we also have some successes to report:

Success #1: Modern SharePoint environment

Apart from all the other SharePoint mod cons, we finally managed to make every site stand-alone; the subsites (sometimes 7 layers deep) were gone, and we had STORAGE SPACE! 🥳

Success #2: Central governance

The organization had given a more central role for ICT. This meant that all site collections were now managed by one ICT team, rather than by the various businesses and ICT. This allowed us to finally have one central governance, for instance:

  • Central creation and deletion of sites
  • Naming convention for sites, so each site had a unique identifier. We used a number, which I thought was rather unpleasant as it gives you no clue what the site is about, but with about 25,000 (!) sites it was the easiest system
  • Custom role for the site owner, so they could not do everything (esp. in design)
  • Central review and reporting on the site collections

Success #3: Mandatory Site owner e-learning

I have always been in favour of a sort of “site owner exam” and it fitted within our more strict governance, so I created a training and a test in e-learning format.
Remind me to share the test in a Form one of these days, so you get an idea of what we wanted people to know. An earlier post about our training setup.

Success #4: Launch video!

The communications department created a rather nice teaser video to celebrate the launch. The original version lives on a corrupted USB-stick, but I managed to find an old Teams recording showing it. Please play at 2 x speed to see it properly. The sound has been lost during the process, there was a simple music soundtrack behind it.
Now you understand why I am partial towards intranets called “Connect”! 😊

Leave a comment