[SP20xx] Are you keeping up (part 1)?

It’s never a bad thing to look at what’s coming. This future peeking seems to be hot in the SharePoint world, with guys like Dan HolmeBenjamin Niaulin and Daniel McPherson giving their take on what’s in store for us. Interesting views which of course always include things like cloud, mobile devices and new ways of working for your end users, whatever generation you want to call them.

In my day-to-day work though, I am still mostly involved with enterprise grade customers who might be thinking about that stuff, considering it, but most definitely they’re not there yet. On the contrary; they have a long way to go. So I wanted to write this post to give an overview of things those companies can do today with their current landscape, in order to prepare for that future. And do not worry: the conclusion will not include you writing apps from now on.

In this n-part blog series, I’ll discuss some of the ‘hot topics’ and my views on what choices enterprise grade companies need to make.

When you work at such an enterprise grade company, most of your colleagues will probably still be working with SharePoint 2010. Even 2007 MOSS might still be in place because of some legacy applications running there, or the fact that no one really want to spend time migrating stuff. Let’s not forget that SharePoint 2007 is “only” 7 years old, which really isn’t that old compared to other systems your company might have (Lotus Notes, anyone?). Probably, your company also has a habit in skipping versions. The IT department is not comfortable with installing a first release version of Microsoft product. They will wait until Service Pack 1 comes out just to be certain most bugs are fixed. You are using a Windows 7 PC because Windows 8 is weird and it’s pretty likely that the next migration will take you to Windows 10, skipping 8 / 8.1 completely.

Does that all sound familiar? It’s still how things work at a lot of companies. The world might be screaming cloud, short release cycles and things like that: reality is different. Might not be the message Microsoft likes to hear, it’s the truth.

The need for change

So, first thing you need to ask yourself is: do I need to change? Valid question in my opinion and the answer is always: no you don’t. No matter how many people tell you different; you do not need to change when you do not want to. But (there’s always a but); risk increases when you don’t. This is nothing new. Remember that time you had to migrate dozens of old Windows Server machines to a newer version because it was running out of support? You really didn’t have to. Those machines would have kept running even without the upgrade. But you didn’t want to take the risk of running unsupported machines, so you decided to go with the upgrade.

So, it comes down to risk assessment. In the previous scenario, risk assessment was pretty easy. When out of support, any issue you would have would not be fixed or it would cost you a bulk load of money to get it fixed. Chances are though, you weren’t having that many issues any mor since it was already fully matured software you were using. Today, risk assessment is not that easy any more, because more factors are coming into the picture. I’ll give you some examples:

  • With cloud style services popping up everywhere, your business is considering alternatives. IT departments are considered to be inflexible, expensive and even incapable. I’m not saying they (all) are, but that’s how your business perceives you.
  • Your end-users are becoming more and more tech savvy. They are used to having mobile apps, nice looking responsive websites and all kinds of other fancy stuff. Having to work with old legacy stuff could be a serious turn off.
  • With companies like Microsoft using different release cycles, the “we’ll wait for SP1” argument really doesn’t cut it any more. Risk of installing a first release version is much less compared to what it was before.

So when doing your risk assessment, you need to take things like these into account. You think you might be avoiding risk by not acting, whilst actually you are taking risk by doing so. I believe it was Dan Holme amongst others who call this “Risk of inactment”.

Okay. Back to your traditional enterprise company running SharePoint 2010 and Windows 7. Should you now conclude you need to move to the cloud and upgrade to Windows 8.1? Absolutely NOT. Again, it’s about risk assessment. History should have taught you that most upgrades and migrations are pretty painful and bring a lot of horror to your end-users. And to be honest: why would you migrate that legacy SharePoint 2010 application when it’s still working ok and SharePoint 2010 is still being supported?

 

So how can we keep up?

Start by trying to keep up instead of catching up. What I mean by that: adapt your IT policies and processes to be compatible with current day technology, but also to keep it there. Too many migrations are followed by a period of inactment in which we fall behind again. Instead, IT policies should be adapted to make sure we keep up in the same pace as technology is moving. Switching your policy from “we’ll wait for service pack 1” to delivering the latest stable releases will be a huge step already. Your business users will notice and I’m guessing that they will like you for it. And it’s perfectly fine to choose to stay behind one year or maybe more, but don’t let that gap get any bigger.

Some examples: new employees requiring new laptops will get one running Windows 8.1 and Office 2013 installed. As soon as Windows 10 is stable, you start rolling out shiny new Windows 10 devices. Newly installed servers should be running the latest version of Windows Server and you might want to consider moving them to a cloud provider like Azure or Canopy. And when a team requests a SharePoint site, deliver it running on SharePoint 2013 or Office 365. Do that all, but leave your current IT as is, unless it needs to be changed for whatever reason.

It sounds simple, but most IT managers will have some concerns:

“Won’t we get into trouble with non-compatible software?”

Sure, that’s a valid concern. When an employee relies on software which really isn’t compatible with a new version of Windows, this won’t work. So give  that employee an older version which is compatible. But normal desktop workers who only use Outlook and Office can get the latest version.

“Supporting our end-users is far more easier when everyone is using the same software”

Of course it is. But the point of this all is that your end-users should be empowered here. Sorry, but you IT guys are never core business although some might think so. Your business is about your customers, so you need to make sure your employees have the tools they need to do their jobs the best way possible.

Surely there are a lot more concerns which I could list. The answer pretty much boils down to the same thing: your company should focus on their business, not on their IT. The days in which IT was so complicated that no one understood it are gone. Any IT department which will not follow that lead will get into trouble one way or the other.

 

Empower early adapters

Another great way of keeping up with new technologies is most likely already present within your company. It’s the employees who are early adapters by nature. The guys who have the latest smartphones and tablets in their bags. The guys which sometimes annoy IT by nagging for that new version of Lync or Internet access to the webbased applications.

Traditionally IT would not care about these people, since an employee is an employee. But what if you could use that group of people to test new releases in the field continously? What if they could stimulate colleagues to also upgrade their software? Help out people who are new to the new version of Windows? You would get an enourmous amount of engagement for free, not to mention the hours saved on training and support.

Again, try to keep it simple. By announcing an early adopter program, you can easily identify the individuals within your company who like to test out new stuff. They will sign up themselves. Those people usually understand that new stuff can have it’s perks and they do not mind Googling a bit to find out how that new piece of software works. They’re the ideal group to test since they will dive into all corners to find out what’s in there. And once their colleagues see the new stuff,  they will start wanting to have the same. This way, a migration changes from being something that is pushed by IT to being actually wanted by your end-user.

There will always be that group of people who just don’t care about new stuff and for who any migration of any sort is painful. But if you’ve already got 80% of your company running on the latest versions, pushing that final 20% because their software is running out of support is not that hard any more.

 

So, we should still migrate?

I wouldn’t call it so. When keeping up, the need to do migrations becomes less and less. Taking SharePoint for an example; you can easily have 2007, 2010 and 2013 running next to each other. New workloads land on 2013,  the older farms keep buzzing untill they run out of support at which time you’d have to move some left-over data to 2013. Most of the time, your end-users will already have moved the stuff they work on because they feel  the new  platform is better.

For those familiar with the SharePoint upgrade process, you know that such a technical upgrade requires a SharePoint 2010 farm anyway, so it’s all the better you have that already running. Or where you that company who skipped a version and wants to go from 2007 straight to 2013?

To come back to the opening of this article; I really do believe that with minor adjustments, IT departments can start to make a difference. I also believe they need to when they want to remain credible towards their business colleagues. IT is moving whether you like it or not, and there is a limit to what you can control. As soon as your business starts buying cloud based services on their own without consulting, you’re in trouble (unless it’s policy of course…).

Leave a Reply

Your email address will not be published. Required fields are marked *