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!

Advertisements

My personal gems from IntranetNow

GemsOn October 5 I participated in IntranetNow, and a wonderful conference it was!

There were plenty of interesting and enjoyable presentations but below are the ones that resonated most with me:

1. An excellent Yammer use case

Baxter Willis of WM Reply shared a great Yammer use case from one of his clients, drinks business Diageo.
Apparently they have an archive of all bottle types, advertising materials, recipes etc. Nobody was really aware of that department, until recently. They are digitizing their content and the archivist posts something interesting on Yammer every day, e.g.
“Did you know that Pimm’s has been associated with Wimbledon from the 1930’s?” accompanying a picture of a nice old newspaper ad proving her point.
This lady is now the toast of the company and her Yammer group is very popular.

I like this because it is another easy way to share knowledge, which would otherwise be hidden in the archive. Posting it on Yammer costs nothing more than 5 or 10 mins a day. It helps the Marketing and Social Media people in their current work by giving them new insights to the company and its history.

The new Smirnoff label is now based on earlier labels throughout time, and this is also caused by this work!

2. How to get feedback from your employees

Emma Morrison and Usman Hasan of Hyde discussed the their intranet redesign, based on feedback sessions with their employees.

What I liked about this is that they used a simple but effective approach of lunch sessions, and shared their learnings.

The “let them rant” or “whine and dine” idea resonated with me, as I have also found that sometimes people just want to vent, sometimes not about the intranet itself, but about related things.
In my situation I have heard from several annoyed people who had been handed over a team site due to reorganizations – either because they had a new role and the team site came with it, or because the previous owner had moved on. Someone else’s team site can be quite hard to handle as the setup and especially the permissions are not always documented or intuitive.
I have learned that the best way to help them is to go through their site together, trying to make sense of it (looking at site contents, checking permissions), rather than trying to defend something or taking it personally. 🙂

3. Improving an intranet with no budget

Janet White shared her approach to improve an intranet with very simple means and no budget. Anyone who can get good results with creativity and elbow grease, rather than money, is my hero!

Using simple tools like card sorting, tree testing and talking to users helped her to improve the navigation of the intranet (better labels and better structure) and some of the content.

Note

I have linked to the Slideshare versions of the presentations as I expect the information on the IntranetNow website will be replaced next year.

Image courtesy of Aasimshaz

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

Working in a SharePoint box

spintranetsinaboxRecently I have been helping to launch a new Office365-based intranet.
While we set out with the idea of “out of the box” (a sound strategy, knowing my earlier experiences with extensive customizations) we have had to create some custom things to meet the requirements of several stakeholders.

I was therefore very interested in Clearbox Consulting ‘s evaluation of 26 “SharePoint intranets in a box“.
Unfortunately this report was published when we had already progressed very far in our intranet journey, so there was no reason to buy it.
Still, it kept nagging me because I was really curious if we could have used one of the “out-of-the-box” solutions.

So you can imagine my surprise and elation when Sam Marshall provided me with a copy just before Christmas, as well as a discount code for the readers of this blog.

What is this report about?

It compares 26 products of companies claiming to have a ready-made SharePoint intranet. This means that you do not have to do any developments yourself. It is just some configuration and a little branding.

The researchers have made the evaluation by comparing a set of standard scenarios that most intranets will need:

spbox-content
Content of the report. (Screenshot from the website)

Strengths

The major strengths are:

  • Many offerings compared – I never knew there were currently 26 different products!
  • The evaluators are all experienced intranet peeps who know what they are doing.
  • The evaluation is based on recognizable business scenarios.
  • Consistent and objective evaluation. (We could never have done it, since we would undoubtedly be biased by our own requirements)

To think about

  1. The cases provided are all very common in the intranet world. However, you may have some unique requirements that are not mentioned here. In that case, you may need to create your own filtering to find out who would be the best in-a-box-partner for you.
  2. As mentioned earlier, SharePoint and Office365 are changing very rapidly, and I do not know a. how well all vendors can keep up, and b. if and how quickly SharePoint developments will catch up with the vendor’s unique features. (I heard “Corporate News”  is on the Microsoft roadmap for 2017)
  3.  I expect new vendors to appear as well as consolidations.

So, I therefore hope and expect that there will be regular updates to this report…

Who should read this report?

  • Anyone who is starting on a new intranet should definitely read this.
    This may help you to decide if SharePoint would be a good option for your organization. You may think SharePoint is too much and too big, but an out-of-the-box solution may just offer what you need without too much hassle.
    If you already know you are going the SharePoint way, the report may help you to determine if a ready-made solution would be useful. Even if you think you know SharePoint well, you will learn a few things that may be relevant for you now or later.
    You may decide not to go for a ready-made solution, or even not to go for SharePoint at all.
    The report may also trigger you to refine or extend your requirements. For instance, we all have “Company News” on our radar, but have you thought about if and how SharePoint can be used for ideation? If Communications is your major stakeholder, they may not immediately think of the need for transactions. You may want to check with all stakeholders if they have thought about those things.
  • Anyone who has to decide on the need for custom development.
    If none of these vendors mentions what you are setting out to do, you may indeed need to develop it yourself. But if they all provide this functionality, it is probably available as an app somewhere.
  • Anyone who is working on their intranet or digital workplace roadmap, to determine whether it makes sense to move to a ready-made platform in future.
  • Anyone who is curious what intranets-in-a-box have to offer.

But isn’t this a lot of money?

No, it is not.

  1. That amount of money will buy you only a few hours of consultancy.  If you want to set up your own requirements to test against, agree on it, find and talk to all the vendors, have demos and evaluate all the results in a consistent way you will need much more time than “just a few hours”.
    Besides, the evaluators have not been biased by their own requirements.
  2. I can offer you a 10% discount if you use the code IIAB2CBOX10on the product page .
  3. You can probably get away with charging this (< 500 € / £ / $) on your credit card and submitting it as expenses 🙂 .

Good to know

I have reviewed this report for a number of reasons:

  1. I was interested in the topic because I was curious if the intranet I am working on could have been done out-of-the-box, which might have saved us a ton of time and hassle.
    (Answer after reading the report: I think we really needed the extra work we have done to meet the requirements.)
  2. So far, I have been the only “practicioner” who has reviewed this report. I think it is important that someone, who is actually in the middle of a SharePoint project in a company, shares their view.
    You will find more reviews on the Clearbox blog.
  3. I have known Sam Marshall personally for a number of years. I also know most of the people who have worked with him on this report. I have great respect for all of them. Therefore I trust this report.
  4. This has been a Christmas present so I have had the time to read and think. 🙂

So, everything came together very nicely this time.

Title inspired by “Living in a box” by Living in a Box from 1987.

 

 

Ouch-sourcing

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

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

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

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

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

Unfortunately, there were also a couple of bad points…

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

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

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

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

Image courtesy of kjnnt at FreeDigitalPhotos.net

Project Management in a Team Site

Over the years, we have used Team Sites extensively for managing and working in projects. Depending on the type of project, we have used them in different ways:

Simple Projects: stand-alone Team Sites

The majority of projects were simple, short-term projects where a Team Site was used mostly for sharing documents, and perhaps a calendar for meetings and deadlines. Everyone with a good business reason could request a Team Site. We left it to the project manager to configure, which he or she seldom did, but as long as they let us know when the project was finished and the Team Site could be removed, we did not mind. The basic setup was generally sufficient and the target audience small.
We only actively tried to discourage the use of  Team Sites with Tabs; they were very popular but also took a lot of work to set up properly. For a short-term project we thought this was not efficient.

Recurring projects: Team Site with templated subsites

There were also teams who had one project after another, such as product development and IT.  Some of the project managers wanted to have a standard setup for their Team Site for each project. For instance a standard lookup field in every Document Library with the project phases, a custom list to manage time spend, or a world clock because they were working with people from all over the world. Since we did not like to configure stand-alone sites every time, we usually created a subsite template, which we or they could activate whenever necessary. For the project managers it had the additional benefits that all project sites were under one Team Site “umbrella”.
My earlier Crisis Management in a Team Site is another example.

Multiple projects: 1. PMO Team Site.

As every large company, we often had global projects with local or functional sub-projects. You may think of a Sustainability project, the follow-up of  the yearly Employee Satisfaction Survey, or a company-wide Cost-Reduction program.  It was essential that the progress of these projects could be monitored in an easy way. 
Many of those projects were therefore facilitated by a simple Team Site with an Issue Tracking list as the main component. Every project was a line item, that the respective project manager had to update on a regular basis. By cleverly configuring the list and the views we could give a great overview of project progress to the Program Manager.
The individual projects could be managed in a subsite, a stand-alone site, or in a different way.

The first few times we really had to push this functionality to the various Program Managers, but after a few succesful implementations, people came to us immediately when a new global project was planned.

Multiple projects: 2. Program Site Collection.

For other major global projects we created a dedicated site collection. We only did this when it was absolutely necessary, for instance when many people had to contribute (increasing the risk of accidental overwriting), lots of documentation had to be shared, and/or it was important that one country or function did not have access to another’s information.
In those cases we used a templated subsite per country and/or per function. We generally made use of (Corasworks) rollups and rolldowns. For instance, announcements and manuals were posted in one site, and rolled down to all subsites, while the results of the project were rolled up from all subsites into another site for reporting.
All these rollups influenced the performance of the site. Next to that, it was essential to think about security because there were many people who needed access to one subsite or another, and if you wanted to be able to see the rollup of results, you had to have access to all subsites. And then we are not even talking about any changes in template – if the program manager wanted a change to the template after it had been implemented,  it meant that you had to make changes to many individual subsites and to the rollups.
But in the few occasions when we have used this setup, it has worked well.

I will describe and show an example of the PMO Team Site setup in my next post.

DoMoreWithSharePoint – Development Process overview

So, you have a business process that does not run as smoothly as it should; it is not (yet) in scope for your ERP, and you and the Business Process Owner have agreed that you will make a (temporary) solution in SharePoint. You have a team, you know how to set priorities, and now…

How to start? And how will you do the next project? Will you re-invent the wheel for every new project? You may do that for the first few projects, but then it is time to collect your learnings in a standard process to give you a good guideline. And especially when working with others in one team, it is important that all of you work in the same way.

Basically, this is an IT-type project; the main differences being:

  • no financial investment – your platform is already available
  • no technical implementation – the focus is on business change and configuration, not on code
  • the Site Owner is responsible for ongoing maintenance, including small changes

We have defined the following major steps. Every step has a set of substeps, that you will apply depending on the complexity of the problem and solution.

1. Project Definition
You discuss the project, scope, mutual expectations and business case with the business owner, and agree on the next steps.

2. Design
You create a prototype or proof-of-concept to test your understanding of the issue, to give a business owner a tangible solution for initial evaluation and feedback, and (optional) to validate your functionality assumptions.

3. Build and Rollout
Upon agreement of the proof of concept, you build, test, rework, and finish the solution with the business owner. Next to that, you also support the business owner with implementation in the business. Finally, you train the business owner and back-up in maintaining the solution and how to get support.

 4. Ongoing Maintenance and Support
While your business owner should be able to make small changes and maintain the content, you may need to help him or her with the more major changes or bugs. Also you will want to monitor the site’s usage over time, and keep track of  housekeeping issues.

I will elaborate on the different steps in later posts. You can find earlier posts on the process via the DMWS-Process tag.