The Curse of Customization

The briefing for our new intranet was: “It should work like the current intranet as much as possible”.

CurseofCustomizationWe had just spent a lot of energy in educating our users, and usage of our custom-built intranet was going up rapidly. We had appointed some Intranet Champions that were keen to create intranet sites for their departments or processes. We did not want to annoy or even lose them by changing the functionality that we had created with such care.

A bunch of excellent consultants had built our old intranet. They were a Microsoft Gold Partner, so when management decided we would “buy” rather than “make”, they were the perfect partner to create our new SharePoint intranet as well.
We had a great time! Together we brainstormed about how we would wanted the functionality to work and we reviewed all functionalities, opportunities and potential issues for users and for ourselves. Our partners happily tweaked everything the way we wanted it. I guess we provided them with an excellent learning opportunity, because it was early days for SharePoint and everyone needed to make some miles to truly understand it all.

6 months before launch, we set up a test environment for our Champions and other heavy users. We gave them a short training and asked them to do a few things and provide us with feedback. They appreciated being involved and came up with some good remarks.
3 months before launch we made an improved test environment available for all users. We created e-learning modules for end users, because we had customized so much that regular SharePoint trainings did not fit. We trained our Intranet Champions in site management and other new functionality.

Launch day came and went without major issues. Everything worked, there were no connection or other technical issues and apart from some questions, all went smoothly. After some weeks we found that in some small remote offices they were still using the old intranet (they asked why the news was not updated), but we could quickly solve that.

After some time, we noticed that our Intranet Champions became a little less engaged. Partly this was due to normal turnover, but we also learned that our most active Champions had lost track of how things worked. And when our Top Champion asked for help because he did not know exactly how to rearrange the content for his new department, we started up our “Business Solutions Team” to help people set up their sites and help them streamline their processes.
But this taught us that all our efforts to mimic the “custom-built” functionality had been in vain…

Maintenance and support
In the beginning, Microsoft was very interested in what we had done. (as it turned out, the next SharePoint version had many features that we had built in our earlier version :-)). However, since we had deviated so far from the platform, they could not always provide proper support. Every time an issue arose, we first had to discuss how we had implemented it, and only then they could investigate and solve.  After some time they stopped this because we were out of the initial service window.

Also, within our own team of consultants turnover and loss of knowledge became an issue. As people moved on it was harder and harder to find someone who had sufficient understanding of our tweaks, and was able to keep the system stable without making changes. And of course most consultants want to work with the latest SharePoint version, not with the current or an older one.

But also our outsourcing partner did not properly understand what we had done, and they had their bit of turnover as well.  Issues were not being solved anymore because everyone was afraid to touch the system.

Service packs
Every service pack deployment was an adventure! We would never know which tweak would be negatively impacted, so we had an extensive test script of which we all had to do a part. Fingers crossed that nothing would break!

Upgrade/content migration
When we thought we would finally migrate to a newer version of SharePoint, we did some migration tests together with Microsoft. We migrated one site with documents to the new platform, using Microsoft’s migration tooling. Although the receptor site and the logs showed all indications about receiving the documents, until this day we have never been able to make them visible.
That meant we would have to completely rebuild any new intranet from scratch and find another way to migrate the content.

What have we learned?
The briefing for our new intranet was: “It should be out-of-the-box as much as possible”…

Image courtesy of Kheat at

4 thoughts on “The Curse of Customization

  1. Jeroen December 11, 2013 / 6:45 pm

    Hi Ellen, I have seen the same effect in a different setting. A workflow application that was integrated in Outlook was recreated in the clientside of a document management / workflow system.

    In this setting, we used the term: “as is” to describe the transition to the totally different (underlying) technology. The users were not to be bothered with the fundamental difference in technology, that was something ” under the car hood/bonnet”.

    In hindsight it might have been better to just go for a more default implementation of the document management / workflow system.

    Less euros to adapt the user then to built a look a-like client mimicking the old application. We will never know for sure…

    • Ellen van Aken December 14, 2013 / 9:13 am

      Thanks for sharing your story, Jeroen! I agree it may be better to use something standard and teach people how to use that. In the end, it is better for everyone because also the user will suffer if nobody knows how things work. And indeed…customization is expensive in more ways than just the money!

  2. Ashley Johnson January 4, 2016 / 10:17 pm

    Hi Ellen,
    I wanted to see if you might divulge with whom you partnered, for my own curious interest. My company offers applications on Office 365 and SharePoint, but the main takeaway is that they don’t cover up SharePoint, as a lot of Intranets do, which ultimately will cause problems down the road. And we have been discussing this issue a lot on our blog. One of our posts concerns the issue you had about whether to build or buy your Intranet, the link to which I am including below. Thank you for the very insightful post and it confirms what we’ve been saying about when you choose an Intranet solution, make sure it fits in with Microsoft’s native guidelines.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s