My third SharePoint intranet

This was also very likely my last! 🙂 Start and finish: 2021.

When I arrived at the scene, the organization had an intranet on an outdated, unsuitable platform. It was very complicated to create News and add pictures, content was outdated as it was quite a job to update stuff, and there was no interactivity at all.
The formal document management system (on the same platform) was cumbersome, the content outdated, the owner had left and nobody felt really responsible for that system.
On top of all that, there were considerable costs involved while we also had Office365, so it was only a matter of WHEN we would move to SharePoint Online and other Office365 applications, not IF.

Fortunately the project could start when I was still there and we would launch before I would retire.

This was a model project, quite unlike the two I had experienced before. In my first intranet we customized for functionality, in my second intranet we customized mainly for branding, and this one was a breeze: no customizations wanted or needed! Of course, SharePoint Online had evolved since I was involved in my second intranet, but there were a few other success factors as well:

1. Two projects: intranet and document management system

While I was trying to convince everyone that we really needed to start working towards SharePoint, I noticed that there was a lot of pushback. Gradually we understood that the governance model was unclear. We tried to help people see that the intranet and the DMS (document management system) happened to live on the same platform (at that time under one governance) but were two very different things. We needed to separate the two projects with different project teams and ownership.

My colleague was involved in the DMS, as this would be more complicated and she was expected to stay in the organization after my retirement, so it would save a handover. The intranet was simpler and I could easily document and transfer the knowledge to her.

So, from now on, this post will deal with the intranet.

2. SharePoint out-of-the-box

This was a strong wish from everyone involved. We did not think customization would be necessary for our requirements: News, formal information from various departments and processes, and an entry point into applications such as the HR system and the DMS.
We also wanted to avoid complexity, a longer timeline and costs.

3. Office365 was already in the organization

We did not have to worry about technical implementation, as we already used the Office365 suite. We needed to set a Homepage and make sure we could create Hubs, but those were only small adjustments.

Our colleagues were also already familiar with how things worked, so it was not a major change. We already used SharePoint sites for projects, departments and what not. Those would not be included into the intranet per se but could be linked to when needed.

4. Small project team

There were only three people involved in the day-to-day project management:

• The project manager and intranet owner from Communications. She was in charge of the content and design, and also liaised with the various stakeholders in the organization.
  At launch she was responsible for Communications and training of News publishers and other colleagues.
• An external Microsoft consultant who had created intranets before. He knew all the functional details, and he also brought experience from other organizations as to what worked and what not.
• And then there was me, who knows about SharePoint, but I did not have experience with Hubs and Homepages and Organizational Assets and those kinds of things. I was the liaison for IT-matters, and e.g. informed my colleague and our systems administrators what was happening, and which changes we needed to make in the system.
  At launch, I was also involved in the training sessions.

This was very effective. No large meetings, no endless discussions, we shared progress with the organization and asked for their feedback and worked that into the new intranet.

5. No additional branding needed

After having worked for a number of brands, with branding customizations that were “absolutely essential”, it was very strange for me to notice that this organization (mental health care) was not really interested in branding. Every site beloning to the intranet has the intranet icon, and the DMS (called “Werkwijzer” aka “Work directions”) has its own icon, but that’s it.
Everyone can select their own Office365 top bar colour/pattern, we did not need the name of the organization in the bar, and the “default blue” SharePoint theme was close enough to the company colours. I tried to convince the project manager that we could easily change the theme to the actual blue from the corporate colours, but that was not needed.

6. No content migration

We decided not to migrate anything centrally. If a site owner wanted to move content from the old intranet to the new one, they had to do that themselves. We advised against copying, as most content was outdated. This led to some struggles with people who did not want to refresh their content, but the project manager insisted on at least a review and preferably a complete redesign to fit in the new setup, such as more picture materials and better use of page columns.

7. Guidelines for News and pages publishing

During training sessions of the future news and page editors we noticed that some people felt confused about all the options for visual display of their News and pages.

We decided to create some guidelines to help the publishers and keep things consistent. That post (from April 2022) got a lot of positive responses in the SharePoint/intranet community, so I guess this is interesting for other organizations as well.

8. A hard shut-down date for the old intranet

We needed to shut down the old intranet before November as the yearly bill was due then. We closed it down for employees three months before the pay date, but every publisher and content owner still had time to check if they had everything in their new site. The project manager warned everyone several times about the final shut-down date until it was finally gone forever.

What did not go so well?

Although nothing went wrong, we found that having many different News channels and publishers in one Hub site made the News part of the intranet a little crowded and overwhelming for some. Every News post is public, so a lot rolled up into the Hub, meaning a very short visibility time for each item on the Homepage. (Only 4 items were displayed at any given time)
Besides, some posts were duplicated as a re-post, and it was not always clear where a post originated. We spent some time fine-tuning the number of items, creating links to the Hub site, communicating how things worked etc. in order to improve.

Below is a screenshot of the Homepage just before I left (December 2021). You see it is standard SharePoint. It is all in Dutch, but I think you can guess what is what: Central news, the DMS, Events (including our Office365 webinars), the various intranet sites/departments, some highlighted items and links to various sites and applications.

Homepage December 2021

Three months after launch it was decided to show more items on every page, to address the wishes from the organization, and to rearrange things a little. The screenshot below is from October 2022.
The News and Events are both a little longer, there are some (pink and green) highlighted organizational projects, changing every month, and the various external web sites have a separate row with yellow icons. This was all done by the intranet manager herself, no difficult customizations needed!

Homepage October 2022

Now: Happy intranet manager and publishers

The intranet manager (the former project manager) informed me she is really happy with SharePoint. She finds it easy to work with and regularly makes small changes to the homepage herself, such as new buttons, or new highlighted items, to keep things fresh.

Furthermore, the news and page publishers like working with it, too! They inspire and stimulate each other to make posts and pages as nice and useful as possible. How cool is that!

Now: Proper governance

In the old intranet, both content, design and technical/system support for the intranet and the DMS were the responsibility of the Communications department.

Now, Communications is responsible for design and content of the intranet, while the DMS Owner is responsible for the design and content of the DMS.
ICT is responsible for technical and functional support for both.

Conclusion

All in all, we completed the project in about 6 months. It could perhaps have been done faster but things were a bit slow over the summer holiday period. Still, it was the shortest intranet project I have ever been involved in, and it was a most enjoyable last project. I could finally prove that customizations are not needed for a good intranet!

So, go for standard out-of-the-box SharePoint, folks! There are already so many options, and most of them have been well thought out for intranet use. No need to re-invent your own wheel!

My second SharePoint intranet

This project was started in 2015 and launched in 2016.

The situation

The old intranet was built on SharePoint 2007 (on-prem) and bursting at the seams. Each business had their own site collection, with many subsites underneath. Each site collection could only hold 2 GB (!) so it was a constant struggle to keep within those limits.
I was the functional owner of a number of site collections and most of my posts from that time deal with keeping the storage space within its limits. So I shaved off versions, migrated stuff to archive collections or even shared drives, optimized presentations and what not, in order to keep the ever growing collections within limits.

The different business were quite autonomous in their approach, so some site collections had been nicely reworked with SharePoint Designer, and some had lots of workflows. There was an attempt to have common procedures, but this was all voluntary and not mandated.

All business and ICT folks who were involved with content, support and system maintenance really wanted a new intranet!

The project

After many years of project proposals we finally got approval to start creating a new intranet, based on SharePoint Online. This was not so much because the budget holders thought they needed an improved intranet, but because support for SP2007 would stop and the business wanted to move more applications to the cloud.

A Microsoft partner was found and off we went! At the beginning I was not really involved, which frustrated me. At a certain moment I just inserted myself into the weekly progress meetings and started asking questions and giving advice. After all, I had more direct contact with users of the current intranet than anyone else in the project, so I thought my input could be useful. Some weeks passed and I was considered one of the project team 😁

Mistake #1: Majority of budget went to News

We spent the majority of budget on creating a custom News function, which would be targeted and personalizable. It consisted of one page per news item in a special page format, a (too large) number of tags, and a publishing flow. Especially the targeting and personalization took up most of the work, as it had to be build and was rather complex.

When we launched, it was not fully ready but most of it worked. Improvements were on the roadmap.

The project team then attended a Microsoft event and heard that Microsoft would launch SharePoint News a few months later. We collectively cried a bit 😂

Mistake #2: Agile development, Waterfall operations

This project would be a pilot for introducing Agile methodology into the organization. We got trained and it went actually quite well. I like having many short improvement cycles, it suits my working style. When I was creating “Business solutions” at my former employer, I also worked like that, knowing that ideas and requirements would change as my customers learned more about the capabilities of SharePoint as we progressed.
(I know there’s more to Agile but this stood out for me)

At launch, the intranet was a Minimal Viable Product. We had a roadmap to improve it over the next months. Only…due to cost savings the improvement budget was cancelled, which was a big disappointment and not a good way to deal with Agile. It turned out that an MVP is a good, but vulnerable, concept.

Additionally, no budget was provided (let alone left) to provide adequate documentation, as that is “not Agile”. That did not sit too well with the operations manager who had to provide the support, but we thought we could manage, as both an important developer and myself were in-house. I wrote about this mistake as well. (TLDR: the developer left shortly after launch…)

Mistake #3: Custom design

The idea was to make the intranet look like the corporate website. I do not always like this, as the purposes and audiences are completely different and one generally changes the website design more frequently, leaving the intranet with an “old” look-and-feel. I have ranted about this earlier. 😁

It meant that, for communication sites, we had

• a non-standard font size, rather large
• a Promoted Links tile that had slightly different behaviour (dimensions, hover-over) than regular, causing tons of confusion with people who looked on Microsoft Support or YouTube for instructions
• 65% white space, which drove people nuts because they had to scroll a lot to see the content they had to work with daily

Example of a page with customizations.

We had custom page templates to allow these features.

For team sites, we had custom content types, created to make a difference in stages of a document, as well as hidden tags to help Search. These were also organization-based. Then we changed the organization. Do I need to tell you about the consequences? Fortunately, not many people were aware of the custom content types, most people just used the default and never looked back…

In my post about my first intranet I already mentioned the joy of customizing SharePoint, so I will not do that here. Let’s keep things cheerful! 🥳

Mistake #4: Migration mistakes

The project team initially decided that we would only centrally migrate content that was no older than 2 years. Older content could be migrated by the owner if they thought it was necessary. However, the business insisted that everything should be migrated, as it was too much work to filter out the relevant content and “we had enough storage space now”. So even very old files that I could no longer open in our SP2007 environment were migrated, and still could not be opened. What a waste!

Additionally, the “migration factory” (as the migration team called itself) often forgot to include the new page templates and/or to remove the old page templates. This led to frustrated users who could not use the new templates, and to frustrated support people as people kept using the old templates so we did not get the uniform look-and-feel that we wanted. It was up to Support to adjust all mistakes as these would generally show later.
Permissions were migrated as they were, and not (as we preferred) on the site level only (to allow the business owners to review any more detailed permissions).

Of course we also have some successes to report:

Success #1: Modern SharePoint environment

Apart from all the other SharePoint mod cons, we finally managed to make every site stand-alone; the subsites (sometimes 7 layers deep) were gone, and we had STORAGE SPACE! 🥳

Success #2: Central governance

The organization had given a more central role for ICT. This meant that all site collections were now managed by one ICT team, rather than by the various businesses and ICT. This allowed us to finally have one central governance, for instance:

• Central creation and deletion of sites
• Naming convention for sites, so each site had a unique identifier. We used a number, which I thought was rather unpleasant as it gives you no clue what the site is about, but with about 25,000 (!) sites it was the easiest system
• Custom role for the site owner, so they could not do everything (esp. in design)
• Central review and reporting on the site collections

Success #3: Mandatory Site owner e-learning

I have always been in favour of a sort of “site owner exam” and it fitted within our more strict governance, so I created a training and a test in e-learning format.
Remind me to share the test in a Form one of these days, so you get an idea of what we wanted people to know. An earlier post about our training setup.

Success #4: Launch video!

The communications department created a rather nice teaser video to celebrate the launch. The original version lives on a corrupted USB-stick, but I managed to find an old Teams recording showing it. Please play at 2 x speed to see it properly. The sound has been lost during the process, there was a simple music soundtrack behind it.
Now you understand why I am partial towards intranets called “Connect”! 😊

My very first SharePoint intranet

During my career I have helped to create and implement 3 SharePoint-based intranets:

1. Custom-built > SharePoint 2003 (on prem)
2. SharePoint 2007 (on prem) > SharePoint Online
3. Other platform > SharePoint Online

I have made mistakes and created things I am proud of, and I thought I’d share it for your amusement and possibly learning.

Let’s start with the first one, this was in 2005.

Our custom-built intranet was just beginning to take off, and when we moved to SharePoint 2003 we did not want to lose momentum. So our goal was that everything worked as much as possible as the current system. This may not have been the best idea, but we had even worse ideas. 😁

Mistake #1: Too much customization

I have described most of this in my post “The Curse of Customization” because we customized everything, and that included adjusting texts in the back end and removing the Folder capabilities from Document Libraries and replacing that with a mandatory column called Category, which was totally cool but most annoying when you quickly wanted to add a new category.

Mistake #2: Too complex usage statistics

Another idea that seemed great at the time was custom-built usage statistics. The standard SharePoint info was (and is) meagre, and we wanted to be able to break down usage at various organizational and business levels, just like we had with our old intranet.

How that turned out, you can read in “KISS: Keep Intranet Statistics Simple“

Mistake #3: Outsourcing support

This was not our decision of course, but a company decision. For our intranet this was rather devastating, as you can read in my post “Ouch-sourcing“.

Of course there were also things that went well!

Success #1: Do More with SharePoint: our Business Solutions

Although in the beginning people were a bit hesitant to use the new intranet, we quickly created a process to help them make the most of it. We turned into a “Business Solutions team” that improved problematic business processes, based on a business case. Our calculation method to determine priority for us, and benefits for the business, has been described in this post. And yes, this method was approved by our finance team.

One of the most successful cases was a pre-SAP automation of the CRM-process of part of the organization, where different teams analysed every complaint and determined whether they needed to re-imburse the customer or that someone else was responsible for the complaint and any damage. See “CRM in a Team site“

You can find more examples here: https://mydigitalworkplace.wordpress.com/tag/business-example/ (you may need to scroll down a little)

This was REALLY fun to do, we all learned so much about SharePoint and the business was happy with better and cheaper processes. Sadly, my later employers were not really interested in this setup. 😥

Succes #2: Good score in Digital Workplace Group’s Benchmarking tables

We became members of the Digital Workplace Groep (then: Intranet Benchmarking Forum) and we quickly rose to the top of the league for most categories except Usability and Design. More information on the Benchmarking process: https://digitalworkplacegroup.com/benchmarking/ 

The homepage above the fold; you can see some more here

Succes #3: The oldest intranet promotion video in my collection!

Although I can not imagine that we were really the first organization that created an intranet launch video, our video is the oldest in my collection that I am aware of. Enjoy!

Reaching beyond the usual suspects

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

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:

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:

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!

My personal gems from IntranetNow

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

Let’s celebrate the unsung heroes: “The @MVPAward recognizes individuals who, over the past 12 months, have demonstrated superior knowledge, leadership and passion, combined with a desire to help and accelerate other’s learning, careers, and abilities.” https://t.co/R0eebaLcz5

— Tracy van der Schyff #NotLiz (@tracyvds) March 15, 2018

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

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

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

Recently 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:

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 “IIAB2CBOX10” on 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

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

Ah…those were the days when we still had our own development and support crew.

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.