SharePoint Online Site owner training

Learning-Collect“There’s plenty of SharePoint Online help, blogs and videos around” I boasted some months ago, when I set off to execute the training plan for the SharePoint Online intranet that we have launched recently.
I expected to “curate” most of the learning materials, and to create only a few.

Our criteria

We set off with a number of company and project criteria:

  • The company’s learning strategy is the 70/20/10 model. This means people learn new skills and knowledge in different ways: 10 % in formal training, 20% in peer-to-peer learning and 70% in their daily work.
  • Learning is based on the 5 moments-of-need model, so we have to make sure the right materials are available at the right moment.
  • We have made some customizations, such as a limited permission set for Site owners (less than Full Control), and a custom display on Promoted Links. We knew beforehand we would have to create materials for those topics.
  • I would focus on learning materials for Site owners.
Our learning principles

Formal learning

The 10% formal training now consists of an e-learning program providing a high-level overview of purpose, concepts and functionalities of the new intranet, including the Critical Skills. (The “how-to-click” details are in the “on-the-job learning materials” which are referred to in the e-learning). It takes between 1 and 1 1/2 hour.

elearning-testI created several modules in PowerPoint, and recorded voice-overs. This means we can replace any module (e.g. Permissions, or Custom Site Templates) easily without having to redo it all. Some inconsistencies are still being fine tuned as I write, new functionality developed, and Microsoft may change some things as well 🙂
I then created a number of test questions with multiple-choice answers, and added a Site Owner agreement (rights & responsibilities) which all trainees have to sign off (using a SharePoint survey).

Our e-learning specialist turned this all into an e-learning programme. It looked very easy but he has obviously done this before 🙂 (He also does freelance work if you are looking for someone!)

This e-learning is mandatory for all existing and new Site owners.
And before you ask how we are going to enforce that: content migration from the old into the new platform is still going on, and a Site owner can not start working in their SharePoint Online site until they have completed the training.

Peer-to-peer learning

The 20% was easy to set up: a Yammer group to ask peers or the intranet support team about all kinds of intranet- and SharePoint Online-related questions.
With the platform being launched recently and the migration of content in full swing, it will be no surprise that this channel is currently very active.

elearningyammerIn the e-learning and in all communications we invite people to share their questions in this Yammer group, and we make it a point to have all questions answered quickly.

For issues, such as things not working as they should, or errors, we have a more formal support channel.

On-the-job learning

The 70% would be the “curated content” I envisaged. I set off enthusiastically in the Microsoft support pages, as well as in many other blogs by people who write for Site owners, such as Let’s Collaborate, SharePointMaven, Sharegate and icansharepoint. Oh, and my own blog of course. My posts are often inspired by “my users” and my daily work.

Well, that was a bit of a disappointment.


As it turns out, the majority of the available information is not 100% applicable to us.

  • Our customized Site owner role made it hard to use anything that has to do with permissions. But also materials that tell you how to customize your site are not appropriate because the new role also has limited design options. So I could not use Gregory Zelfond’s Power User Training, for instance – it starts with creating a site and changing the look.
  • Our custom Promoted Links display needs some extra steps for certain page templates.
  • Many of the materials were not 100% current – with document libraries being managed with Tabs instead of the Modern look-and-feel, for instance. I wanted things to be 100% applicable when we launched – the correct look-and-feel and correct functionalities. The difference between the old and the new platform is too large otherwise.
  • Most of the materials have NOT been written in a “life cycle” format
    1. What it is and when to use it
    2. Create and configure “app”
    3. Add to and configure web part on page
    4. Add item to app
    5. Edit or delete item in app
    6. Modify something in app and/or web part (views)
    7. Delete web part
    8. Delete app
    9. Tips & tricks & troubleshooting
    10. Good practice

So, I have done a lot of writing, and my colleague has made tons of videos to accompany that. I have used Microsoft materials and some of the blogs I mentioned – often as “additional information” or “good practice”.

Final setup

This is the final setup

Next steps

I will continue to adjust my own materials and scout for other good stuff. I hope that over time, people will learn to deal with the ever-changing look-and-feel and not be confused by a video of a document library that has “last years style”. Then we will be able to use more materials created by others.

We are also working on a plan to make sure the Yammer channel keeps being active when everyone will be in the “business as usual” mode again.

I will also have to adjust the e-learning on a regular basis.

It has been quite an interesting project to create all this, but it is strange to be doing that while there are so many materials already available on the internet. It feels as if I am reinventing wheels, which I hate!

Have you created learning materials yourself or have you borrowed with pride?

Multiple choice image courtesy of Becris at


Site Permissions Breaking Bad, episode 2

The Invisible Library.

Broken eggSome time ago, a Team Site Owner asked me if I could help her move some content from one site to another. Since she had Full Control in both sites, she had the right to ask and I helped her transfer some large libraries and lists.

I then asked her what to do with the rest of the content. There was another library with a large number of documents in there, and the usual array of semi-empty Calendars, Task Lists etc.

She said she did not need anything else and that the site could be removed after some time. So we agreed that I would add a message to the site’s homepage, informing people of the new location for the content, and the date when the site would be removed.

At the agreed date I removed the site.

Several months later…

…another person from that department asked me about a certain library that he could not find anymore. He sent me the link and I saw it was the large library in the site I had deleted…

It was too late for a restore so the content was lost. Of course we all felt devastated, and I made a short analysis of what had gone wrong. As with most major accidents, it was a combination of several mistakes.

What had happened?

  • One content owner had removed all other people with Full Control from the library, and made it accessible for himself and a few other people only. So, the other people with Full Control did not see the library anymore, including the person I had worked with.
  • They used only the direct link to the library to check the documents. They never went via the homepage, so they never saw the message that the site was about to be deleted.
  • There was no message in the description of the library, so I had no reason to assume that there were any different permissions in that library.

What have we learned?

  1. Never remove the  Owners/Full Control group from a library. The Owners should be able to manage their site properly. If they do not see all their content, they may make incorrect assumptions.
  2. Add information about different permissions to the description field of the list or library .
  3. Ask the SharePoint administrator for a screenshot of the “View site content” page before you decide to delete a site. The administrator sees all content, and you can compare that with what you see.

This was the situation:

Library where Site Owners have been removed.

As always, your comments, suggestions and shared experiences are welcome!

Image courtesy of artur84 /

Site Permissions Breaking Bad, episode 1

BreakingPermissionsThe Survey.

In my earlier post, I showed default site permissions and what happens when you break permissions in one library.

This time I will show another common scenario with non-standard permissions, that may give issues if you do not set it up properly.

Scenario: Your list or library has a larger audience than the rest of the site.
This is quite common when you conduct a survey or have a request list in your site. You give your target audience contribute access to the survey or request form. They will generally not need to do anything else in your site.

In the picture below, the yellow circle is an additional members group with access to the one list, only.

A common setup for a survey, or a request form. The audience has access to the one list only.
A common setup for a survey, or a request form. The audience has access to the one list only.

This is an adequate setup if you are conducting a one-time survey, or have a request form where you invite people to participate via a link distributed by email. But in the following cases your users will still experience issues:

  • If you use a “Thank you page” after submitting feedback. The “Thank You”  page lives in another part of the site. Users will get an access denied as soon as they hit “Save”. Their feedback will be saved, but it is an unpleasant experience which will lead to many questions.
  • If you send them the link to the site, and ask them to navigate to the survey or request form, or click the survey/request form link or button. They will get an access denied when they try to enter the site.
  • If there are drop-down fields in the request form that use lookup lists. If they do not have access to the lookup lists, they will get a blank drop-down box.

Suggestion for a different setup.

  1. Determine if the rest of the site content is very confidential. If yes, store your survey in a less confidential environment. If not, proceed with 2.
  2. Add everyone in your audience to the a new group with Read access
  3. Create the survey, request form, library or other “app” 🙂  (I think it is really funny that lists are called Apps now)
  4. Now break permissions in the list or library
  5. Edit permissions for the new group from “Read” to “Contribute” in that list
  6. Break permissions in any confidential lists/libraries from your visitors and remove the new group. (Optional)

Your site’s permissions will now look like this. Much better and less issues!

Your audience now has read access throughout the site (with perhaps an exception or two) and contribute permissions for the list. This is less error-prone.
Your audience now has read access throughout the site (with perhaps an exception or two) and contribute permissions for the list. This is less error-prone.

Giving people access to one library or list only, is like asking the painter to come in through the window, not through the front door. It is better to let him in through the front door, and close or lock some rooms, than the other way around.

Next time, another example of how breaking permissions can go really bad!

Title inspired by award-winning series Breaking Bad.

Image courtesy of David Castillo Dominici at

The Curse of Customization

The briefing for our new intranet was: “It should work like the current intranet as much as possible”.

CurseofCustomizationWe had just spent a lot of energy in educating our users, and usage of our custom-built intranet was going up rapidly. We had appointed some Intranet Champions that were keen to create intranet sites for their departments or processes. We did not want to annoy or even lose them by changing the functionality that we had created with such care.

A bunch of excellent consultants had built our old intranet. They were a Microsoft Gold Partner, so when management decided we would “buy” rather than “make”, they were the perfect partner to create our new SharePoint intranet as well.
We had a great time! Together we brainstormed about how we would wanted the functionality to work and we reviewed all functionalities, opportunities and potential issues for users and for ourselves. Our partners happily tweaked everything the way we wanted it. I guess we provided them with an excellent learning opportunity, because it was early days for SharePoint and everyone needed to make some miles to truly understand it all.

6 months before launch, we set up a test environment for our Champions and other heavy users. We gave them a short training and asked them to do a few things and provide us with feedback. They appreciated being involved and came up with some good remarks.
3 months before launch we made an improved test environment available for all users. We created e-learning modules for end users, because we had customized so much that regular SharePoint trainings did not fit. We trained our Intranet Champions in site management and other new functionality.

Launch day came and went without major issues. Everything worked, there were no connection or other technical issues and apart from some questions, all went smoothly. After some weeks we found that in some small remote offices they were still using the old intranet (they asked why the news was not updated), but we could quickly solve that.

After some time, we noticed that our Intranet Champions became a little less engaged. Partly this was due to normal turnover, but we also learned that our most active Champions had lost track of how things worked. And when our Top Champion asked for help because he did not know exactly how to rearrange the content for his new department, we started up our “Business Solutions Team” to help people set up their sites and help them streamline their processes.
But this taught us that all our efforts to mimic the “custom-built” functionality had been in vain…

Maintenance and support
In the beginning, Microsoft was very interested in what we had done. (as it turned out, the next SharePoint version had many features that we had built in our earlier version :-)). However, since we had deviated so far from the platform, they could not always provide proper support. Every time an issue arose, we first had to discuss how we had implemented it, and only then they could investigate and solve.  After some time they stopped this because we were out of the initial service window.

Also, within our own team of consultants turnover and loss of knowledge became an issue. As people moved on it was harder and harder to find someone who had sufficient understanding of our tweaks, and was able to keep the system stable without making changes. And of course most consultants want to work with the latest SharePoint version, not with the current or an older one.

But also our outsourcing partner did not properly understand what we had done, and they had their bit of turnover as well.  Issues were not being solved anymore because everyone was afraid to touch the system.

Service packs
Every service pack deployment was an adventure! We would never know which tweak would be negatively impacted, so we had an extensive test script of which we all had to do a part. Fingers crossed that nothing would break!

Upgrade/content migration
When we thought we would finally migrate to a newer version of SharePoint, we did some migration tests together with Microsoft. We migrated one site with documents to the new platform, using Microsoft’s migration tooling. Although the receptor site and the logs showed all indications about receiving the documents, until this day we have never been able to make them visible.
That meant we would have to completely rebuild any new intranet from scratch and find another way to migrate the content.

What have we learned?
The briefing for our new intranet was: “It should be out-of-the-box as much as possible”…

Image courtesy of Kheat at

Lingerie and Labeling on the intranet.

LaceOnce upon a time (it must have been around 2002) we reserved some space on our intranet home page for new products. Being in an international consumer goods company, we thought it would be good if local marketeers could share their new products or promotions with the rest of the world. At that time, the company was very decentralized, and many wheels were being reinvented. We hoped the little “box” (the words “widget” or “web part” still had to be invented  🙂 )  would make it easier to share ideas.

We called the box “New Products”.

Once someone had requested and received contribute rights, they could upload pictures and enter text. These were visible to all employees, and all new products were being shown in rotation. (the concept of “carousel” had not yet been invented 🙂 )

It was quite popular because people were proud of their innovations. Employees in other countries would sometimes ask if and how they could buy the product, or if they could use the promotion mechanism for their own purpose. So we considered this functionality a moderate success.

That does not mean all went smoothly.

The company also had a textiles division, and a brand specializing in pantyhose and ladies’ lingerie. The products were great – beautiful designs, innovative materials and latest technologies. The brand marketeers were very proud of their products and showed every new product in the New Products “box”. They displayed their products on beautiful models who wore not much else…
Not everyone appreciated that amount of exposed skin, and we (as the owners of the functionality) received many complaints.
We therefore asked the brands to dress the models in a long-sleeved blouse, unbuttoned, to cover some of the skin. The brands agreed, but did not understand that some people were uncomfortable with their pictures, just as the other party did not understand why you would want to post that kind of pictures on the homepage of the intranet.

Pads vs Pods
Another interesting discussion was the one following the display of our latest varieties of coffee and tea pads on the New Products box.  The European marketing teams were proud of their very successful new products, but other countries objected to the use of the word “Pads” on the product pack, because that was associated with feminine hygiene products. In those countries, the common word was “Pods’.
Of course the European brands did not change the name of their succesful range, but it was an interesting reminder of the different meanings of a brand name in different cultures.
Some time later, a computer company launched a tablet computer that used the “wrong” word and nobody complained about that. 🙂

A strategic decision
But then company management had a session about the future direction of the company. As a result, we were asked to change the name from “New Products” into “Growth Drivers”.
While we understood the concept, we were not happy with this, because we were afraid that many employees would not understand the purpose of this box anymore. After all, we were a multinational manufacturing company, and a large part of our employee base, including local marketing, was not exactly fluent in English.

We tried to discourage management but alas, “Growth Drivers” it had to be.


From that moment, the use of the web part  (by then we had moved to SharePoint) declined. Even while the only change was the name, employees did not recognize it anymore, especially our non-US population. They asked where the New Products functionality had gone and were annoyed when they discovered that a perfectly good name had been changed into something “fuzzy” that needed “translation”.

What have we learned?
Keep your intranet labels simple and intuitive, especially when you are in a multinational company where not everyone may be fluent in English.

You may also like:

Mind your language. A guest post on Wedge’s Kilobox Communiqué.
How NOT to implement a Discussion Forum.
What does your content smell like?

Lace Image courtesy of andyk at
The Banana-Caramel pie is my own creation. Recipe available on request!

6 Mistakes to avoid when installing intranet kiosks

kiosk_256It was not my plan to write about this. With more and more computers on the production work floor, and more home and mobile access for intranets, I honestly thought that intranet kiosks were a thing of the past.
But recently I met several people who are planning to install kiosks in their companies, so I thought I’d share my experiences and help them avoid the mistakes we made.

More than 10 years ago we installed kiosks in some production locations in Europe. The idea was simple: give employees without their own PC a place to access news, policies and procedures, forms etc. It was much applauded by the works council, we thought they looked pretty cool and we expected people to swarm around the installations regularly.
However, not much happened. Whenever I visited a production location, I looked at the kiosk, gathering dust. Some were even broken, and had been so for months.
We decided to take them away and ask people why they did not use the kiosks.

1. Nobody was responsible
There was nobody who was responsible for communicating the availability and purpose of the kiosk, work with management to stimulate usage and adoption, or to call support when something was broken.

2. There was no technical support
IT thought we were supporting these and we thought IT did it. Both parties did not know how to maintain the machines. 

3. There was no training or instructions
At that time, we thought our production personnel was not that internet savvy. Despite that, there were no proper training or clear instructions provided.

4. People had to use the kiosks in their own time
Since management did not know the benefits of using the intranet at that time, and feared all employees would be “surfing on the intranet all day”, personnel was only allowed to use the kiosks in their lunch break or after work.

5. It was not personalized and it was read-only
All our European kiosk-users saw the rather American-oriented homepage by default and they had to click several times to get to useful local content in local language. It also meant that people could not complete forms or make requests or share documents. The American news did not interest them, and the useful content was not fully accessible.

6. They were positioned in crowded locations
Although it was a good idea to bring the machines to places with many users, it meant that people had difficulty concentrating, because many people were talking and passing by. Remember, employees were only meant to use this during lunch!
And…you could only use it while standing.

One of my colleagues used these lessons to roll out an intranet café in a more comfortable setting and with better conditions. Still it did not bring what she had expected. I am therefore still doubtful of the use of intranet kiosks. I am not alone, see these earlier articles from Toby Ward James Robertson and Steve Bynghall who all suggest home and/or mobile access as a better option.

But if you really want to do this, please do not repeat our mistakes! (And please share a blog post with your key success factors!)

Image courtesy of Visual Pharm via


Ouch-sourcing“Andrew, it is not working” I shouted from my office.
“K”, came the reply from across the corridor, after 5 or 10 minutes followed by “Fixed it!”.
Andrew, our in-house SharePoint whizzkid, had built our intranet, knew everything about it, and liked a challenge. He loved finding out what was wrong and fixing it before I had time to tell any user that we were working on it. Sometimes he had to reboot a server, sometimes it was a piece of code behaving strangely, sometimes a local hitch, but he was 99,99% reliable to fix any issue within an hour. And he was not even an employee, but someone we hired long-term from a partner.

But then management decided to outsource all application development, service and support to one external company. Of course this would save the company lots of money. We could now use people depending on our needs, did not have to plan around holidays or be worried about illness. The service provider was supposed to be knowledgeable in all systems, including SharePoint, so that was convenient.

So we had to let go of Andrew and his colleagues. Andrew followed his long-time dream of moving to Australia and the last time I looked at his LinkedIn profile, he was still there.

But first we had to handover all info to the service provider.
We created a team site for all documentation, code, installation manuals and what not. Next to that we organized many Live Meetings to go over all details with the new support party. We recorded those and added them to the documentation site.

So, the good point of the situation was that we were finally forced to get all our documentation properly organized :-).

Unfortunately, there were also a couple of bad points…

  • First of all, there were lots of language and culture issues so it took quite a while before everyone understood each other properly. The fact that Dutch people are quite direct (if not downright blunt), and not very hierarchical, was not really helping the working situation with a partner from a more cautious culture where everything had to go through a manager.
  • Our service provider did not understand our environment due to the many customizations. They always wanted to change code to solve an issue, but since we no longer had anyone in our team who understood the implications, we were afraid to approve of that. In the end it meant that issues were not solved at all and we learned to live with them, anxiously waiting for the moment we could upgrade (which did not happen during my time at the company).
  • All issues had to be reported, reviewed, taken in, calculated, approved, planned, executed, tested, approved, implemented and communicated. And that was without any rework! OK, I also like some order in my household administration, but it was so much work and took so long. How I longed sometimes to shout “Andrew!” And sometimes I just did, for the sake of it :-).
  • And whenever we had finally created a good rapport with a team member,  he or she hopped to the next job with hardly any handover and we could start all over again, instructing someone into the intricacies of our system and hoping (in vain) that over time, issues would be solved.

We were not the only team with issues. So management organized regular top-to-top meetings to discuss the issues and iron out all wrinkles. Nobody dared to question openly if, given the general inefficiencies, there were still any savings compared to having an in-house crew.
When asked about the turnover of project members, the support provider answered with a longer version of: “Our people want to have a varied career and we want to provide them that”.  I read the statement at least 3 times, but I could not find any reference to the words “customer”, “service”, “commitment”, “continuity”, nor any synonyms.

Since then I have heard the same story from many others, so I really wonder if outsourcing is such a good idea. In theory it sounds good. With the opportunities of the digital workplace and all parties being used to remote working, we should be able to collaborate seamlessly and independent of location. Within our direct team we certainly could!
However, in practice it simply did not work well. Did we just resent the situation? Was it the cultural differences? I do not think so. I rather think it is because by outsourcing you introduce measurable formality, and take away things like responsibility, company loyalty, spontaneity and team feeling. And those last 4 things, which are not as easy to measure as “total cost of ownership”, “average resolution time” and “customer satisfaction score” may be more important than we think.

What do you think? I would really love to hear from someone who has a great working relationship with their outsourcing partner, or from someone who has reversed their decision to outsource. Please share your story and especially: share your lessons so we can all benefit!

Image courtesy of kjnnt at