blog.frederique.harmsze.nl my world of work and user experiences

September 30, 2021

IT governance and user adoption need each other

Filed under: Adoption,Governance — frederique @ 21:24

I have said it before: it is not enough to set up an IT solution. You will just end up with a solution that nobody uses and that soon is no longer useful anyway. But then again it is not enough to only organise its governance. Or to only stimulate its user adoption. The IT solution needs both of them. And governance and user adoption also need each other.

The users need to adopt the IT solution for it to be useful

If the users do not adopt it, why did you spend time and money to create and roll it out? For a museum? You will never achieve your business goals if the users do not embrace the solution and use it.

If your project only had technical goals, like migrating from an obsolete platform or updating it, before its end of life: if nobody uses the new version and you are fine with that, why didn’t you just unplug the old one? No need to replace or upgrade it it. And yes, I do see projects where only technical goals are stated, like the migration or update of an obsolete version of SharePoint, for example. And then I also ask what’s in it for the users, would-be users or should-be users.

So you need to be clear on what’s in it for the users and help them adopt the solution to achieve those goals. In other words: you need an adoption plan and you need to implement it.

Governance needs to be in place for the IT solution to stay useful

If there is no governance on the solution, it may soon be obsolete when the environment evolves, the users get swamped in obsolete stuff that is not curated and cannot find the stuff that has become relevant. Security issues appear, as the recent users don’t have the right permissions and old users have permission that they should no longer have. I already talked about this is a previous post, the snags we hit if you don’t have governance in your Microsoft 365 environment.

So you need to determine what the governance should be, so that the organisation and the users can keep achieving the goals you were aiming for. In other words, you need a governance plan and you need to implement it.

Governance also needs user adoption

Even if you have a brilliant governance plan, it won’t help you if the users do not adopt that governance along with the solution. If they haven’t adopted that governance, they won’t know what to do to, and what rules and guidelines to follow. For example, they need to know if and how the can get a Teams environment, if and how they can get access, if and how their document will be archived or deleted.

Of course some of the governance is completely invisible to the end-users. For example, if everyone has the same license, the end-users don’t have to know how you manage those licenses, as long as it all just works. No adoption needed there.

So you need to include the solution’s governance in your adoption plan for the solution. For example, on help pages and in training, teach how users can request a Teams environment, what are the rules, how owners can give colleagues access.

And user adoption needs governance

Even if you have a brilliant adoption plan and made sure that, at the start, all users embrace the solution enthusiastically, it won’t help you in the long run if you haven’t arranged governance for your adoption plan and materials too. For example: when Microsoft adds a new app to the Microsoft 365 toolkit, how do we make sure that users adopt that one as well?. If it turns out that users are having trouble with a particular aspect, how do you solve it?

So you also need to include the solution’s adoption in the governance plan for the solution. For example who will Introduce new apps, explain what’s in it for them, and update the adoption materials to include this new addition? How do you identify gaps in the user adoption and fill them in?

If you fit all of these pieces into the puzzle, you will get a solid and future-proof solution that meets the organisation’s and the users’ goals and keeps meeting them. And that’s what we want.

June 30, 2021

If you have no governance in your Microsoft 365 environment…

Filed under: Governance — Tags: — frederique @ 23:05

If you have simply switched on Microsoft 365 without arranging for some well-considered governance, things tend to get messy. You could get a major security breach or lose important data. But even if no disaster occurs, you may still get a lot of confusion and unhappy users

Recently I talked about some things you should think about concerning the governance of Microsoft 365. That was inspired by the confusion and unhappiness I see at an organisation where they switched on Microsoft 365 and moved a lot of documents into SharePoint, to rescue them from an old file system that was falling apart.

There had not been time, money or sufficient interest from the business when IT had to take those actions. But then the users had to actually find their information in that new system, and they started to complain. Yes, the system is up and running, but to make it usable, it also needs more governance set up.

Here are 10 snags we hit when we have no proper governance.

1.We don’t know who can decide on the configuration.  

We hear many complaints that the main overview pages in SharePoint are useless. These complainers are perfectly right, because these pages have not been configured in any meaningful way. We want to address that, but we hit a snag: it is unclear who is responsible for these overview pages, so who can decide what should be on them? Just IT? Or people from the business? Some Change Advisory Board? With who in it? Same thing for other elements of the environment.

So you want to be clear on ownership: who should decide and who should you refer to when other users don’t agree.

2.People don’t know how strictly they need to conform and to what.

We have some Site Owners going wild in their sites, while others clamour for more consistency and best practices. It is not necessarily a problem if the department sites are all different and all Site Owners can do their own thing. But if that is how you want to set up (part of) your environment, that has to be clearly explained, so that people know what they can expect. And even then, you may want to put in some restrictions, so that they cannot include anything truly tricky. If you need more uniformity and consistency, what templates and settings do you want? And again: who decides on that?

So be clear about the rules: what templates should people use and what rules should they follow.

3.Important documents are not unique and clearly tagged.

We talked to some users who were getting desperate, because there seemed to be multiple copies of important documents. Which was the right one? Which was the officially published one? And where is it? Some documents are very hard to find, because they lack crucial metadata. For some documents, once they have been found, it is unclear what their status is. Is it a draft? Is it a copy for other purposes? Or is this the official version?

So you need to plan to keep the important data clean & clear. You not only need to explain to the users how important it is that they tag and store their documents properly, and how, but you also need to monitor and curate at least the set of important documentation.

4.Users cannot access information intended for them.

It turns out that important documents are locked up in a department site, while many others also need to consult those documents and are entitled to consult them. Just not permitted in SharePoint.

So you need to determine what kind of information belongs where and who should have access to it. For example, what belongs in a department site (or Team) only accessible to the members of that department, and what should be published to a more general documentation or knowledge site.

5.Users can edit information no longer intended for them.

In several sites, the right people have been given the right permissions. So far so good. But then some of these people got new roles in the organisation and others left. However, nobody changed their permissions in these sites or removed the people who should no longer be included. User management is not a one-off activity…

So you need to make sure access is managed regularly. Usually the Site Owners or Team Owners need to add and remove users to and from the right groups. For that purpose, you need an active Owner, and a deputy if the primary Owner is not available. But not too many Owners, because if everybody is responsible, nobody is responsible…

6.Self-service Team creation led to chaos.

At first, they had self-service Teams creation switched on, like everything had been switched on. That very quickly got out of hand, with all kinds of strange, overlapping and inappropriate Teams being created. So they switched that off. Now they are starting to allow the creation of Teams on request. But it is not clear yet how the Teams should relate to the existing SharePoint sites created from a specific site template.

So you need to determine who can create things like SharePoint sites and Microsoft Teams and how: via a request, based on a template, by adding a Team to a templated SharePoint site?

7.Users cannot get support.

If a user has a question or a request, what should he or she do? Call someone, enter a ticket in some system? The users grumble that they cannot not get any proper help, because the regular helpdesk does not know anything about Microsoft 365 and they do not know who else to contact. Very frustrating.

So you need to set up proper support and make sure that the people providing support are up to the task and stay up-to-speed.

8.The help materials are stranded.

We created and shared some training materials and we started to set up a Microsoft 365 Learning Pathways information portal. But then we had to stop, because it is unclear who is the owner: who decides how we should set up the portal, with information in which language about which elements of Microsoft 365 and with which custom additions about the specifics of the organisation? And who will keep it up-to-date? Could we start something like a ‘tip of the week’ or would it all die out as soon as the consultants left? Providing help materials is not a one-off activity.

So you need to plan how you will keep offering relevant and up-to-date help to your users.

9.We are getting drowned by Microsoft’s changes.

One thing we know for sure: Microsoft 365 keeps evolving, with new apps and improved features. We see that some users start experimenting with new options in ways that turn out to be unsafe. And we see other users get confused because functionality suddenly is different from last week.

So you need to plan how to go with the flow of Microsoft’s changes instead of drowning in them: monitor the changes, determine their impact on your organisation, determine if and how you want to activate and then manage them, communicate about them.  

10.People with good ideas feel like lone voices in the wilderness.

Now that people are starting to use SharePoint and Microsoft 365, some of them have interesting ideas for improvements. But how can they make themselves heard? How can these great suggestions be implemented? When we started to talk to people in the business, we not only got swamped in complaints, but also in ideas. However, I could only take note of them, because it still is unclear who can decide on the environment. This of course brings us back to point 1, that you really need to have clear ownership.

So you need clear ownership and a process for improvements. For example, people can request changes, discuss changes with key users, ask a change advisory board to decide on bigger changes, get budget and set up projects to realise big changes…

Fortunately, in this organisation the users and the business discovered that some governance had to be set up and improvements had to be made to the first set-up of Microsoft 365. Unfortunately, they discovered it by getting stuck in their daily work and then getting frustrated. But at least, they started the ball rolling…

May 31, 2021

Governance in Microsoft 365: what should we think about and why?

Filed under: Governance — Tags: — frederique @ 23:08

So you have Microsoft 365 up and running in your organisation. But have you also thought about its governance? The word Governance often conjures up visions of big, stuffy documents. But the point of governance is not to generate such documents, but to keep your environment up and running smoothly. So you need to ask yourself and answer some questions, as to how you want to do that. This is not a complete checklist, but rather a high-level sketch of the sort of things you should consider.

Your goals

You are rolling out or have rolled out Microsoft 365 for a reason. For example, you want to empower your employees, to collaborate, communicate and share knowledge effectively, efficiently and safely, offering them a smooth and convenient experience. To reach your goals, you not only need to set up your environment properly, but you also need to make sure that it keeps working properly.

So first of all, it it important to be aware of the reasons why you are using Microsoft 365. What are you trying to achieve?

Things keep changing

Things change, so need to keep up-to-speed and keep the environment up-to-date. This is the case for every system, but it is even more pressing for systems that live in the cloud, like Microsoft 365. How do you keep meeting your goals when everything keeps changing?

  • The user population changes: new colleagues arrives, others leave or get different roles.
    So:
    • How will you make sure the right people can do the right things, at all times?
    • And how do you deal with externals/guests who are not a member of your organisation?
  • The content changes: People are collaborating and communicating in the environment, that is the whole point. They keep adding, editing and deleting content.
    So:
    • How will you make sure that the users don’t get swamped in obsolete old content?
    • How do you strongly protect confidential information, while keeping keep less sensitive content easy to use?
    • And what actually is your confidential information, which “informational crown jewels” do you absolutely need to protect?
  • The application landscape changes: Microsoft adds applications to Microsoft 365 and improves existing applications. All the time.
    So:
    • How will you stay up-to-speed with what’s new & what’s hot in Microsoft 365?
    • And how do you determine which standard applications the end-users can use, now and in the near future? What should their default settings be?
    • What are your rules for custom applications?  In particular: who is allowed to create what kind of no-code/low-code solutions using Microsoft’s Power Platform?
  • Insights and needs change: When you started with Microsoft 365, you decided what goals you wanted to achieve and how you had to set up the environment to meet those goals. But once you start using the environment, you may get new insights. And even if you interpreted everything perfectly in the beginning, the actual needs may have changed. An obvious example was the massive need for online collaboration and communication that surged when the pandemic hit.
    So:
    • How do you gather feedback on how users like and use the environment, and what they are missing?
    • What’s the procedure for changing the environment? Who decides what to change? And how do you test what it will be like, before you launch it to everyone?
    • How do you make sure that the end-users know about, understand and adopt the evolving applications that are most relevant for them at this time?
    • How do you monitor what’s going on in your environment, so that you can take action when you are moving away from your goals?

These are some things you should consider. And while you are at it, write down what you decided. Not in a stuffy document, but in a Communication Site on the intranet, that users can easily check if they want to know how their environment is governed.

September 30, 2019

Some tips for respecting the privacy regulations in project sites

Filed under: Governance,SharePoint — Tags: , — frederique @ 22:36

Recently, I have been talking about GDPR in the context of SharePoint project sites for a construction company building houses. What practical design choices should we make for the new SharePoint template we are developing, combined with instructions to our users? Let us take a look at five of them.

In a previous post we talked about the Office 365 security and compliance GDPR dashboard, that can help us detect and manage sensitive information after it has been stored in our Office 365 tenant. But it is better to think beforehand and aim for privacy by design. We should only store and process personal data if we have a clear purpose for it. And only for the people who do need these data, for as long as they need it.

1.Don’t use personal data if you can keep it abstract

In their building projects, the houses are bought by real people, who have real personal data. In the project site, information has to be shared about the construction of the individual houses: which kitchen options should be included, what work remains to be done for that house, et cetera. However, there is no need to refer to these houses by the names of the buyers.

So we don’t list a house as the one bought by Mr and Mrs Smith, but at the house with building number 32. And we explain to all users that we avoid using personal data unless it is absolutely necessary to get the job done and we can justify sharing these personal data.

2.Put documents with personal data in a clearly marked, separate, secured library

We do have some cases where some project team members do need to see personal data in order to do their jobs, like commercial team members who need to talk to the house owners and renovation architects who need to see photos of the original rooms the may display personal belongings.

So we have a separate document library for the house owner documents, which is clearly marked as such. That library is listed in the site menu under the heading ‘Sensitive’. And only the project team members who need to use these data have permission to enter the library. We explain to our users where they have to store and find these documents, and that if they don’t see the library, they do not have permission to open it.

3.Only share the personal details that are needed, nothing else

We have a secured list of the contact details of the owners of the houses that are being built, so that project members who need to get in touch with these people know how to reach them. In the past, that list also included fields to share information about the spouses, children, hobbies, et cetera. Somebody got inspired by customer relationship management and got carried away… That information is quite irrelevant for the construction job.

So we trimmed down the list in our site template, to contain only the fields relevant for the job. This way, our users understand that they should not include other personal data.

4.Only allow individuals to access personal data. Not AD-groups

In parts of their project sites, all employees in the business unit or even all employees in the company can see the information. For example, the basic project information is visible to all, for transparency in the organization. For these “high visibility” lists and libraries, access is managed by way of AD-groups that include everyone in that unit. However, you cannot easily see who is part of that “everyone group”.

So in lists and libraries that contain personal data, we do not allow security by way of AD groups. We tell the site owners that they have to add individual users to the SharePoint permission groups, to explicitly and purposefully give those people access.

5.Delete personal data no longer needed after the project

After the building project is finished, some personal data may be needed by the aftercare people. But we should not keep personal data just in case somebody may be interested in them someday…

So we remove the permissions on the personal data for the users who are no longer involved in the finished. And we delete the personal data that do not have to be kept for a clear purpose. For example, we need to keep the data of the companies involved as subcontractors, but we do not need the phone numbers of the individual people. So we keep a companies list for the project relations, but not the people contacts lists.

 

All in all, we are baking some privacy measures into our SharePoint template for construction projects. We are giving the site owners and end users specific instructions. And we are creating awareness, that we need to be careful with personal data.

February 28, 2019

Office 365 security and compliance GDPR dashboard – Yes please

Filed under: Governance,Office365 — Tags: , — frederique @ 23:57

These days, our project managers and site owners are aware that they have to be very careful to store no personal data, except data that are necessary to do the job, only accessible to the people who need to use it, only for the time they are needed, only for the purpose for which they were gathered. But are we sure that there were no personal data hidden somewhere in SharePoint 2007, dating from more than a decade ago, that we now risk exposing SharePoint Online after migration? Let us MAKE sure!

I am working on a project for a construction company that has been using SharePoint for ages. They have over 8.000 SharePoint sites for our Operating Company alone, most of them SharePoint 2007 sites. Currently, we are migrating these old sites to SharePoint Online, as “archive sites”, as part of our transition to Office 365. So we see a lot of old stuff passing by…

  • We want to make sure we keep all information that is still relevant for the company, such as construction details on the buildings they constructed, information needed for maintenance and guarantees.
  • But we also want to make sure that we do not have personal data that we are not allowed to have according to the privacy rules, GDPR (General Data Protection Regulation).

I am not worried about the remains in SharePoint 2007; those servers will be decommissioned and emptied soon. What I want to know: are compliant in our Office 365 environment, including SharePoint Online, where we are migrating all of that old information. The advantage of asking that question, is that we can use the modern tooling offered by Office 365 itself to check!

Tools in Office 365: GDPR dashboard and toolbox

Recently, I made our privacy officer very happy by showing him the GDPR Dashboard in the Office 365 security & compliance center. It is part of the admin toolbox which we already have in our tenant. So let’s comfigure it and use it to our advantage.

Security & Compliance center: GDPR dashboard

Security & Compliance center: GDPR dashboard (in a demo tenant, nothing going on…)

It took me a moment to find it, because I was looking in the Microsoft 365 admin center. You need to go to a different url: https://protection.office.com/ (at least, in the admin center of my tenant I see no link at this time)

And this dashboard comes with a toolbox:

GDPR toolbox

GDPR toolbox

Discover
Identify what personal data in your org is related to GDPR.
• Import data: Bring data into Office 365 to help safeguard it for GDPR.
• Find personal data: Use content search to find and export personal data to help facilitate compliance in your org.

Govern
Manage how personal data is classified, used, and accessed.
• Auto-apply labels: Automatically classify content containing personal data to help ensure it’s retained as needed.
• Create a disposition label: Trigger disposition reviews so you can decide if personal data should be deleted when it reaches a certain age.
• Use Compliance Manager: Access your org’s compliance posture for GDPR and get recommended actions for improvement.

Protect
Establish security policies to prevent, detect, and respond to cyberthreats.
• Create a data loss prevention (DLP) policy: Detect content containing personal data to help ensure it’s protected.
• Apply cyberthreat policies: Protect your users from cyberattacks like phishing, malware, malicious links, and more.

Monitor & respond
Track label usage, stay on top of data breaches, and respond to data subject requests (DSRs) and legal investigations.
• Respond to DSRs: Create DSR cases to find and export Office 365 data related to a data subject request.
• Respond to legal investigations: Use eDiscovery cases to respond to legal investigations.
• Review and explore label usage: Get insights into how labels are being used and take action if needed.
• Set up alert policies: Track and get notified about user and admin activities related to GDPR.
• View reports: Drill down on activity related to policy matches, threat detections, and more.
• Visit Service Assurance: Learn how Microsoft helps meet the security, privacy, and compliance needs of your org.

Data Loss Prevention Policy for GDPR

One of the items in the GDRP toolkit is to create a DLP (Data Loss Prevention) Policy to detect content containing personal data. You can create one starting from the shortcut in the GDPR toolbox or from the DLP section of the security & compliance center.

Data Loss Prevention policy: GDPR

Data Loss Prevention policy: GDPR

This will detect personal information in our environment:

  • EU Debit Card Number
  • EU Driver’s License Number
  • EU National Identification Number
  • EU Passport Number
  • EU Social Security Number (SSN) or Equivalent ID
  • EU Tax Identification Number (TIN)

You can select where it should apply. I want it to protect all content in all locations Office 365, including Exchange email and OneDrive and SharePoint documents (Hey, not SharePoint lists? And how about Yammer Groups, Teams conversations? Maybe it is assumed that nobody would put, for instance, a passport number in there. I have seen scans of passports in SharePoint documents and in email attachments, before they were removed as soon as possible…).

GDPR Policy: select the locations it should protect

GDPR Policy: select the locations it should protect

But for a test it is more practical to limit its scope and choose specifc locations.

GDPR policy limited to one test site collecton

GDPR policy limited to one test site collecton

You can customize what it should detect, for example: content shared with outsiders or only insiders?

GDPR Policy: tweak the details of what it should detect

GDPR Policy: tweak the details of what it should detect

And then what action should it take if it detects personal data? For example, email a report to the person who set the policy, the global admin, some specific mail address.

GDPR Policy: what action should it take with what it has detected?

GDPR Policy: what action should it take with what it has detected?

As a result, you get reports like these, in a csv file:

GDPR policy: report from demo tenant, converted from csv to columns to make it more readable

GDPR policy: report from demo tenant, converted from csv to columns to make it more readable

 

Ok, to be honest, in our first test it did not seem to detect any of our own examples of personal information we added in a SharePoint testsite, while it found a lot of false positive. But still, it looks very useful, once we get it to work properly.

June 4, 2016

Surprises from sites and owners in the migration

Filed under: Governance — Tags: — frederique @ 09:13

In our recent project to migrate all active collaboration sites of an organization, we interacted with a lot of site owners. We had anticipated several questions that the site owners would have and challenges that they would meet. But there were some moments when I got reactions that I had not expected at all.

We mailed about 700 site owners about 750 site collections. And it is a rather heterogeneous bunch: they come from all departments in the organisation. Some are very SharePoint savvy, while others turned out to have no clue. Some are incredibly proactive, while other could not be coaxed into any action. I have already told about the lessons learned in the migration as a whole in a previous post. Now let me elaborate on some of the surprises the owners and the sites had in store for us.

People listed as Main Site Owner who had no owner permissions

We had a migration list, detailing all collaboration site collections with two Main Site Owners who we would contact several times over the course of the migration project. We asked these people to confirm if they really were the site owners we should contact.

Interestingly enough, I got quite a few responses when I sent out the new URLs of the migrated sites, of Main Site Owners who could not access the migrated sites. At first I feared something had gone wrong with the security settings in the migration. But then it turned out that none of the people who complained about access had actually had permissions on the original site. So the migration was perfect: no permissions to no permissions. But the question is, why did these people confirm that they were Site Owners of a site where they were no kind of owner at all?

The people who gave me more details all thought that we were talking about some other site. The apparently had not clicked the prominent link visible in the migration list. They had seen the site name, and sometimes the name of their co-Main Site Owner (most sites had a deputy) and assumed they knew what site it was. They were mistaken.

Bottom line: people are only human, and very busy. So take into account that the response is not always accurate.

Mix-up between different kinds of SharePoint sites

I’ve talked several people who turned out to be confused about the different kinds of SharePoint sites we have in this organisation. There are different sites from the Local organisation: collaboration sites, intranet portal, sites with special applications (at a separate address). And there are also sites from the Global organisation. I have to admit, the environment also confused me when I got here, but that was mostly because I did not know how to get from one part to the other. But I can see the difference between the Local sites and the sites managed by the Global organisation: they not only have a different address but also a different colour.

We emphasized in our communication that we would only migrate Local sites from the collaboration address, which were branded as Group Sites. Nevertheless, I have had several questions about people asking about the migration of sites that turned out to be one managed by Global or subsites in the Portal.

Bottom line: for some users, all of those SharePoint environments are the same. Don’t assume that everybody understands the difference between intranet and extranet sites, portal sites and collaboration sites, regular sites and secure sites…

Some site owners voluntarily indicate that their sites does not have to be migrated

In previous migration projects we saw that Site Owners always said that everything had to be migrated. Unless they found out that they were the ones who had to migrate their own sites. In this project we told the people that the IT team would migrate their sites, but still 26% of the sites could be deleted, according to the Site Owners. We did tell them that they would have to take some actions along the course of the migration. Maybe that was enough to avoid unnecessary migrations. Or maybe these people are just very orderly and like to clean up, at least when prompted to do so…

Bottom line: Ask explicitly if sites should be migrated, because that may result in an unexpected clean-up.

Some site owners have set up exotic configurations

The site owners are in charge of their own sites. And some of them took the opportunity to rebuild their standard site into something exotic. And these exotics don’t always survive a migration. There were some spiffy calendar overlays ,workflows with manual links, strange things in Infopath forms, pages with weird styling, browsable reference guides in htm, non-Sharepoint pages in mht format,… Some of it we knew about, but some of it surprised us when we saw it. And most of it migrated smoothly, but some things broke.

Bottom line: Keep an eye on sites as part of your regular governance. Otherwise you may run into unexpected issues when you migrate or update, and when the unusual sites break down.

A migration is a nice occasion to meet your site owners and sites. Let’s not wait for the next migration to do it again, but keep in touch with the owners and keep an eye on their sites.

May 31, 2016

10 lessons learned in a Team Site migration

Filed under: Governance,SharePoint — Tags: — frederique @ 23:10

Recently I was in the lead in a migration project, in which we upgraded collaboration sites from SharePoint 2010 to 2013 and moved them to another location. Let me share with you some lessons I learned in that project. Some from friendly feedback, others from hitting snags head on. Some related to SharePoint, and others that don’t have anything to do with technology but are all about people: communication and process.

SharePoint

1.The content database attach upgrade method is quite handy

We had hundreds of sites to upgrade and migrate in a short time. There was no time and manpower to do it manually or to write a custom code solution to do the migration. We did have a migration tool at our disposal but that was not suited for bulk migrations, and the other tools we looked at we too expensive. So we decided to use the content database attach upgrade method.

We were quite pleased with the result: we did manage to migrate 551 site collections in one weekend, even though some were quite large. The content and settings moved along nicely, including timestamps and the names of the authors, even if they had left the company.

2.Ask a SharePoint developer to script clean-up in Powershell: automate repetitive tasks

Unfortunately, the old collaboration sites were chock-full of weird customizations. They had even customized the permission mechanism, for Pete’s sake… So we did not want to upgrade the sites completely as-is. We could have tried to reconfigure the sites manually, but that would be a lot of work.

So a SharePoint developer wrote Powershell scripts, to clean out the unwanted customizations and transform the sites. We could not get rid of everything, but after the clean-up, the migrated sites are a lot more future-proof…

  • SharePoint developer. We talked to other developers, but we found out that they could not write these scripts sufficiently quickly and accurately. The scripts had to tie into SharePoint functionality, so the developer needed a good grasp of the way SharePoint works.
  • Automate as much as possible before the migration weekend. We had a non-stop process over the weekend for the production migration, where people had to perform tasks in the middle of the night. That can be a recipe for disaster. So the developer automated as much as possible, so that he hardly had to type in any commands and took little risk of making mistakes.

3.Align the settings between the old and the new SharePoint

We found out the hard way that the settings in our new SharePoint 2013 environment differed from the settings in our old SharePoint 2010 environment. These differences pertained to exotic exceptions in our collection of collaboration sites, so we had not included them in our regular test cases. For example:

  • The threshold for the maximum number of items in a list has been increased in the old environment to 13.000, while in the new environment the lists complained after 5.000 items.
  • HTM and MHT files were opened in the browser in the old environment. In the migrated sites, users are prompted to save such files.

So next time, we will make sure to compare the settings and align them beforehand.

The team’s process

4.Test the functionality

We started testing at an early stage, from different perspectives.

  • Content: Is the content intact, including things like the number of items, the timestamps and author names, and versions?
  • Settings: Are the settings intact, including for example views, web part pages, permissions and site settings?
  • SharePoint functionality: did the we somehow break the regular SharePoint functionality or does it all still work properly?

We needed to know what the Site Owners and other users would get after the upgrade. Firstly, because the developer was able to fix some issues before the real migration, in his clean-up and upgrade scripting. And secondly, because this allowed us to warn the Site Owners which elements would not transfer well. Fortunately, this pertained only to functionality that very few sites used. For example, the Term Store is not part of the content databases. We left it behind, because nobody really used Managed Metadata.

5.Test the infrastructure

In addition to the functional test of the environment, we also tested how the migration would run on the infrastructure:

  • Disk space. Given the size of the content databases, how much space do we need on the servers? Do we have that space? We didn’t, so we requested additional space.
  • Time. How much time does the migration take on the servers we have? What if we add a server for parallel processing with our clean-up scripts?
  • Snags. What snags do we hit? For example, we found out that we had to install a feature that was no longer used but still referred to from within SharePoint. And we found out that some servers would pause in the middle of the night, if we didn’t take special precautions.

I am very glad we did several test runs, because in our first runs we got nowhere near the finish line  within the planned timeframe of one weekend. And after these tests and subsequent changes, we did manage to finish the migration of the production environment by Sunday afternoon.

6.Create a cookbook and timetable for the team

Especially during our migration weekend, the pressure was on and we worked round the clock to perform our tasks. Some tasks and some transitions between tasks could not be automated easily. So we made them foolproof in our process:

  • Cookbook: We could blindly follow the clear and explicit steps we had written down in our cookbook beforehand, based on our thorough tests.
  • Timetable: The SharePoint developer/architect who devised the technical migration method created an excel sheet with all tasks, with calculated fields indicating when they had to be started. The calculations for the planned times were based on the durations found in our tests, and the calculations for the actual/expected times were based on our progress during the migration weekend. This way, we all knew when we could expect it to be our turn.

Migration timetable

Migration timetable (thank you Macaw colleague Peter Heibrink!)

7.Keep the lines open

Part of our team was in The Netherlands and the others were in India. So we could not get together in a real-life “war room”. So we worked from our homes during that migration weekend, and we kept in touch via digital means:

  • Conversations in Skype for Business. This was our main channel for informal chats and voice calls, to check progress, ask questions, get answers, put forward suggestions and generally encourage each other.
  • An e-mail thread to keep all stakeholders informed when we moved to the next step. They could read the e-mail on their mobile devices – not everybody had to stay glued to their laptops for the entire weekend.
  • A list of emergency phone numbers, so that we knew how to call and wake up key people if anything got stuck.

The most important thing is actually not the digital communication channel, but the willingness of the team members to share their thoughts, to express any doubts or questions they had, and to answer questions. This way, we could really work as one team.

Communication with Site Owners and Users

8.“Beautiful” emails are ignored as spam. Make it functional and personal

We started with an email to all Site Owners. It looked like a newsletter, styled to fit the corporate look & feel. We regretted that decision, when at a later stage we heard that some Site Owners had completely missed the communication. They literally said: “nobody reads those emails in newsletter format.” Oops.

What worked best, were emails that:

  • Have a functional look. No fancy styling, just mail to a colleague.
  • Have a clearly visible key message, in the subject and in the first lines: what is the point, what do we need from you. For example: “Group Sites migration starts Friday May 20 18:00h: Check in the final documents and inform the users”
  • Make it clearly relevant for them personally as much as possible. For example, in the subject of an individual mail we put: “Can we delete the Group Site XYZ?”, when the owner of a big site hadn’t told us if he wanted us to migrate it. This take a lot of time, but did allow us to take some unwieldly sites out of the migration. And when we mailed the new URLs after the migration, we used a mail merge to send every owner a mail with their own name and specific link, highlighted in a clear but ugly yellow.

9.A self-service migration list helps, but you still need to process email replies

We set up a migration site (already in SharePoint 2013), with information about the migration, a discussion list for questions and remarks, and a self-service migration list:

  • Information about each collaboration site collection: In that migration list we put an item for every collaboration site collection, with key information: the main site owners as far as we knew them, the URL, some metadata carried over from the site request list.
  • Fields that we wanted input on: We asked the owners to check the Main Site Owner fields and change the names if needed. We also asked them to switch the status field, to indicate if the site should be migrated or could be deleted.
  • Dynamic views helped the owners and users find the sites relevant for them: filtered by Main Site Owner = [Me], grouped by department, grouped by status.

Within a few days after our initial mail to all site owners, about half of the items in the list had actually been updated by the site owners themselves. That saved us a lot of time and effort! But then again, about a quarter replied by email so that we had to administer their wishes. It was more important to us that we actually get an answer than that this answer was given via our preferred channel, so we thanked them anyway. And the rest had to be chased to elicit any answer at all. Fortunately, we had decided that if we got no response from the owners, we would simply migrate the site to avoid getting into time-consuming fights..

10.Asking the Site Owners if they want to migrate their sites is worth the effort

We contacted the site owners, because we wanted them to take a small part in the migration: make sure their site was ready for migration and inform their users. So we asked them to confirm they were the main site owners we should contact.

Because we were mailing them anyway, we also asked them to tell us if they wanted to migrate their sites. We fully expected everyone to blindly respond that of course their sites had to be migrated, especially because 6 months earlier we had sent out a regular request to delete inactive sites. But lo and behold, it turned out that the site owners said that a full 26% of all collaboration sites could be deleted! That saved us a lot of time during the migration weekend.

May 31, 2014

10 lessons learned about migration training

Filed under: Governance,Office365 — frederique @ 13:52

Over the past months, I have been training users in the basics of Office 365 and on how to get there from their old system. They were using Lotus Notes, so they had to go quite a distance. And they had to take quite a few of the steps themselves, in addition to automated migration steps. I hope the users learned from these training sessions. In any case, I have learned a few lessons.

1. Acknowledge the fact that nobody wants to migrate

IT people and consultants often love to jump to the latest and greatest software. But regular employees are busy doing their jobs. The intranet or digital workplace are just tools for them: they expect these tools to work and don’t want to waste time on them.

So when I started my training sessions, I was in for a lot of grumbling: the Lotus Notes users heard that they not only had to get used to a new tool, but that they also had to spend time on migrating their e-mail.

To ease the pain:

  • I showed how the new tools can make their lives easier,
  • and how they are not so different from the old tools as to force them to relearn everything.
  • I explained what the IT department had done,
  • and what they could do themselves to make the migration take as little of their energy as possible.

2. Don’t make the training mandatory, but strongly encourage people to take action

The goal is not to make people follow the training sessions, but to enable them to migrate and start using the new tools smoothly. Some people need training for that, other can manage without training.

The organisers at first wanted to make the training mandatory, and I am very happy they decided to keep it optional. I do not want to have a group of people in my session who really don’t want to be there…

To help the people who don’t have much time:

  • we also offered short versions of the training at the end of the work day,
  • they had the option to follow a training session via teleconferencing ,
  • we had call to action e-mails and materials that the users could consult in their own time.
  • And when somebody dropped by to tell me they did not have the time for a full session, I could tell them in a few minutes what they absolutely needed to know to avoid problems.

3. Invite the participants explicitly

The employees don’t have time and this has little priority for them, compared to their “real” job. Make it as easy as possible for them to learn about the training sessions and to attend.

When I started with these training sessions, the organisers send the employees who were scheduled to be migrated an e-mail, containing (among a lot of other information) a link to page where they could find a training schedule and then click on another link to register for a training session. Hardly anybody showed up. Attendance was improved a lot, when they also sent meeting invitations to these people.

To make sure people did not miss the training by oversight

  • Send them a personal invitation; don’t just assume they will find it on the intranet.
  • Invite them in such a way that the session ends up in their calendar.

4. Try to get together in the same room, with teleconferencing as a fall-back scenario

It is easiest to check if people understand what you are explaining when you can look them in the eye. And the participants can ask their questions more freely when they are in the same room.

The training sessions we planned were at the participants’ locations. However, they could also join via a teleconference and screensharing via Lync. A few people did take advantage of that option. However, when the discussions became lively in the room, it was hard to follow and participate for the people who had joined us online.

5. Distribute your handout or materials at the beginning

Some people felt a bit overwhelmed by all the new information and all the actions they had to take. They need to be able to consult the information at their leisure. Or at least be reassured that it is there, in case they need it.

So I reassured them right at the start, that they did not have to remember everything I was telling them, because there were plenty of materials to consult afterwards, and plenty of contact points where they could ask their questions. We had created a flyer, which I distributed at the beginning of each session. Whenever I mentioned, for example, the address where they could consult their mail online, I also mentioned where that was printed in the flyer. I saw many people write additional notes or big exclamation marks on their flyer.

  • Put a checklist and instructions in a site, where you can keep them up-to-date if anything changes. Create a Yammer group to discuss the migration to the new tools.
  • Link to that information from the call-to-action e-mails and prominent pages of the intranet, and show it in the training session.
  • Create a hand-out that contains the key information and points to the information in that site.
  • Distribute it at the beginning of each session, so that the participants know what they already have at their disposal.

6. Speak the users’ language, not the corporate language

The main goal in a training session is that the participants understand what is taught and are able to interact in order to learn effectively. Do not assume that everybody speaks English.

I have received feedback from several annoyed users that they were unhappy to receive the official announcements and invitations to the training session in the corporate language: English. Especially at the factories and other locations where “the real work is done”. The corporate language usually only plays well at the corporate head office.

Fortunately, the training sessions themselves took place in the local language: Dutch, French and English in only a few cases, at Head Quarters. So I knew the participants could understand me, and they could readily ask questions and interact in the language they are most comfortable with. And that helped a lot.

6a. Corollary: Speak the users’ language, not IT language

The participants should learn what they should do and what’s in it for them.

Most employees in the company moving towards Office 365 are not in IT and do not want to know which software is doing what on which server to migrate them. Of course there are always some techie people who want to know these details, but you see others glaze over when the talk gets techie.

So I was happy that they IT department was migrated and trained before the others, so that we could have the techie discussions in their sessions without bothering the innocent users.

7. Focus on what is important for the participants

The employees have to assimilate a lot in a migration scenario, while they have little time and less enthusiasm for it.

So we focused on what they needed to know most at that time:

  • What they had to do in the migration to make that run smoothly and successfully
  • The key functionality in the new tools that they would need to know to get back to work after the migration.
  • The main reasons why the new tools would make their lives easier after the migration.

8. Show, don’t tell

People want to see for themselves what will happen in real life, and not just hear the theory of it.

So I showed them how the migration worked in my test mailbox. And I showed them how Office 365 worked, with special attention to functionality that is different from Lotus Notes. Because they could see how it worked in real life, they could also see the benefits for themselves. And we could honestly discuss the drawbacks, so that they knew they would not have to waste time searching for options that were no longer available.

9. Be flexible and interactive

The main advantage of a real-life training session over a set of pages and lists in a site, is that people can ask their questions and discuss their worries.

So I always had room for interaction, between me and the participants but also between the participants themselves. Especially in small groups, we could really focus on the subjects that they were most interested in. For instance, some teams already knew all about Outlook, so we looked at the other tools in Office 365.

10. Take the participants seriously but have fun with the session

No question is stupid. No concern is laughable. But that does not mean that the session should be all solemn and formal.

I liked the sessions to be rather informal, admitting up-front when I had a problem, allowing them to ask any question without being embarrassed by it. I had heard many questions before, so I could reassure them that they were definitely not the only ones struggling.

 

Actually, setting up and giving training sessions is like setting up and running an intranet: it is all about the users and helping them to reach their work goals. As long as we keep in mind that the training sessions and the intranet are not the goals in themselves, but a means to an end, then we’ll be fine…

February 28, 2014

Build it and they will come? Not if they do not adopt it

Filed under: Adoption,Digital Workplace,Governance — Tags: — frederique @ 22:24

Even if you have built a brilliant intranet or digital workplace, the people will not come and use it if they do not know about it, if they do not understand it, or if they do not feel that it is for them. They are all busy doing their jobs and do not want to be bothered by change, especially when they feel it is being forced on them as the latest fad from the IT department.

In a previous blog post I discussed five questions you need to address to get a Sharepoint environment that meets the users’ needs and can be really useful. In this article I focus on the other aspect: given a great tool, what can you do to get people to actually use it? You can start small with low hanging fruit, embed it in your organization and get leadership on board, communicate, involve the employees and find champions, and arrange for support like training and help where needed.

But before I go into details, let me first emphasize that you cannot simply force employees to adopt your system by making it mandatory without making it palatable. If your system does not meet their needs and they don’t feel comfortable with it, they will just find tools elsewhere (like dropbox when they don’t like your SharePoint). Or at some point quit and find an employer that does provide them with a workplace they like…

1. Start small, with low hanging fruit

You don’t have to launch everything that SharePoint has to offer to everybody all at once. People will just feel overwhelmed by all the options thrown at them. Concentrating on what’s in it for the employees:

  • Focus on simple functionality that can help a lot of people. For example, sharing documents and collaborating on them in a team site instead of e-mailing them back and forth and getting lost in the different versions.
  • Focus on eager users who can really benefit and may even be asking for a tool to help them, for example, to share documents with partners or process requests via a simple workflow. When a small team has used the new tool successfully to achieve their goals, you can show that to the others, their enthusiasm can spread and get the vibe going.
  • Focus on key content that many users need or find interesting. For example, HR information and today’s cafeteria menu (in many organization quite popular…). Make sure that content is in place when you go live and make sure that it is maintained afterwards.

2. Embed in the organization: get leadership on board

If the organization’s leadership is not on board, you firstly may run into trouble over funding. And secondly, employees may sit on the fence and wait it out.

This is especially true for the more social aspects of your environment, like discussion groups: some employees hesitate to share their ideas and give feedback in a public forum if they fear that management will disapprove. They need to know their manager will respond with kudos instead of complaints when they write up their discoveries in a blog post on the intranet.

When senior management participates enthusiastically and visibly, especially when they respond constructively to ideas and warnings, the employees will be more likely to stick out their necks and participate too.

3. Communicate, communicate, communicate

If the employees don’t know it’s there, they won’t come and take advantage of the brilliant digital workplace you’ve built. So tell them what you are going to build, what you are building and what you have built, what so cool about it and especially: what’s in it for them. This is not about the technology (although that may be of interest to some technical groups or technical organizations), but about the solutions that will make their jobs easier.

Make a communication plan and determine:

  • What you should communicate to which groups of people. For example, the basic benefits to all employees, productivity gain to managers, ease of site management to site owners.
  • Which channels to use for what: formal news articles on the homepage of your intranet, video, a series of informal blog posts, e-mail to people with special roles like site owners about the changes that will impact them, a few (very few!) e-mails to all employees about what they can expect (linking to intranet articles for more details), paper leaflets and quick reference cards explaining the steps they have to take, posters on the walls showing the benefits, …
  • What you should communicate when. For example, in the beginning tell about the results of the benchmark survey you did on the old environment, before launch explain what they can expect, after launch tell success stories of benefits gained by specific teams and share tips and best practices.

4. Involve the employees and find champions

Communication should not just be you broadcasting your information towards a silent crowd of employees. You also want to hear from them. You will need the input and feedback of the users to get an environment that really meets their needs. And you should make it clear that you are involving the employees, so that they don’t feel like you are trying to force your tool down their throats.

Tools that can help involve the employees include:

  • Serious surveys and quick polls
  • Focus groups
  • Social options in your existing intranet, like comment fields, discussion lists, yammer groups.
  • Just talking to them at the water cooler, coffee machine, or whatever you have…

When you are involving the employees, try to find and engage “champions”: people who can stimulate and help their colleagues to take full advantage to the new tools. These champions do not have to be the management sponsors or “officials” like the HR person or IT person for that part of the organization. It can be anybody who is enthusiastic and savvy about the new tools and willing to share.

So when a user is asking you smart questions about the new intranet, or often contributing to a discussion forum or blog, or contacting you about a team site that they manage and want to improve, or referring others to you for a specific solution, pay attention. These people are very valuable to you as representatives of and pioneers for their community.

5. Arrange for support: training and help where needed

The users may need help to understand the new tools and how to use them to their full potential. Usually, you hope your environment is so user-friendly that innocent end-users do not need training in order to use the basics. But, you’ll still want to arrange for:

  • Training for site owners and other people who need to play a more complex role.
    For instance, site owners who are expected to manage their sites and configure them to meet their users’ needs will probably need some training: how to create and modify lists and views, how to add elements to the homepage of their site, how to give people the right permissions to the right elements.
    Organize classroom training sessions at locations that can be reached, live online training sessions for people who cannot come to such a location, and recordings or other self-paced e-learning materials for people to follow at a later time.
  • A forum where users can share knowledge about the new tool
    For instance, site owners can ask questions and share tips in a Yammer group or community site.
  • Help content for all users, with a ‘Getting started’ page that offers a quick overview of the most interesting functionality and short cuts to, for example, my profile where I can upload my picture and enter my details. For users who want to know more, provide detailed help content.
  • Demo sites with some demo content that show a team site, a project site or a community site, where users can click around to see what such sites could look like
  • Playground sites where everybody can contribute, to see how it works.
  • Intranet team or at least an intranet guy/gel who the users can contact if the need assistance. Guide them to the best solution for the needs of their team, help them fix their site when it is broken, and simply hold their hand until they feel comfortable enough to take charge.

So…

So there are things you can do to help your users adopt the new tools and take advantage of them in their daily work.

  • Don’t wait until you have built everything and then start thinking about adoption. Involve your leadership and your users from the beginning, think about the low hanging fruit so that you are sure that works perfectly, train content owners at an early stage so that the key content is in place before you launch.
  • And then again, don’t stop after you have launched your intranet or digital workplace. Adoption is part of your ongoing governance: you keep monitoring what is needed, aligning with the organization, offering quick wins, communicating, involving the employees and proving support.

Your intranet or digital workplace is a living environment. You’ll need to keep an eye on it, using analytics tools and user feedback, to know how it is performing. You’ll need to feed it with good quality content and improvements, or it will starve. And you and the users need to adopt it and love it, or it will pine away…

January 31, 2014

Install it and they’ll come? Not if it doesn’t meet their needs

Filed under: Adoption,Governance,SharePoint,Usability — frederique @ 16:40

The other day, I talked to someone about their plans to set up SharePoint 2013 in their company. The reason they wanted SharePoint 2013, was that their SharePoint 2010 environment was not used. They had not investigated why it was a failure. But from what he told me, it sounded like the IT department just built SharePoint and assumed that the users would come. And they didn’t.

Ummm, and what makes you think that installing a new version of SharePoint would make any difference?

The only way your SharePoint implementation is going to be a success is if:

  • Firstly, it meets the users’ needs and
  • Secondly, it gets adopted by them.

These things do not happen by themselves; you have to address some serious questions before you start installing and implementing your SharePoint and before you introduce it to the users. Obvious? Apparently not, as this was a real life example of an IT guy who seemed to think he could build it and they would come…

In this article I focus on five big questions that need to be answered so that you end up with a SharePoint environment that can be useful. In the next article, I will address adoption: how you can then get employees to actually use it.

1. What are the goals?

What are you trying to achieve with your environment? Building and introducing a SharePoint environment is not a goal. It is a means to an end, such as enhancing productivity, innovation and employee satisfaction in your organization.

Go into detail. Don’t just state that your goal is “more productivity, period”. Think about the goals of your organization, and what a tool like SharePoint could do to help you achieve these strategic goals.

And keep your eye on the big picture. Don’t aim for a narrow goal like implementing a standard way of working through SharePoint. I have heard that as a goal, and it sounds like you are forcing a tool on people that is solely dedicated to force a way of working on them. A recipe for disaster. You are trying to enable the employees to collaborate effectively and efficiently? Taking advantage of the best practices and recognisability offered by standardization is a way, if done properly. And yes, SharePoint can help with that.

Try to quantify your goals, although this is usually quite difficult. How much do you think you can save by improving productivity? A percentage of time that is no longer wasted and can be spent on other tasks? How many mistakes were made last year, because employees did not follow the standard way of working, that could be avoided? By how much could the number of service requests be reduced, because the employees can now help themselves? If the goal is more employee engagement: are you going to measure it by means of an employee satisfaction survey before and after and the result should be so many points improvement?

2. For who is it?

This ties in with the goals: who will work with the environment to achieve those goals? And don’t answer “Duh, the employees of our organization”. There are different groups of people in your organization, and these people may find themselves in different situations.

  • Is it for the Information Workers who work on a computer in their daily work?
  • Operational workers, like factory workers, who don’t have a company computer?
  • Sales operatives who are on the road all day and use a mobile device?
  • For corporate and local? And do these people all understand the same language?
  • New employees and veterans? Are they newbies or computer savvy?
  • For all departments or specifically for some departments who will benefit the most?
  • Only employees or also external parties like suppliers and partners?

If it’s all of the above for the environment as a whole, the different groups may well use different parts of the environment to fulfill their different needs. For example, the Information Works work on documents together, the factory workers look up procedures and request a shift change during a break, sales operatives align their schedules and share their findings after meeting with a client, the external parties work with employees in very specific projects.

In any case, it is very important to keep in mind who the users will be. Usually, SharePoint is not just for IT-people and not just for corporate people.

3. So what do you implement?

What should you offer these people to allow them to achieve their goals? It’s not enough to answer “Well, we offer them SharePoint”.

Even if you have decided that you will use only standard, out-of-the box SharePoint and don’t want any custom development, you still need to think:

  • What functionality are you going to take out of that standard SharePoint box?
    A portal for company news and information to make sure people are up to speed on the latest developments and official policies? Team sites for collaborating in teams? Document management functionality? Project sites to manage projects? Workflows to streamline processes? Integration with Office? Discussion boards and feeds to share ideas? Incorporating Yammer? Commenting and liking to stimulate feedback? Dynamic, search-based overviews that pull information from different sites?
  • How are you going to configure it so that it is handy for the user?
    Do you need separate sections with special security? Do you tie it all together with shared navigation or do team sites, for example, stand alone? Which elements do you put on the pages? With what views to focus on the most relevant items? Based on which content types equipped with which templates and information policies? And using which metadata to allow for clear structure and pertinent search results?
  • What will it look like?
    If it looks awful, it is a lot more difficult to convince people to spend time in the environment. Do you style SharePoint in alignment with your organisation’s style? Or another style? Can every site owner pick his or her own theme or should it be consistent across the entire environment? Do you create a rich look & feel for communication pages and a clean one for pages where users do their heavy duty work without getting distracted?

4. And are you checking with the stakeholders?

If you are an IT guy or gel, you can try to answer these questions by yourself. But don’t. You are doing this for other people in the organisation, so involve them to increase your chances of ending up with something they’ll like:

  • Are the goals aligned?
    The goals for your SharePoint environment should follow from the goals of your organisation. Does management agree with the goals and audiences you formulated?
  • Did you ask the different groups of users what they think of the old system and what they need?
    What do they hate and love in the previous SharePoint implementation or the other systems that you think of replacing with SharePoint? Did you do a survey, a focus group, interviews? Or at least ask around informally, if it’s a small-scale operation? Did you check the available analytics, to see which pages are visited?
  • Are you asking the different stakeholders what they think of your ideas along the way?
    Do you solicit feedback from users about the functionality you propose? Do you test the usability of the configured site, even if it is just by asking an innocent user to click through a test site and see where they click and what confuses them?

5.How will it be governed after launch?

Ok, you are building a great SharePoint environment that should meet the users’ needs. But will it keep up with real life, or will it fall flat after a while so that the users abandon it? You’ll need a governance plan that answers questions about, for example, Content Lifecycle Management. Don’t postpone thinking about governance until after you’ve launched, because then you may find your configuration at odds with the desired content management strategy, for example:

  • How do you keep the content fresh?
    Who will get the initial content in there in the first place? Who will write new stuff, update information, and delete what is no longer relevant? Do they need a publishing process of drafts, approval and scheduled publishing? Automated information management and what would the rules then be? Analytics to find out what is visited and what is not? These questions will have different answers depending on the type of content: corporate departments manage the organisation-wide information and site owners manage their own team site? In a team site, all members can contribute information?
  • Who will manage the elements?
    Site owners can manage their apps: add things like lists and libraries to their sites, and web parts to their pages? Can anybody create their own site for their team or project, or should they request it? Then who will process the request and what will be their criteria? Who decides a new section should be added to the portal? Who can add terms to the taxonomy?
  • How do you make sure the right people have the right access?
    Site owners manage the users on their own site? Internal and external users? Do you have sections, like a portal, that should be visible to everyone in the organisation? Then who manages that ‘everyone’ group? If you are using Office 365, what kind of licenses do you have and who is managing them?
  • How do you avoid technical disaster and who will fix things when they are broken?
    Do you have planned maintenance on the back-end? Do you have disaster recovery scenarios and are you sure they work?
  • How can users get the help they need to use SharePoint optimally?
    Do you have a helpdesk? A network of local “champions” that stimulate the users and help them out? Do you arrange class-room training, training videos, e-learning modules? Do you have help content? A community site where people can discuss SharePoint best practices?

With this last point about governance, we move towards the other part of making your SharePoint a success: adoption. Once you have launched the tool and arranged for it to stay gleaming and fresh, how can you get people to start using the tool and keep using it? But that is the topic of another article.

Older Posts »

Powered by WordPress