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.