Document your deviations

Documentation-Dude

When we were designing the new SharePoint intranet, some things needed (?) to be customized. And you know I am a big fan of custom functionality. (NOT)

  • Formal Publishing sites needed to resemble our internet site (I have always wondered why people think that is a good idea)
  • Collaboration Team sites home pages showed the security classification of the content, the audience and the site owner. (Useful! If applied correctly…)
  • We added another permissions level to avoid site owners creating subsites.
  • The document content types had 20 fields of hidden metadata in them, as per our term store. This was to improve the search experience – after all, in a 40.000 employee company with many locations, a few metadata would be most helpful to find the document from the correct business, function or location.

Dude, where’s my documentation?

So, when the intranet was ready to launch, and support was handed over to the regular support team, the Support team manager asked the developers for all the documentation.
It was not there and they had not planned for it. Against the advice of Veronique Palmer, he accepted this as a fact and support was handed over to the support team. After all, one of the developers was in-house so we could always turn to him.

Or so we thought, as he left the organization shortly after launch of the intranet…

Support

Support mostly went OK as the majority of issues had to do with permissions.
But when the content types started to show issues we had no clue where to go for help, so we ended up installing the regular content types. Nobody wanted to complete 20 metadata fields for each document!
And when the organization changed structure, the metadata changed as well and nobody knew where to make the changes in the content types.

What to document?

So, while I agree with everyone that too much documentation is a waste of time and effort, it DOES make sense to document:

  • Any custom functionality. What is the customization supposed to do? What are the specific settings? Is this set by tenant, site collection, or site? Where are the settings to install and implement it? What can go wrong? What NOT to do (for the admins and the users)? Where to go when support people or architects need to look, change or troubleshoot? Etc.
  • Anything that is on the roadmap to be improved after the MVP-state. What does it do now? Into which direction will improvements most likely go? Where and how to make those changes? What to look out for? What will break and will need to be fixed when you make those improvements?
  • Anything that can be expected to need adjustments with organizational change. And trust me, organizational change will happen! The company’s name, the company’s logo, the businesses, there may even be splits, mergers or acquisitions on the horizon. So, make clear where your intranet logo and images live, what effect changing terms in the term store will do to your customizations, and where you need to make the necessary changes to make sure the organizational changes are reflected correctly.

This post was created after reading Gregory Zelfond’s recent post about implementing SharePoint in large organizations, which made me chuckle with recognition 🙂
Then Veronique Palmer commented with things you should document, so I thought I would give a real-life example.

Any other experiences or suggestions for documentation?

Developer image courtesy of lemonade at FreeDigitalPhotos.net

Advertisements

Reaching beyond the usual suspects

IntranetNowBlogheaderOn October 5 I participated in IntranetNow in London. I presented there, and thought it would be nice to create a write-up in my blog, with some images from my presentation. If you prefer the PowerPoint variety, please check out my presentation on the IntranetNow SlideShare.

What brought this on?

Recently we introduced a new intranet (Publishing and team sites) to the organization.

Blog-changes
A overview of the old (left) and the new situation (right). Lots of changes!

We went from a SharePoint 2007 environment on-prem, to SharePoint Online in the cloud. That alone was a big change.

Our old platform was created 10 years before, when the organization was still very decentralized, and people could do on the platform whatever they wanted (which they did) as long as they did not break it (which they did…sometimes 🙂 ).
The new intranet is strictly governed, as there is now a strong central Security and Compliance team, strong Enterprise Architecture, many Governance Boards and Steering Committees and of course our new landlord Microsoft, and they all tell us what people can do and what not.

Additionally, we went from being one large company to two companies and we reorganized as well.

Challenges

We knew we were going to make a big change, so we secured the help of our “usual suspects”, a small group of people active on Yammer, and a small group of active content owners. They kindly agreed to be our Champions, helping us launch the new intranet to their circles of influence.

However, many of them left the organization during the project, or moved to another job, due to the reorganizations. So we were left with an even smaller group of “usual suspects”.

We tried to make up for it by increasing the communications:

  • Yammer messages and YamJams
  • News articles and Newsletters
  • Webinars with demos and question time
  • Local sessions to inform people
  • Emails to site owners
  • Creating training

But well, you know how it goes:

  • People do not always read or act upon communications
  • People only learn when they have a need, so many people left the learning until they had their new intranet and their new site(s).

So despite our efforts, this is more or less how people reacted when they saw their new tools for the first time:

Chaos wallpaper2.png
Sadly I do not know the creator of this wonderful image, but I have used it anyway since it is the best I could find to depict the response of the audience…

People were confused, did not know where to find their content, how to manage their sites, how to navigate, etc.

Action needed!

Well, if you want to implement a new effective digital workplace, this may not be the best response. So we introduced a new role into the organization: the Adoption Consultant. It is their role to make sure that employees

  • know what the DW is,
  • can use it to their advantage
  • and like it, so they will promote it and help others use it

Within this organization, the DW consists of the Office 365 suite plus a few other tools available for all employees.

So we are currently embedding this process into the organization:

Blog-cycle
The Process

  • There is a UX manager who runs a survey with 1/12 of employees every month, asking for user feedback about all IT tools and services.
    There are other sources for feedback (Yammer, support tickets, etc.) but the survey is the most formal one.
  • He turns the responses into usable data and insights.
  • If something relates to the Digital Workplace, he asks the Adoption Consultants to help with it. They determine which remediation actions need to be taken.
    New functionality will also be handled by the Adoption Consultants, as some projects have the objective to “get the software installed on people’s machines” without thinking beyond that point…
    So they think about whether extensive communication and training sessions are needed, or if a link to the help materials of the vendor is sufficient, or anything in between.
  • By implementing those actions it is expected that the complaints and remarks about this topic will be reduced.

Yeah, interesting picture, but what does that mean in practice?

Users: “I can not find anything on the intranet”

UX Manager: “We have found that “I can not find anything on the intranet” is in the Top 3 of complaints for the past months. Adoption Consultants, would you please look into this”?

Adoption Consultants:  “What does it mean exactly, “I can not find information on the intranet”? Do people not know how to search? Are they looking for information that is not there? Do they not know how to navigate?”
* arrange interviews with a selection of complainers*

Adoption Consultant: After some discussions I think

  • We will need to create a campaign to inform people about the options available in Search.
  • We need to suggest to this department that they properly archive their outdated procedures and provide more meaningful and descriptive titles and tagging for their current content.
  • We need to discuss federating SharePoint Search, as some people appear to be looking for content which lives in our IT service system.

What else have we done so far?

  • We have given “Digital Workplace roadshows” in various locations across the world, explaining what the Digital Workplace is and how people can best use it. These have been received really well.
  • We have started a campaign about the different options of Search, update your profile, etc.
  • We manage a “Digital Workplace” group on Yammer as THE place for discussion. This is really well-used and popular.
  • We have created procedures to communicate consistently about projects that bring new functionality to the organization, using consistent channels (such as that Yammer group).
  • We are working with local focal points as they know more about their specific situation.

What are the results?

As we have only started this role last July, we have not accomplished a reduction in unfavourable feedback from the employee survey. But we have achieved a few things:

  1. Through the roadshows, we have met a number of new enthusiastic content owners, willing to help their circle of influence with the new Digital Workplace
  2. Interviews with colleagues who responded in the survey have revealed unexpected and useful feedback.

And that survey…we will do our best to improve the results over time!

Using Yammer for a business process

YammerWe tend to think of Yammer as an optional communication and collaboration channel, where you can discuss topics and share information with and ask questions to all your colleagues, independent of where they are in the organization or on the globe.

But Yammer can also be used as part of a business process.

I recently talked to a Retail Sales organization that has been using Yammer for several years for a number of business processes.

1. Sharing information about customers.

A Yammer group has been created for each major customer.

Sales people visit shops, shop managers and customer head offices.
If they see empty shelves where their product should have been, incorrectly priced products, packaging with peeling labels, a nice display idea from a competitor, or anything else they find remarkable, they take a picture and upload that to the Yammer group with their comments.
This way they share it immediately with colleagues and the back-office, and the back-office can take instant action if necessary.
(For long-time readers, this is very similar to the process we had to facilitate with a Team Site as Yammer was at that time not an approved tool within that company)

YammerBus-Nicedisplay
Example of something interesting at the customer.

2. Flagging opportunities for improvement.

A dedicated Yammer group facilitates this process.
Whenever something could be done better, this is mentioned in this group, such as:
“I notice that the company flag at the Customer Center looks a bit worse for wear – can we have a new one?” or  “Can we please agree on a standard update interval for prices as I now have to find the latest prices in my own files rather than in the system?”
The Sales Managers discuss these suggestions and take the necessary action.

YammerBus-ImprovementsPost
Example of a potential improvement: reduce postage costs for samples

 

3.  Sharing winning strategies and achievements.

Another group has been created to share wins and winning strategies, as well as losses. Of course the Sales people are eager to share their wins, or show how they have added value or made a customer happy! Losses can also be a source for learning of course.
That information helps colleagues in two ways: they know what is happening with that customer, and they may learn different tactics to increase their negotiation repertoire.

YammerBus-Winexample
Example of win and interesting developments.

 

Not perfect

Is this perfect as a business system?
No. Yammer is not a CRM or Task Management system and conversations are easily lost without a process in place to capture and follow-up on them. Management and back office need to capture all posts manually and turn them into action lists and reports.
Posts are sometimes shared in the AllCompany group instead of in the group. (But you know you can move Yammer posts to different groups, right?)

YammerBus-Move conversation
In case you did not know – you can move conversations to a(nother) group!

 

But it works for them – the mobile Yammer app saves time for the Sales people, who are the face of the organization. They are on the road a lot and taking a picture with their phone and explaining in a few words at which branch of which customer they are and what they see, is quick, easy and useful.

As the Sales force does not often meet at the office, general improvements or the sharing of sales tactics might be forgotten without the Yammer group – but with the app they can share details immediately from any location.

Examples work!

The scenarios above may not work for you. But I have found that sharing examples help people to imagine what they can do with Yammer.

The other day I showed a rather skeptical audience these, and some other examples, of using Yammer. I also explained that, contrary to email chains, Yammer conversations are visible for people who get added to the group, e.g. new employees in the team.
All of a sudden one person said: “Aha! I am a Subject Matter Expert and I get a lot of emails from different people, asking me the same questions over and over again. If we use a Yammer group, we can share the questions and answers with everyone. That will save us all time. ”
We created that group there and then – it was also a good demo for the audience 🙂

Can you share some examples of how you have used Yammer for business processes?

An unpleasant inheritance

inherit-picInheriting something is a mixed pleasure.
You can become the proud owner of your uncle’s lovely old-timer, or be able to wear your grandmother’s diamond necklace and matching earrings at grand events, but you generally receive those treasures only after a dear one has passed away.
But you can also inherit debts, a house with an expensive mortgage, a nephew or other “things” that you have never wanted.

Inheriting permissions in SharePoint can also be a curse rather than a blessing.
“I have suddenly lost access” has been the title of many recent incidents. No need to blame this on Microsoft, SharePoint or the support team, because in 99% of cases this is a human error:

  • The Site Owner accidentally removed their own permissions while cleaning up a document library’s  or site’s permissions. The support team can easily fix this.
  • The Site Owner accidentally inherits the permissions from the parent site. That is pretty serious and has happened alarmingly often!

inherit-removeuniquepermissions
A dangerous button that will inherit permissions from the parent – this can be wanted in documents, folders and libraries but can wreak havoc in sites.

I have already mentioned in many of our instruction materials: “if you see “this web site has unique permissions” in the yellow bar, DO NOT CLICK “Delete unique permissions” as you will

  • Inherit the permissions from the parent site
  • Lock yourself out of your site if you have insufficient permissions on the parent site
  • Remove all unique permissions in your site (and there is no “undo” or “restore” option)

inherit-thiswebsitehasnqiuepermissions
If you see this text, you are at the site level!

The warning message appears not to be informative enough to keep people from proceeding.

inherit-warning
The warning message before you inherit the permissions from the parent site.

Recently I have guided a few people through “permissions stuff” via screenshare and I notice that they always want to click ‘Delete unique permissions” when they want to remove users. In several cases these users were individuals who were not in a group and therefore were seen as having unique permissions.
On those occasions I have been just in time to guide their mouse pointers to the right button: “Remove User Permissions”.

inherit-removeuserpermissions
Use this when you want to remove  groups or individuals from your site

This has now happened so often, with such serious consequences, that I have added a suggestion to Microsoft SharePoint Uservoice to rename “Delete Unique Permissions” into “Inherit permissions from parent” as this is probably easier to understand for the user than the current wording. If you agree, please support my request. (Happy to return the favour, of course)

You know, like in SharePoint 2007:

Inheritpermissions2007
What it looks like in SharePoint 2007 – much more intuitive! (Pic taken with Phone)

And if you have taken any measures that successfully prevent this accidental inheritance, please share!

Image courtesy of Phil_Bird at FreeDigitalPhotos.net

Beware the SharePoint MVP!

 

No, I am not going to bash the SharePoint Most Valuable Professionals! I have received help, feedback and support from many MVP’s including Veronique Palmer, Jasper Oosterveld and Gregory Zelfond, and I have read and used the posts and presentations of many others.

But I am glad this title caught your attention 🙂

The Minimum Viable Product

This blog will be about another MVP – the Minimum Viable Product, a common word in Agile development, meaning you will launch a product that meets the basic requirements (as defined at the start of the project) and will be improved incrementally over time.

I think I have been woking somewhat agile  when I was configuring solutions, and met with my business counterparts on a very regular basis to discuss the proof of concept/prototype and checked if this met their expectations.
I only created a very small list of requirements, as I knew that many business partners only had a vague idea of what they were really looking for, and when confronted with my interpretation of their requirements all kinds of unexpected, or in any case, unspoken, things came up.

  • Is there an option to leave this field blank?
    Yes, but that means that we either leave this non-mandatory (which may lead to more blanks than you want) or we add a dummy value such as “please select”. What do you think is best?
  • Can we have a multiple choice for this field?
    Ofcourse, but that means you will be unable to group on this in the views, so we will have to resort to a connection for filtering. Oh and then it is better to make this field a look-up field instead of a choice field. Let me rework that.
  • What if someone forgets to act on the email?
    We may want to create a view that allows the business process owner to see quickly which items are awaiting action.

And more of those things. I generally met with my business partner once every fortnight, if not more often.

So I am all in favour of especially the short development cycles of Agile.

“Users” does not mean “end users”, exclusively!

I also think that “user stories” are much more realistic and human than “requirements”, although they sometimes look a little artificial.
By the way, I would recommend any team to think not only of “end user stories” but also of “tenant owner” stories or “support user stories” as other people involved have their own needs or requirements.

Rapid improvements

I also like the idea of launching a Minimum Viable Product and doing small, rapid improvements on that, based on feedback and experiences, because

  • You can show users that you are listening to them
  • You can show that you are not neglecting your intranet after launch
  • It gives you something new to communicate on a regular basis

MVP-DevelopmenttoLaunch
During development, you work towards the Minimum Viable Product

So, when we were launching our intranet I was quite interested to be part of the project and to work towards an MVP.

When we finally launched our MVP we also published the roadmap with intended improvements, and shared the process of adding items to the roadmap.  That way users could see that we had plans to improve and that we would be able to spend time and attention on meeting the needs of the business.

Vulnerabilities

When launching an MVP with a promise to make ongoing improvements you are more vulnerable than when you do a Big Bang Launch & Leave introduction. What about the following events?

  • Cuts in the improvement budget.
    Those can be a blessing or a curse, but they may happen.
  • People who leave before they have documented what they have created.
    I have never liked the extensive Requirements Documents and Product Descriptions that go with traditional development, but if you are handing over your product to the Support organization, you really need documentation of what you are handing over. End users can have the weirdest questions and issues! 🙂
  • Reorganizations which turn your product team or even your company upside down.
  • Microsoft changes that mess up your customizations. We have a webpart that shows your Followed Sites – it suddenly and without warning changed from displaying the first 5 sites you had followed to the last 5 sites. Most annoying!

So before you know it, you end up with a below-minimum viable product. ☚

MVP-Developmentfromlaunch
While in a normal development cycle you would slowly and steadily improve upon the MVP, unexpected events can leave you with something less than MVP.

What can be done?

So before you start singing the praises of Agile development and put on your rose-tinted glasses

  1. Make sure you have a safe development budget that can not be taken away from you.
  2. Ensure you have an alternative no-cost optimization plan, such as webinars, Q&A sessions, surveys, configuration support, content changes etc. to make the most of the launch of your MVP and to get feedback for improvements for when better times arrive.
  3. Insist that everyone documents their configurations, codes, processes, work instructions etc. as quickly as possible. It is not sexy but will save you a lot of hassle in case your team changes.
    If you are in need of extracting knowledge from leaving experts, here are some tips for handing over to a successor, and some tips for when there is no successor in place yet.
  4. Be prepared for changes in processes, data or organization. You do not have to have a ready-made plan, but it is wise to think about possible implications for your product or process if the Comms team is being reorganized, someone wants to rename all business units, or you need to accomodate an acquired company in your setup.
  5. Keep customizations to a minimum. Use existing templates and simple configurations.
    Personally I would be totally content without a customized homepage. The SharePoint landing page or, even better, the Office365 landing page as the start page to my day would work perfectly well for me, but I have learned not many people share that feeling.

Any experiences to share?

Have you had similar experiences? Have you found a good way to handle budget cuts, a way to develop budget-neutrally, how to deal with people changes or another way to deal with unexpected events that endanger your MVP? I am sure there are many people (including myself) who would like to learn from your stories!

Images are from Simon Koay’s totally gorgeous Superbet. Look at that B!
M=Mystique, V=Venom, P=Poison Ivy

Knowledge Management from support tickets

KMTickets-headerNow that we have launched our intranet we constantly receive questions and support tickets from our users. That is not exactly a surprise, as we know that our current intranet is vastly different from our old one. We have SharePoint Online versus SharePoint 2007 and a completely new governance.
We learn a great deal about our users and our environment from these tickets and the discussions in our dedicated Yammer group.

Of course my team knows that I am into KM, so I am currently in a small “Virtual Expert” group on knowledge sharing. Our goals is to “translate experiences into knowledge”.

That sounds pretty formal, but it is quite simple really. And you know, I like simple, especially when it is about KM.

How it works

KMTickets-process

Whenever we receive an incident, we assign it according to the type of incident. This allows every one of our team to learn about a specific topic or process, and to improve the process or generate knowledge about this topic.
For instance, for a time all incidents dealing with permissions were assigned to me.
When I had gained sufficient knowledge of common permission issues, either by searching online or by doing experiments, I wrote work instructions for the rest of the team. Permissions issues (provided we recognize them when the tickets come in 🙂 ) can now also be assigned to others as we have a common procedure.
Yammer questions that can not be answered by the community receive similar treatment: we do online search and experiments where needed. (Although we ask people to submit a ticket when it looks like something in their site is broken)

We have a regular call to discuss any new and interesting issues.

When we run into a problem that we can not solve by searching online or doing an experiment,  we ask our very knowledgeable tenant admins. They show or tell us when they know the answer. My colleague and myself then turn this knowledge into documentation – be it a work instruction for the support team, a manual or a tip for end users, or sometimes a suggestion for extra communication or even a change to the system settings.

Most materials are stored on SharePoint: in our own team site or in the site we have created for end users.

Love all around!

KMTickets-LoveI love this structured approach. Our manger, who is very much into service delivery, formal processes and stuff like ITIL, appreciates the process we are going through.
Our tenant admins like to share their knowledge, knowing this will free them up to do tenant admin stuff.
My colleague and I have great pleasure in capturing knowledge and turning it into something tangible that helps us do our work faster.
The rest of the team is happy to have good work instructions.

SharePoint Holmes

It may be a small process, but it works for us and we enjoy the benefits.  And you…you see the SharePoint Holmes cases! 🙂

Header image courtesy of Kimberley Farmer on Unsplash.com

SharePoint Holmes and the disappearing Datasheet View

SPHolmes1Part of my role is solving user issues. Sometimes they are so common that I have a standard response, but sometimes I need to do some sleuthing to understand and solve it.
As many of my readers are in a similar position, I thought I’d introduce SharePoint Holmes, SharePoint investigator, who will go through a few cases while working out loud.

The first case is about a Datasheet View.

The case

One of the users of a site did not see the items in a list. Having access to the data was a requirement for his role and he had always been able to see this content before it was migrated to SharePoint Online.

So, I put on my SharePoint Holmes cap and rolled up my sleeves.

The investigation

  1. I logged in with my Admin account and went into the site.
  2. I saw the items perfectly well. Just items in a Datasheet view.
  3. Permissions check – the user had Read permissions to the site.
  4. Items with unique permissions check – the list had unique permissions but the user had Read access.
  5. Item-level permissions check – in the Advanced List Settings it showed that all items were visible to all users of the site.
  6. Workflow check – no workflow reducing permissions after going through a process.

Right, that was an interesting one.

  1. It was time to look through the eyes of the user, so I added myself to the same user group and checked. An empty list stared back at me.
  2. I went through the other views and found a standard one. I could see the items in there, and so could my user.
  3. One of my colleagues mentioned that issues with the latest IE update had been reported, which might have influenced the Datasheet view.  We tried different browsers. That made no difference, but there was always that difference between user and admin.

Hmmm….

The solution

Search engine to the rescue! One of the results surprised me, and I had to test that.

I created a datasheet view in my own tenant. It looked like this:

SPHolmes-Datasheet-Owner
What the Admin sees

Then I logged in with Contribute permissions. It looked like this:

SPHolmes-Datasheet-Contributor
What a Contributor sees

Then I logged in with Read permissions. It looked like this:

SPHolmes-Datasheet-Reader
What a Reader sees

You need at least Contribute permissions before you can see items in a Datasheet view.

The Datasheet view is meant for editing, so only people with edit permissions can see items in it. It makes sense and I have always told people to use the Datasheet view very sparingly as it is only too easy to change something. The many Excel-addicts in my user base however loved it and have also used it for display purposes in our SharePoint 2007 intranet.
Now they either have to elevate permissions or recreate their views.

Interestingly enough this was a permissions issue, but different from what I have ever seen before!

Image courtesy of Geerati at FreeDigitalPhotos.net