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

June 4, 2016

Surprises from sites and owners in the migration

Filed under: Governance — Tags: — frederique @ 9: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.

October 31, 2013

Popularity trends in your SharePoint Online team site

Filed under: Governance,Office365,SharePoint — frederique @ 23:19

People who provide content or manage sites want to know how much their content or their sites are used. They want to know if it is worth spending time on it. What is used a lot and needs to be maintained carefully. What was supposed to be very useful but turns out not to be visited at all. Based on that information, they can adapt their content management or site management strategy. In short, you need analytics for your intranet governance. Even when you are in the cloud. So how does SharePoint Online 2013 help?

As I mentioned in a previous blog post about the 2010 version of SharePoint Online, we only had an unsupported hack to access some numbers. And that stopped in March, when Microsoft upgraded the back-end of SharePoint Online. In the 2013 version, we have gained visible statistics, though they are very basic.

Still, we have something and it is quite democratic: all users can get some sense of how often content is viewed. Visitors can see how often a document or a page has been viewed, members can see in a library what are the most popular items. The more permissions you have, the larger the scale of the analytics you can consult: site owners can see popularity trends for their sites and site collection owners for the collection as a whole. Just don’t try to drill down and slice & dice by interesting criteria.

Site visitors see how popular individual items are

When they open the item menu “…”, even visitors who only have read permission see how many times the item has been viewed. You don’t see anything displayed there when you are the only one who has visited a newly added document once or twice, but a number appears when the document has been visited more often.

The visitor can see the number of views of the selected document

The visitor can see the number of views of the selected document

In addition, visitors can generate popularity trends reports for pages and files. When the visitor is on a page, he or she can open a Popularity Trends report for that page from the ribbon:

Popularity trends option in the page ribbon

Popularity trends option in the page ribbon

And the visitor can generate a Popularity Trends report for one or more selected document in a library: a tab is opened in Excel for each of the selected documents, and at the top of the sheet you see the name of the item.

Popularity trends for selected documents

Popularity trends for selected documents

This gives you an overview in Excel, in the form of lists and in graphs of the hits on this item over time: on a daily basis over the last two weeks and on a monthly basis over the last three years. So you can see if the item has gained or lost popularity. Or if it has popularity peaks, say, at the end of every month, when the entire team has to go to the selected page to fill out their travel expense report.

In Excel, you can do some manipulations. But what you cannot do is slice & dice by, for example, the country or department where the users are based. Or the page where the users come from when they land here or how much time they spend on this page.

These numbers emphatically do not mention the names of any user or any other personal information about the users. Only the number of visits, regardless of the people involved. That is why these analytics can be made available so widely without any legal privacy concerns.

Site members see the popularity of items in whole libraries

In a library, site members can check the popularity of files via the Most popular items button in the ribbon.
Note: For SharePoint Online, this only available in libraries, including page libraries, NOT in lists.

Site members have a button 'Most popular items' in the library ribbon

Site members have a button ‘Most popular items’ in the library ribbon

This leads to an overview in the form of a search result of

  • Most views, recently (i.e. over the last 14 days) and ever (i.e. since it was uploaded or created in the library)
  • Most views by unique user (the intranet knows of course who the users are, because we are logged on to the system)
  • Most recommendation clicks (based on item-to-item relationships calculated by the system. Maybe this report is not so clear to us, but the search engine also uses these data to calculate the relevance of results. Think “People who viewed this also viewed”.)

Because it is a search result, you can drill down by specifying a search term to find the items you are interested in or by filtering via the refiners on the left hand side.

Result of the most popular items in the library

Result of the most popular items in the library

And then you can look into the details for the item you are interested in, by clicking the Popularity Trends link under it.

Popularity trend over time for the selected item

Popularity trend over time for the selected item

The button says this is about ‘most popular items’, but you can also see what is less popular and that is very interesting as well: if nobody ever reads a document, you should either promote it better or just get rid of it to clean up your site.

Note: Visitors who only have only read permission see the button. But when they clicked on it, they used to get zero views for everything (If it does not work for visitors, it would have been better to grey-out this option for visitors, or they may get the wrong impression). However, when I last tested it, it did seem to work just fine. So maybe the problem has been fixed. Until I am sure about that, I will assume this functionality only really works for users who have edit permissions.

Site owners see aggregated Popularity trends for their sites as a whole

In site settings, site owners have the option Popularity trends.

Popularity trends in the Site Settings

Popularity trends in the Site Settings

When you click on that, you only get one option currently: generate a usage report.

The option to generate a usage report as a site owner.

The option to generate a usage report as a site owner.

And that gives you the usage details for the site as a whole, in the same kind of report that the site members can get for an individual item.

Usage details for the site as a whole

Usage details for the site as a whole

Note: the permission component ‘Create subsite’ needs to be enabled for these site owners. Otherwise they see the option on their site settings page, but it leads to an access request page.
This is rather awkward: in the intranet we built, we want to control site creation, so site owner do not have permission to create their own sites. As a result, they can’t see the usage statistics either…

Site collection owners see an even larger aggregate and search reports

At the level of the site collection, site collection owners have the additional option Popularity and search reports.

Options for the site collection owner: site popularity trends and collection popularity and search resports

Options for the site collection owner: site popularity trends and collection popularity and search resports

From there, you can also open search reports that tell you not just how much the search is used (Number of Queries) but also how it is used (Top Queries, Query Rule Usage) and where it fails (Abandoned Queries, No Result Queries).

Usage reports at the level of the site collection

Usage reports at the level of the site collection

Note: in the large SharePoint Online environment where I often work, we have a separate site collection for Search. We have to go to that collection to see which queries the users started from the portal. The search reports included in the portal collection display “automated” searches for specific content types that we use to roll up information dynamically.

For the aggregate of the search reports over all site collections, go to the SharePoint admin center.

Reports in the SharePoint admin center

Reports in the SharePoint admin center

Conclusion

So am I happy with the analytics options we have at our disposal in SharePoint Online 2013?

Well…. it does not take away the need for a serious third party tool if you want to really monitor what happens with your content.
I’ve read that these analytics were designed to make the search functionality smarter rather than make the content managers work smarter by monitoring usage.  That makes sense from what I see and in particular from what I don’t see: no easy drill-down, no slicing & dicing by type of user (department, country etc), no real-time data, no data about the time of day when anything is used, no information about where users clicked to get here or how long they stay here, what device and browser they use….

But it is better than what we used to have in the SharePoint Online 2010, especially since this spring. Mostly because site owners and content owners can see for themselves if their documents, pages and sites are being used now and over time. It’s a start.

January 31, 2012

Barriers to a successful adoption of the intranet

Filed under: Adoption,Governance — frederique @ 23:08

We’re developing a new intranet at my client. But we know we don’t just need a great system – we’ll also need things like communication and governance to make it a success. So we’ve been looking at the barriers that the users may encounter and how we can overcome them.

Generically, we see the following barriers to a successful adoption of intranet features and the following solutions for it:

  1. Don’t know about it. So:
    • Communication: Intranet, local communication vehicles, announcement mailing
    • Getting started kit: show and tell what’s available, in the site and outside (flyer, QRC)
    • Champions: drive adoption
  2. Cannot access it. So:
    • Opens by default in browser
    • Simple URL: redirect if technical url too hard
    • Invitation: get account data on Day 1 (user management)
    • Support for forgotten account data (ongoing user management)
  3. Don’t understand how to use it, afraid to mess up. So:
    • User friendly site
    • Help content, link to help and handy navigation + search within help
    • Policies
    • Training of contributors of News, Blogs and Files
    • Support in case you get stuck
  4. I see nothing relevant here. So:
    • Make sure the site works (incl good performance)
    • Relevant content at the start
    • Ongoing relevant content (content governance)
    • Releases of relevant new features
  5. Not worth the effort to contribute, what’s in it for me. So:
    • Incentives (recognition, games, gadgets,..)
    • Management commitment: it’s part of your job
  6. Disappointed in the lack of response. So:
    • Set an example (e.g. HR)
    • Champions make extra effort
  7. No time for it. So:
    • Management commitment to make time for it
  8. Afraid to stick out their neck. So:
    • Set an example (e.g. HR)
    • Open culture where management encourages contributions actively

August 31, 2011

Duds – Why do some solutions fail?

Filed under: Adoption,Governance,Usability — frederique @ 23:56

I’ve been developing small-scale information worker solutions for the same company for a few years now. Different departments and teams needed different solutions to solve their problems in the domain of communication, collaboration and the optimization of business processes. And because I am still here, some time after we’ve launched the solution, I can see where it all led.

Well…

On the one hand, some solutions are still a great success, helping the teams to increase productivity and quality, and reduce cost and frustration.

On the other hand, other solutions completely fell flat. They have never been used for real, and got swept out ignominiously as a dead site by the house-keeping team.

What went wrong with those duds? It’s not always clear, but these seem to be important negative factors.

Solving no problem.
We create a solution – in my case usually specific functionality in a teamsite – to solve a problem. We identify that problem in the beginning, with a rough business case. However, sometimes an expected problem does not actually arise. So the solution is sitting there in a vacuum, solving nothing of substance.

An example that I encountered recently, was a solution for issue tracking in a high profile project. When I asked after a few weeks why I did not see any issues in the tool, the answer was that there were no issues so far…
Maybe I should see that solution as an insurance policy: you hope you don’t need it, but you make sure it’s there just in case your house burns down or – in this case – the project gets swamped with issues. Unfortunately, I fear they did find issues later on. By then, original project leader had left, probably nobody remembered that they had this tracking tool and they solved the problem some other way.

So: If you create a solution for a problem that hasn’t arisen yet:

  • Double-check that they need the insurance.
  • Keep it as simple as possible, to avoid wasting too much time.
  • Make sure the team know about the solution, so that they can start using it as soon as the problem does arise.

Functionality insufficient
We do our best to create a solution that meets the users’ needs. But sometimes the result just isn’t good enough. In my case, the available platform and toolkit definitely limit what I can create. In other cases, the technology may be up to it, but the budget it too restricted to get the job done.

An example that I won’t forget in a hurry is a sales tool for a Russian team. We knew from the beginning that we were pushing the envelope. But as the project progressed, it became clear that it just wouldn’t work. The American third party tool didn’t understand the Russian date format. The client became more emphatic that his huge amounts of data needed to be connected in multiple ways. And there just was no way that we could solve the problems in a reliable way. In the end, even the parts of the tool that did work, were never used and the entire solution was deleted in our last spring cleaning campaign.

So:

  • Identify the full extent of the client’s needs at the beginning of the project, especially complex showstoppers.
  • Double-check that you have grasped the essence and that you have a solution, especially if there are further complications, like a language barrier (I don’t speak Russian any better than that third party tool that got stuck on the date format…).
  • If there is no good solution, cut your losses and stop the project. Launching an inadequate, unstable solution will only make your life harder, when they call you to save them when it collapses.

Usability insufficient
Our solutions are created to help employees be more productive, or more generally: help the users reach their goals. That will only work, if the solution is user-friendly: if the users can do their job quickly, easily and pleasantly.

With on a fixed, old platform, usability of any of its solution is sub-optimal, to say the least. For instance, readers see an Edit button and only discover they do not have the required permission when they try to save the item and all their content is gone. And when contributors enter metadata, there is no connection between the data they enter. So if they first select a country and then a city, the selection list of cities is not pe-filtered. Stupid system…

However, sometimes a solution is not user friendly just because it is an IT system, regardless of its “objective” usability. I’ve sat next to users who told me “No no no, this is just too difficult for me“, until I pointed out that – basically – they just had to click the prominent button ‘Upload document’ to upload a document. “Hm, that’s actually quite easy”. Such users don’t feel friendly towards any new system, because it always takes some energy to check out something new, and they don’t see it as their core business. But that has more to do with user adoption driven by management commitment.

So: optimize usability as far as possible

  • Determine who the user groups are and what they need, and cater for their needs specifically. For example, remove the Edit buttons from pages that are mostly visited by readers who cannot use them anyway.
  • Test this with real users, even if it is very informally: just drop by and see what they do. I see a lot of interesting things when visit my less intranet-savvy contacts. They sometimes click in very unexpected places…
  • If you can’t use technology to make things clear and the fixed styles don’t give you any help, be as clear as you can in text and sorting:
    Include the right words in title bars, link texts, explanatory texts, document titles.
    Order the content in such a way that the information that is most important to most users is at the top of the page, at the very least above the fold: most recent documents, my tasks, key links, etc

User adoption insufficient
A solution can be set up brilliantly, if the users don’t use it, it is still a dud. Of course none of the solutions I created were absolutely flawless. But I have seen good solutions ignored for other reasons.

One of the solutions where we really made a huge effort to make it as functionally useful and user-friendly as possible, is a program management tool. The project teams of the individual projects should update the project status and other key indicators in the tool, so that all participants can monitor the program’s progress and the program managers can intervene where needed. But most project leads just don’t do it. The tool is not that difficult to use. But determining the status and key indicators of the project is difficult. So they are very reluctant to adopt the process itself, let alone the tool they can use to facilitate that process.

Another example I’ve just encountered, concerns a very savvy project lead, who is definitely able to handle both the process and the solution he could use to make that process more efficient. But he insists on using some “old fashioned” solution that he has always used and that he is completely fluent with. Except that it is rather unpractical for collaboration with the other stakeholders. In this case, the main obstacle for adoption is probably the ‘Not Invented Here’ syndrome.

So:

  • First of all, the users need to understand how it all works. Ensure that the users know what the business process is and how to handle that. And then how the solution can help them with it and how to use it exactly. So provide training and help material, both concise (FAQ, quick reference) and more detailed (user manual, help pages). Even if they don’t consult the material, many users feel more secure in the knowledge that it is available if they need it.
  • Communicate not only theoretical knowledge to the users, but also a clear sense of what’s in it for them: how will this make their life easier (saving them time and effort) or richer (informing them better than before).
  • Is this an important business process? Then using the tool to make that process flow more efficiently is a core task for the participants, and not just something they can ignore. This implies that management commitment is needed and the managers need to act upon their commitment.

Management commitment insufficient
In the context of intranets, the goals that the employees are trying to achieve – with or without using one of our solutions – fall under the responsibility of a manager. If the manager feels that the goals will be achieved more effectively and efficiently using a tool, they can ask us to develop such a solution. But then the managers are also responsible for the adoption, usage and maintenance of that solution, even if they delegate the actual work to another employee. However, I’ve seen quite a few solutions fail because of a lack of management commitment.

For several solutions, including what was supposed to be an important tool to aid marketing strategies, my contact for the entire project was an intern or another temporary employee. I knew the names of the responsible managers, but I never got any input or feedback or questions from them. So when the temporary employee left, the entire project just stopped.
That marketing tool was almost finished two months ago, and it still is almost finished. An HR site was almost finished two years ago, and it is still gathering dust without any further progress. The positive only example was the HR site for another country, where the intern managed to launch the site before he left. That is a rather static information site, so it does not matter as much that it has not changed since then, because at least the information is available for the readers.

In some other projects, the managers were personally involved, but the solutions still failed, because the managers did not see them through. In one case, the most eager sponsor left the company. The other one had very little time, as complications within the organisation distracted her. I noticed that she lost her enthusiasm for the project, but I was unable to re-energize her. The fact that she was in Australia and I was in The Netherlands played a role: we could only have a real time conversation in the hour after my midnight and at the start of her work day. That solution had cost us a lot of effort and was ready for launch, But it was never used and flushed out in our last spring cleaning.

So:

  • Don’t do a project with an intern without on-going involvement from the responsible manager. If they won’t do more than just give the order to develop a solution, then it apparently is not important enough.
  • Get more explicit and well-founded Go/No Go decisions: Is the problem that we are trying to solve still serious? Do you still think you can achieve the benefits? Can we take a sprint to finish the solution with a burst of energy? Or should we just stop wasting time on something that is just bleeding to death?.
  • Make it clear that they need to invest some time now, in order to save a lot of time later, when the solution allows them and their team to work more efficiently.

Most of these reasons for duds to fall flat don’t have anything to do with technology, but with people. So getting a cool new toolkit is not going to help me get more solutions up in the air and soaring to great heights. It’s

getting a cool new toolkit
AND
determining exactly what solutions I should create with it to allow users to reach their goals
AND
making those solutions so user-friendly that they will get their quickly, easily and without frustration
AND
getting the users up-to-speed with its workings and eager to use the solutions
AND
Ensuring management commitment so that the tool that facilitates key processes is considered key as well.

February 28, 2011

Exploring intranet governance

Filed under: Governance — frederique @ 2:30

When we build an intranet, collaboration environment or any other system, we don’t just want it to look good when we launch it. Cracking open the bottle of champagne on the bow of our gleaming new intranet is one thing. But what happens once she has set sail and is navigating the shoals of real life usage?

We’ve build the intranet – or whatever other system we built – to achieve a goal: to increase productivity and employee satisfaction, be compliant with legal rules, save money by saving time, travel and paperwork …
Therefore we firstly have to build the intranet in such a way that it can reach that goal: it needs a steering wheel, a compass, streamlining, a good engine or sails, or it won’t be able to get anywhere. It needs to be governable.
And secondly we have to set up processes  and organizational structures  to direct the intranet: who takes the wheel, where will we navigate, who takes care of the engines, anybody watching out for icebergs in the middle of the night? It needs governance.

Let me explore some aspects of an intranet, what we launched, what can go wrong afterwards and how we can govern that.


What does the intranet offer the user: functionality

In our development project

Issues after launch

Governance needed, such as…

Required: We determined what functionality was needed and made sure that worked when we launched it

Is it all still working?

Find out: Set up a contact for users to report issues
(please note: users don’t know if something actually is a bug in the intranet. They just see that it is not working as they expected)

Decide and plan: Appoint an intranet management person or team who prioritizes big issues.

Do it: Set up tech support who fixes bugs

Understandable: We made everything as user-friendly as possible and included Help and training in the launched intranet.

Do the users know what they can do and how to do it?
Is it really as understandable as it is supposed to be?

Find out: Appoint champions and set up a helpdesk who can answer the users’ questions, and let them capture the questions. Conduct usability tests.

Decide and plan: Determine who is responsible for help and training. Make a communication plan and training plan, and guidelines for the help and training content.

Do it: The champions and helpdesk answer the questions. An editor (role) updates and adds to the help and training content. A trainer gives real life training, remotely or in class. A communicator points out interesting functionality in blogs, newsletters etc.

We may have postponed part of the functionality to a later phase, or we may have missed something that turns out to be important.

Is something important missing, at the highest level, for all users?

Find out: Conduct user research. The helpdesk and champions know what is asked or complained about.

Decide and plan: The intranet owner / steering committee decides at a high level what major changes or additions will be carried out, in a release planning. A general guideline is that it has to fit the vision and current functionality of the intranet, and it has to be done with the standard development method.

Do it: A development team does a project for this.

 

Is something missing at a lower level (e.g the level of a teamsite) for a small group of users?

Find out: These users request a functional solution.

Decide and plan: A solutions manager decides, based on a business case. Guidelines: For this, stick to no code solutions that do not need anyone directly on the server. And follow the best practices that have been established for such solutions on this intranet.

Do it: A business solutions team carries out the project at the front end.

 

Is the current functionality still relevant?

Find out:Statistics and user research.

Decide and plan: The day-to-day intranet manager or the high level intranet owner (depending on the importance) decide what can be removed or made less prominent.

Do it: A tech support or functional support team carries out the change.


What does the intranet offer the users: content

In our development project

Issues after launch

Governance needed

On launch, the intranet does not have that much content yet. The contributors add that later.

Is the relevant content available and up-to-date?

Find out: Allow the user to contact the owner of the section where content is missing or outdated (by clicking a button or by calling the listed contact person). Periodically check the most important content. Check the search statistics for missing content.

Decide and plan: Determine who owns the content, in particular important central content, who is allowed to add or edit it, and which content requires approval by whom. This very much depends on the content and the section of the intranet. Is anyone supervising at a higher level, via a reminder and escalation mechanism?

Do it: Editiorial teams for central content (such as corporate news, HR info). Give enough people contributor permission.

Is the new content readable?

Find out: Allow the users to give feedback via a rating system. Conduct research.

Decide and plan: The authors and editorial teams are responsible for their own content. Is there some overall editorial board that checks the quality of the content? The authors get guidelines for writing on the intranet.

Do it: The authors and editiorial teams make sure their content is readable, by following the guidelines and using tools like a spell checker, wysisyg layout editors, Flesch readability index etc.

Records management: records are a special case. We may have included special functionality like automated document ID and policy management when we built for compliance

In practice, are the records created and managed according to the rules?

Find out: Records owners or managers will have to check before the auditor arrives.

Decide and plan: A records management plan guides the record manager – in general or for a specific domain .

Do it: Check and perform the tasks that the automated routing, archiving and disposal actions generate.


What does the intranet offer the users: team sites

In our development project

Issues after launch

Governance needed

We work with SharePoint and that allows the users to create new sites after the launch, without involving a developer. We provide templates for that.

Is the new site necessary or is there already a site available for that purpose?

Does the new team site fit the rest of the intranet /collaboration environment?

Find out: Let users request a new site instead of directly create it. Check if it is necessary.

Decide and plan: Make a Content Lifecycle Management (CLM) plan. The day-to-day intranet management team approves the request, following the CLM plan. The owner of the new site then has to adhere to the guidelines or best practices for site use.

Do it: Create sites automatically from the selected template after the request has been approved. The new site owner configures the site to fit the needs of his team, adhering to the guidelines. The day-to-day intranet management teams monitors this.

Is the site still relevant, or is it just cluttering up the intranet?

Find out: Periodic automated check for sites that have nog been used a specified period (e.g. 6 months).

Decide and plan: A house keeping plan that allows the day-to-day intranet team to do these checks, and to deal with exceptions.

Do it: For example, the day-to-day intranet management team every 6 months gets a list of ‘dead sites’, contacts the site owners and delete sites that are not explicitly said to be still useful.


How do they find it: findability

In our development project

Issues after launch

Governance needed

It only makes sense to offer the users anything if they can find it. So in the development project, we paid serious attention to the findability

Can the users really find the functionality and content?

Find out: Conduct user research and check the statistics (If a site that we think is important never gets visited, the reason may be that the users cannot find it. Or it is just not that important after all).

Decide and plan: The intranet owner is ultimately responsible for the findability. The could ask the day-to-day intranet management team or a specific “findability expert” to monitor and fix it.

Do it: Who does what to improve the findability depends on the solution for the problem.It should, as much as possible, be something that can be done at the front-end, by non-developers.


How do they find it: information architecture

In our development project

Issues after launch

Governance needed

During development we’ve designed and implemented a good, user-friendly IA: a clear and efficient structure where the most important items are most prominent and everything fits in a category that makes sense.

Do new items (sites, articles, functionality) fit in the information architecture?
Does the information architecture still fit reality (naming, structure)? For instance, elements that reflect the organisational structure are no longer correct after a reorganisation. New k knowledge domains or products need to be added.

Find out: Conduct user research to check for clarity. Check if people who add items know where to put them. Keep an eye on developements in the organisation.

Decide and plan: The intranet owner decides on major changes or additions in the (portal) structure. The could ask the day-to-day intranet management team or a specific “findability expert” to monitor and fix it.

Do it: Who does what to improve the findability depends on the solution for the problem.It should, as much as possible, be something that can be done at the front-end, by non-developers.


How do they find it: search

In our development project

Issues after launch

Governance needed

We provide the search functionality when we launch the intranet.

Can users (still) find what they are looking for using the search functionality?

Find out: Conduct user research and check the search statistics.

Decide and plan: So do we have a “findability expert” or search manager who monitor and fix the search settings?

Do it: The search experts add and update the keywords in the taxonomy, and maybe tweak the relevance criteria of the search engine.


How do they find it: taxonomy

In our development project

Issues after launch

Governance needed

The taxonomy is the basis for the information architecture and the search keyword. We launch the intranet with a basic taxonomy for the main navigation and, sometimes, with the main keywords for the search.

Are terms missing from the taxonomy?
Do the terms in the taxonomy correspond with the reality of the users, or do we need changes or additional synonyms?
Is the hierarchy correct or do we need to reorganise the terms?

Find out: Conduct user research and check the search statistics.

Decide and plan: We allow an uncontrolled folksonomy in the intranet or in some specific sections of it, but somebody needs to be the owner of the official taxonomy: the “findability expert” and utlimately the intranet owner for high level decisions. We need a plan lay down which changes can be approved and carried out by who.

Do it: In SharePoint 2010 you can change the taxonomy in the Central Admin, and promote terms from the folksonomy to the taxonomy.


How do they experience it: stability and performance

In our development project

Issues after launch

Governance needed

In our development project, we have chosen a technical architecture that ensures stability and performance.

Is the intranet still as stable and fast as it was when it was launched, now that it has filled up with content and users?
Users refuse to work with an intranet that is too slow or unstable.

Find out: Check the user complaints and perform objective measurements.

Decide and plan: The Service Level Agreement (SLA) with the hosting party specifies what is acceptable.

Do it: The tech support team handles the servers, but the functional support people can also optimize the configuration of bottlenecks in solutions. Site owners have to take care of their own sites, guided by best practices about performance killers.


How do they experience it: look & feel

In our development project

Issues after launch

Governance needed

When we developed the intranet, we branded it properly and created the appropriate styles and templates.

Are the (new) content and sites (still) branded correctly?

Find out: Check the sites, especially important central content.

Decide and plan: Document what is allowed in which section of the intranet in a styleguide. The day-to-day intranet management team can enforce compliance, if site owners do not adhere to the styleguide. Or is that a job for the marketing & communication team?

Do it: Stick to the predefined styles and templates. Give the site owners a styleguide and material like images that they can use.

January 31, 2011

Why governance? Some thoughts

Filed under: Governance — frederique @ 22:57

Lately we have been discussing governance in our Colleagues Club (mostly with people like Jason Sindram, Willem Oosterhof, Mike Fortgens and Maarten van den Dungen). The funny thing is that we notice that many others see governance as bureaucracy for the sake of bureaucracy. Yes, the term does sound a bit pompous. But that does not mean that governance is useless.

Instead of diving into the exact definition of the term and the meaning of governance, let me just address a few issues I’ve recently encountered in my projects.  Most of these actually turned out quite well, because we do have governance in place. I’m working in intranets these days, so that is what I focus on.

  • “Aha, we can just upload those documents? Cool!”
    The HR department in one of the countries of our multinational still hasn’t put any of its information on the intranet, although the intranet has been available for more than five years. Today I had a meeting with the trainee they delegated to find out if they could actually upload documents into this intranet thingy and avoid all these phone calls from employees looking for information. Well, yes…. And not just upload them, but also update them when the information changes, which it will certainly do.
    Seasoned intranetters and intranet developers hardly believe it. But unfortunately, the intuitive interface and the available materials are not enough to help all users understand what’s the use of the intranet and how to get the most value out of it. Fortunately we do have a team that they can contact if they want to know more. And this team has a communication specialist, although apparently she hasn’t reached everybody yet.
  • “So how do I upload a document again?”
    Some users had found out that I could help them and responded by phoning me for any button click they hesitated about. Very sociable, but highly inefficient for me.
    Fortunately I could point them specifically to the live training sessions we organize, the quick reference cards and the rest of the Help Center. RTFM…
  • “No we cannot risk losing this information!”
    One of the team sites had grown far beyond the official size limit. At that size, we could not guarantee that a back-up of that site could be restored properly. And this site contained important documents and process information that the company has to safeguard for legal reasons.
    Fortunately, the Portal Management Team does regular housekeeping sessions to check for overweight sites. So they became aware of this and we secured the information before any accidents happened.
  • “My colleague has already set up a site for that?”
    The Europeans and the Americans in the multinational both came up with the idea to create a site for the standards for efficiency. Do these need to be separate? Or can they join forces or at least connect to each other?
    Fortunately, we have Content Life Cycle Management in place for team sites. The users cannot directly create a new teamsite, but they request one. The intranet team checks if the site would not be redundant with another site and if the requester has picked the right template before they create the site. Also, we regularly check for ‘dead sites’, where nothing has happened for ages and that just clutter up the intranet.
  • “But the big photo I put on the homepage looks great”
    I regularly see team site homepages torn apart by overlarge images or other content that literally pushes the limits of the page. Usually the creative site owner has designed the page on a large screen, without realizing that the innocent user with his 1024×768 screen gets terrible scrollbars and an unreadable page.
    Fortunately, we have a team that can intervene and tell – or even help – the site owner to fix this. And we have a help center and a best practices blog that give the site owner information and tips on how to do this.
  • “Can we get a team site that really facilitates our request process?”
    Many teams in the organisation have processes in place, for requests for example. And they need something to deal with those in a more efficient, reliable and systematic way than just sending some e-mails and picking up the phone.  Their needs were not catered for in the intranet as we originally set it up. But now we can give them a tool tailored for their process.
    Fortunately we have a Solutions team that can create solutions for collaboration, processing or information sharing problems for which a standard team site template is not enough. This team does not develop code that needs to be rolled-out to the server. But you can do a lot on the front end with SharePoint and some third party tools. We don’t just go ahead and start configuring, but we set up a simple project, based on a business case, and we start by analysing their needs and determining what features would meet those needs.
  • “Intranet not available? Waaaaa!!!”
    A few weeks ago, I could not use the intranet in our office building due to a technical failure. It was hopeless, I could not get any work done there. So I went to the other office complex – 30 minutes of cycling – where to my relief the intranet was available.
    Fortunately we do have a technical support team that fixes the intranet as soon as possible when it breaks.

With an intranet – or another site – it is not enough to build the system and then just toss it at the users and hope for the best. Why? Because we have set up the intranet to achieve some purpose – like increased productivity of our information workers . And it can only achieve and keep achieving that purpose if we manage it properly.

  • Intranet = ‘living system
    Our intranet is not a book that we write, send to the printers and then it is finished. The intranet is meant to evolve with the latest content, with our organization itself and with the latest insights. Otherwise we should just print the company handbook and have done with it. But this living system will not necessarily grow in the right direction, if we don’t water it, fertilize it and prune it where needed.
  • Intranet = open
    Modern intranets are not filled by a small editorial team. The intranet is more lively and certainly more useful if all users can contribute something somewhere and if many users can add lists, design pages and perform other decentralized site management tasks. This can get completely out of hand, if we don’t give some directions and lock down the really sensitive parts.
  • Intranet = indispensable
    We cannot risk our intranet getting completely out of hand, because it is indispensable for our company, as a collaboration platform for our knowledge workers, and a self-service tool and an information source for all employees. So we’d better make sure our intranet remains in peak condition, up-to-date, fully functional and meeting our latest needs.

So just set up some governance to make sure your intranet reaches its full potential and keeps making your and your users’ lives better…

Older Posts »

Powered by WordPress