The Right Way, the Wrong Place
SharePoint 2010 as an upgrade and new collaborative technology platform is here; brand new; shining with feature-sets, clean with many new things users can do.
Those considering the push of moving their SharePoint 2007 environment(s) over could of course do this since there is a plethora of articles explaining in detail how to get the MSI, configure this, change that, and following an installation have a new SharePoint environment – job done.
There is the syrup, tasty as it is that draws people into making the jump and this is done simply because – hey there’s a new SharePoint version out, lets install it, and using the blinding the client with features ploy.
Problem is that users those people generally do that in a land of no IT roadmap. SharePoint 2010 sits in a sea of connected technologies, and nothing is more important in this than the desktop tools. In this article, I will only refer to the Office 2010 suite since that is the preferred connected desktop suite. This suite forms the client applications that “glue” SharePoint 2010 services. Typically, people would use these as their “base” of operations. For example, Microsoft Outlook is perceived as the centre of the universe to people and its clear of that connectivity feature set to SharePoint 2010.
If the clients’ IT roadmap does not include these technologies, and there is no work done to identify where they may sit, SharePoint is not considered future-proofed, and the users would not have a full understanding of the true capabilities of SharePoint 2010 and what they may wish to do with the platform.
There is an argument amongst Project Manager and SharePoint Architects, stating there is no real need to investigate or include Office 2010 on any roadmap when it comes to SharePoint 2010, going even as far to say that it would be unlikely that the client would ever move to Office 2010. Arguments include stating that the client is perfectly happy with the desktop tools they have, and SharePoint 2010 should be able to integrate with what they have. In other words, they have perceived the ‘right way’ of marking Office 2010 desktop applications as secondary to the implementation of SharePoint 2010. After all, SharePoint 2010 is king, because users want a website, so lets’ give them a website, right?
So, how did they come to make those decisions? Is it because they have looked at the new desktop version and compared it with the current? Maybe its because its far too costly to consider an upgrade? Or perhaps its because the interface is so different to their current version that it may ‘scare’ their users and pile on too much pressure on them to learn yet another set of tools?
There could be many reasons; they key though is the desire to keep to the term “bleeding edge” technology. I think this presents a right way, wrong place approach to adopting SharePoint 2010.
I’m going to put myself on a limb here, and state that “bleeding edge” means “catching up”. Bleeding edge is a strategy used to ‘prevent’ adopting the latest set of tools; classifying itself as a conservatively “easy” and “safe” place to be when faced with the prospect of adopting new versions of software. In days past the pace of software development made this comfortable since desktop suites “kept themselves to themselves” – there was little interfacing with products outside of those suites, particularly web based products.
Therefore, strategy dictated to stay at a level “comfortable” with the users (and the purse). There were other reasons, for example, the release mechanism of applications and the ease of getting the alpha, beta versions of these suites. In the past, this was restricted to a large degree. Unless you were a member of a special subscriber group you wouldn’t get a look-in to new products. Testers were selected and sometimes made to sign NDAs (Non Disclosure Arrangements) etc.
Nowadays, things appears to be more relaxed, meaning, that its’ easier to get these suites and start using them for testing purposes. Additionally desktop applications are getting closer and ever closer to the website. SharePoint 2010 has the Office 2010 toolbar on top. This is obviously an intentional move to make it look like Office desktop tools version 2010 and 2007. SharePoint 2010 specific collaborative features that connect it seamlessly with Project 2010, Visio 2010 and Access 2010. For example, going back to the wonderful world of forms design in Microsoft Access versions, imagine that now you have the ability to create sites using Access 2010?
The integration does not stop there, just looking at options in Office 2010 you will start to see more and more connectivity options targeted specifically at SharePoint 2010. Just the other day I was asked about SharePoint 2010 Workspace. Now, this is a rather cool application that allows you to take information offline from a SharePoint 2010 site, work on it, then have it syncrhonised back to the site it came from. Wait a Minute – itsn’t that Microsoft Groove? Yes! That’s an application that when it came out wasn’t didn’t get so much of a look-in, because the strategy was not web bourn, it was desktop bourn. Now look where we area.
So, this all adds up to a prospect that rolling out SharePoint is no longer a ‘single’ matter; no longer a ‘single’ project. Requirements from the client is swinging from the “We need a website to put stuff in” to “We need to be more productive when using our tools with SharePoint”. SharePoint 2010 projects are now full fledged programmes, whose objective is the roll out of a full technology refresh in one fell swoop. However, this “one fell swoop” is a highly complicated affair utilizing multiple projects; you need to have an extremely capable programme manager to pull that off.
Hence, all this means an exciting prospect for SharePoint fans. Now the work really beings, mapping SharePoint to a vastly connected and complex client process is a demanding and challenging task. SharePoint Architects now need to be even more proactive; the connection between SharePoint and external technologies is refined and even better structured. SharePoint 2010 allows this to happen, providing a massively open architecture and feature set.
To complete this article, in summary, SharePoint 2010 needs to be seen, understood and prioritised into the client organisation as the most important centralized technology. The right time to do this is at the beginning; right at the proposal stage this needs to be set into the mind of the client. Ensure the client understands what means to collaborate using desktop tools is and how they are used to enhance that.
The wrong place to attempt this is in a organisation where the culture does not wish to consider the Office 2010 desktop as part of a SharePoint 2010 requirement and/or the technology work does not invoke sharing / collaboration and/or the client does not have the vision or desire for technology refresh or review their ‘bleeding edge’ desktop tools.
