my world of work and user experiences

February 28, 2017

So do we unplug the file shares now?

Filed under: Adoption,SharePoint — frederique @ 23:32

I often see SharePoint environments that exist in parallel to good old file shares. The idea usually is to switch from file shares to SharePoint, because they allow the users to collaborate more effectively and efficiently. However, some users do not want to move away from the file shares. But then again, other users get confused if not everything is moved immediately. I do not have a silver bullet to determine the ideal moment to unplug the file shares. But let us take a look at some considerations, which came up in recent projects.

Switch from file shares to SharePoint

People sometimes ask me why they would stop using files shares and start using SharePoint in one of its incarnations. What’s in it for them? SharePoint sites do offer more functionality for collaborating that file shares. Mosst users can benefit from them, if they adopt them.

And why do I talk about SharePoint sites and not about the newer offerings in Office 365? Because these advantages appear in old school team sites on-premises or new modern team sites in SharePoint online, as well as in the sites associated to Office 365 Groups or Teams. It does not matter, many of the relevant options still live in a version of SharePoint.

SharePoint sites work better than file shares when you need to…

  • Share documents with people outside your organization
    In SharePoint sites, you can only allow externals if the administrators have switched the option on. But I have never had a file share that allowed for external access anyway.
  • Work anytime, anywhere.
    Of course some organizations lock down access without VPN, even in Office 365. But when it lives in SharePoint, your chances are a lot better for accessing information from outside your organization’s network or on a mobile device is a lot easier.
  • Collaborate in a controlled manner
    • Work in a document at the same time with multiple authors
    • Powerful versioning
    • Email notifications when a document is changed
  • Keep track of documents that have more properties than the windows basics
    For example, if documents have an expiry date, owner and a status, you can enrich them with metadata and use those to offer smart views, filtered to display overdue documents owned by my and grouped by status.
  • Work with more than just documents, like action lists, news, links, …
    Classic collaboration entails a lot of documents being exchanged. But the tools allow for more and more different ways to share and keep track of things, especially with the interactive Groups and Teams, including the spiffy Planner.
  • Collaborate on informal notes (for which sites contain a OneNote notebook).

Most of these advantages also apply to OneDrive for Business. OneDrive for Business is the replacement of the personal file share (P-drive or I-Drive or whatever it is called).

Unplug file shares when you switch to SharePoint

You can use file shares and SharePoint sites at the same time, in parallel. But this does cause problems, which you want to avoid by unplugging file shares.

If you have both, it is:

  • Confusing for the users: what do we store where? In an organization where IT did not want to rush the unplugging of the file shares, some users complained that the old file shares ought to be switched off right away. If we are on SharePoint and others still on a file share, how can we find each other? And how can we get used to SharePoint if most of the information is still on a file share? Of course other users panicked at the mere idea of losing their file shares, which is why the IT department took it slow…
  • Costly for IT: storage on file shares is expensive, and you don’t want to spend time and money maintaining two systems.

But look before you leap

Organizations are often eager to unplug the file shares quickly, in order to achieve the desired IT cost savings. However, this can also cause problems.

  • Some files don’t work in SharePoint For example, supersized files or “dangerous” file types (like .exe) cannot be uploaded into SharePoint. Filename with symbols like & have to be changed before they can be uploaded. Connections of connected HTML-files, such as handbooks, can no longer be browsed when they are moved into SharePoint.
  • Is SharePoint really working for the users? Don’t unplug the old file share before the new SharePoint sites can really be used. Not only should the environment be available, but it should also be accessible without hiccups and perform properly. I have hear enough people complain that they did not use SharePoint sites because they are so much slower than the old file shares. Then they are only working theoretically, but not in real life.
  • Have the users been empowered to adopt the SharePoint sites? Do they know they exist? Do they see what the benefits are? Do they understand how they can use them to achieve those benefits? Do they feel confident enough to dare use them? Can they get support?
  • If not:
    • Old school users may revert to older tools If you unplug the file share and they do not see SharePoint sites as a good option, users may go back to sending files back and forth as classic e-mail attachments. Then you may get the IT cost savings, but you will end up with a mess of unmanaged information.
    • Savvy users will find their own tools in Shadow IT Some users love spiffy new apps and tools, and they want to get the job done. So they will just go out there, download this, subscribe to that and join anything else if IT does not provide great tools. I have heard enough users explain that SharePoint sites did not work for them, so they used Dropbox or Google docs or WeTransfer or whatever else instead. This may be just fine, but it may also be a risk if they adopt Shadow IT tools that do not meet the security requirements for example. And don’t think you can prevent this by blacklisting the known tools for file sharing in the cloud. There is always one that the IT official will have missed and that some creative user has found…
  • And transition carefully The best way to transition depends on who you are as an organization, what information you have in the file shares, and what governance rules your information has to obey. Maybe you can move the current information from a file share into a new structure in SharePoint as you go along and leave the rest for a year before you just delete it. Or you can migrate a nicely structured file share into SharePoint using a migration tool. But you should think about it, before you get some garbage-in-garbage-out migration or lose crucial information. And maybe you only have regular office files, without any complications, to which SharePoint is ideally suited. But you should make sure, before users have no other option but to put exotic files onto their C-drive (which may crash) or flash drive (which they may lose) or external storage tool (which may be pirate by who knows whom).

So for some types of files, you may need to keep a file share. For some organizations and some users, a file share may continue to play an important role. But for most organizations, most users and most of the information, it is a good idea to move to SharePoint and unplug the file shares. However, don’t unplug them before you have made sure that the users have adopted the new tool and embraced the new way of working.

January 31, 2017

5 more lessons learned about User Adoption

Filed under: Adoption,Office365 — frederique @ 20:01

Last month I already posted some lessons learned about user adoption. Now I have bumped into a few more things that I want to take into account next time. Some things that worked nicely and that we should repeat and some that offer definite room for improvement….

See the previous post for the other lessons I learned, and here’s the next batch:

1.Get a sense of the users and their needs

Who are the people who are supposed to be using the tools you are trying to get adopted? What do they need? What’s in it for them? Before the tool is bought in the first place, the decision makers should know what it is for. But this information should be known to all stakeholders, in sufficient detail to make it work.

We held intake discussions with all department heads at HQ before we scheduled training sessions with their departments. This worked well: it helped us to determine what these users need and how the tools could help them.

However, what was less clear was how the broader employee groups would be involved: would the logistics people also have access to the tools? The people working in the shops? Or only their managers? Are the tools only for the information workers at headquarters? Or are they for everyone at a later stage? Not only did we not involve those groups, but also we could not answer the questions of the training participants who collaborate, for example, with the people in the shops. And that was a pity.

2.Determine what you want to achieve and make it measurable

Before you start organizing training sessions and other adoption activities, determine what you are trying to achieve: when will the adoption program have been successful? When are the decision makers, the people who pay for the program, happy with the result?

In our program, we kept track of the number of training sessions and the number of people who participated. And we asked the participants to fill in a survey with questions like “Are you going to apply what you learned in your work?” and “Does this training help you to collaborate in a more clever way?” to tell us how they felt about the training sessions and the tools.

However, we did not get enough information to allow the decision makers to decide what should be the next step. And they are still not sure what they want to know before they can make that decision. But is clear that we are not measuring if and to what degree the users are actually benefiting from the new tools, nor what they would need to go to the next level. How about the Office 365 Adoption Pack in Power BI for example (which should become available by the end of March, to see how much the tools are actually used and there is an increase?

3.Organize sessions per team

Sessions per team can work well, because they allow the teams to discuss what would work best for them. One size does not fit all teams, because they do not have the same jobs and they do not have the same needs.

We organized a session per team and we had an intake meeting with the team lead beforehand, to discuss the team’s needs and the most relevant agenda for the session. Then we saw in the sessions that the participants started to brainstorm how they could use the new tools as a team. For example, do their team meeting as a Skype meeting. Put their meeting notes in a OneNote notebook within their joint team site. Some teams loved Skype’s chat functionality, while other loathed it and decided on the spot that they would not use it for now. Fair enough, whatever works for them.

It can be tricky if the team members who share a training sessions have very different levels of Office 365 savviness. We explained the possible tension with the team leaders and they all decided that the team should still all join the sessions, even if some people already knew a lot. The more savvy team members were able to help their colleagues and bring up ideas on how to use the tools. And we had an assistant trainer, who helped out the less savvy team members who got stuck on something that was uninteresting for the others. We were quite happy with the way that worked.

4.Don’t overdose

A training session of 3 hours in which you try to explain everything to users who don’t know anything about the tools yet is not effective. They simply won’t be able to absorb everything… Two sessions of an hour and a half would work better.

We got feedback from the participants that the 3 hour sessions were rather overwhelming. Especially the less savvy team members were struggling to keep up. However, the planners made it clear that it was not possible to plan two short sessions instead of one long session for each team.

So what we tried to do is at least give the participants a sense in what way they could collaborate more effectively and easily using the new tools. And reassure them that nobody expected them to remember everything… If they want to retrieve details that they had missed or forgotten, they can check the help pages and videos we created or ask a colleague. And yes, we got quite a few questions ourselves, via mail, Skype or encounters in the cafeteria.

5.An adoption program is not a one-off activity

A good adoption program is not just one series of training sessions, or one communication campaign. In some cases that might be enough, but don’t count on it.

As I just mentioned, we had planned one series of training sessions.. But quite a few people contacted us afterwards with questions. Some people asked us to explain something again. But most asked for follow-up, now that they had played with the tools in real life. That is when you find out if you have really understood what’s going on: when you try to apply it yourself.

Unfortunately, nothing has been planned officially. We tried to help the users unofficially. But it was frustrating that we were just supposed to provide training, as opposed to help them to adopt the tools to boost their collaboration.


So to a program to increase adoption of Office 365 is helpful. We got enough positive feedback from users to make that clear. However, we can improve on the program and make it even more helpful next time.

November 30, 2016

5 lessons learned about user adoption programmes

Filed under: Adoption — frederique @ 23:03

Currently I am involved in a user adoption programme and there are a few lessons that have become evident. No rocket science, but things that I want to do different next time.

1.Make sure everything works well before you sell it to innocent users

Or at the very least the key features are ready to delight the innocent users. Ok, this sounds obvious, but we had a few missing pieces. Early adopters don’t mind. But innocent users who just want to get their job done and who don’t want to waste time learning something new shouldn’t hit snags.

We had some uphill work explaining Skype for Business but having to help them log on first: the user name is not what you would expect. And then we had to tell them that are not allowed to use it to communicate with people outside the organisation yet. And we decided to stay silent about the new options to attach a file to a mail message as a link to OneDrive, because that will only work when Exchange is integrated.

2.Offer help content before you start training innocent users

Or at least a draft version. Or at least a draft version. When you are in a session explaining new tools to innocent users, they usually ask where they can find the slides or where they can look up the details. After all, we can’t expect them to remember everything and we can’t expect everyone to spend time experimenting.

In our programme, something strange happened to the timeline and we started doing sessions with innocent users before we had any up-to-date help content. One reason is that we planned some fancy help pages and videos and it takes a lot of time to implement them. So now we have just put up some basis help content, like a Frequently Asked Questions list and simple pages for the time being. It is better than nothing until we have the official stuff.

3.Offer some training or getting-to-know-it sessions

Savvy users find out everything out for themselves. But innocent users benefit from a session in which they are told what’s in it for them and shown how it works. Sessions per team can work well, because they allow the teams to discuss what would work best for them. One size does not fit all teams, because they do not have the same work and they do not have the same needs.

We organised a session per team and we had an intake meeting with the team lead before hand, to discuss the team’s needs and the most relevant agenda for the session.

4.Be visible and approachable

One you start introducing new tools and a new way of working, people will have questions. Basic questions for which the answers are in a Frequently Asked Questions list but that some people still prefer to ask in person. And questions about advanced stuff, from enthusiasts want to push the envelope.

We have a mail address for questions and we will have a big ‘help me’ button on the intranet. Between the intake meetings and team sessions, we are present in a central location at their head quarters, wearing t-shirts and hoodies with the ‘Collaborate smarter’ logo. We’ve got a big banner with the logo to flag our location and to lure participants into the sessions. The only problem is that the people who are most visible now are consultants who are only there part time and who will leave after the programme. We need to make some ‘natives’ more visible soon…

5.Plan ahead

An adoption programme does not end after the first series of getting-to-know-it sessions. For one thing, Office 365 changes all the time. For another thing, users want to widen and deepen their knowledge of the tools and of how to use them to do their jobs more effectively and efficiently. How are they doing with the new tools and new insights? Do they need more guidance?

Several people in our sessions have already asked if we will do a follow-up session, to take the next step. In particular, we’ve introduced basic team sites and several team representatives have already asked how they should make the team site do what their team needs. At the moment, this follow-up has not been planned yet, though something will have to be arranged.


So we should improve our user adoption programme. But we do see how important it is to pay attention to user adoption. New tools and new ways of working won’t land properly and won’t yield the desired benefits when we just drop them into the laps of the innocent users.

August 31, 2016

All users are equal…

Filed under: Adoption — frederique @ 20:28

But some are more equal than others. Lately, I have been working in a Functional Management team that supports users, mostly content owners and site owners, in the new intranet. We have a lot to do and never quite enough time to give all of them our full attention. So we have to prioritize.

But is it OK to “play favourites”? Spend time with some users, while others are pointed to a standard help page and told that if they want personal attention, they will have to wait?

Yes, I think that is OK. If we pick our favourites for the right reasons.
Not the people who smile most prettily at us.
Not the people who yell most loudly.
Not automatically the biggest bosses.

We give priority people who are trying to achieve something that will help many end-users a lot.
The content owners publishing key information.
The site owners managing solutions that support important business processes.
The early adoptor users who inspire many colleagues to take advantage of the new options.

I was very pleased to hear Richard Harbridge emphasize this as well in his very interesting webinar titled How to improve Office 365 & SharePoint adoption in the real world: The perception is that we need to support and invest in our users equally. But some users are more impactful than others: 20% of the people are responsible for 80% of the activity on the intranet.

We are not being undemocratic. We are just aiming to get the biggest bang for our buck. And to mix my metaphors: we pick the low hanging fruit, by helping users who only need a small boost to get back on track to rich pickings for the entire community. We don’t have an official champions programma at that organisation (yet…). But unofficially, we know who the champions are. Who makes an impact, who spends a lot of time and energy on the intranet to make such an impact. These people do a lot to make the intranet matter. So we do a lot to help these people.

We are not being undemocratic, we are not being unfriendly, we are just being practical. Because after all, some users are more equal than others.

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 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.

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.


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.


  • 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.


  • 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.


  • 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
determining exactly what solutions I should create with it to allow users to reach their goals
making those solutions so user-friendly that they will get their quickly, easily and without frustration
getting the users up-to-speed with its workings and eager to use the solutions
Ensuring management commitment so that the tool that facilitates key processes is considered key as well.

« Newer Posts

Powered by WordPress