| |
By Marc Stephenson
 SharePoint, SharePoint, SharePoint - as an information management professional, I can't currently move for SharePoint engagements and, considering the mighty Microsoft marketing machine ($billions) and the number of deployments to date (millions), it's easy to see why. I'm sure many of you reading this article will have had some exposure to SharePoint - most likely you are actually 'using' it in your organisation. The question is: is it actually delivering on its promises? Is it a panacea or a poison chalice? And why?
Before writing more, I need to say that I am not a Microsoft-basher. I use Microsoft products literally every day, including SharePoint, which to my company is its (virtual) office. Nor am I a Microsoft proselytiser. I think Microsoft products, like all others, have good and bad points. My assertion is that, because of the very nature of SharePoint itself, and its ubiquity, there are just too many bad implementations out there.
SharePoint as a defining technology
SharePoint is a classic case of a technology defining our information environment. For many organizations, its deployment changes the way users interact and manage their information environment. Only a few technologies have been able to do this since IT became commonplace in the 1980s (Microsoft, of course, has done this before with the PC).
SharePoint's raison d'être is its integration of different functional applications within one system, and the homogeneity of its approach to managing content. These are the features, I believe, that re-define the way many people think about information. There are many systems that do specific things much better than SharePoint, but none of them do it in such an integrated and uniform fashion. In addition, because SharePoint is a consumer technology (rather than an expert technology), it solves lowest common denominator problems, rather than specialised problems. Thus, the integration and homogeneity is at the superficial user experience level, but alas not at the deeper information architecture level.
SharePoint needs an Information Architecture
My direct and indirect experience of many SharePoint implementations has reinforced, to the point of absurdity, the belief that all information systems (the clue is in their description...) need an information architecture. We don't need to get carried away here - rigorously crafted, comprehensively detailed information architectures such as the traditional fileplan in a pure EDRMS, are a thing of the past. Similarly the newspeak of Web 2.0, folksonomies, etc. are also not appropriate because of their inherent informality and lack of rigour. The reality of developing useful, practical information architectures is actually somewhere in between - a third way.
This pragmatic view is alas much less interesting to feature writers and trend-followers, but it is much more important to users and cheque-signers! The weakness of the two extremes - design everything upfront and try not to change it, or just get on with it and fix it up along the way - have never been more sharply brought into focus than when developing SharePoint systems.
Too little Information Architecture
I'd guess that 75% of all SharePoint implementations are done without any information architecture whatsoever. This is typically because they are just deployed by the IT department pretty much in isolation from the business's information management requirements, usually because IT want to see what SharePoint can do (it's a new toy and it will look great on their CVs), or the head of IT thinks it will quickly solve some business problems (it might - eventually).
Often, organisations will install it because they got it for free with their Microsoft enterprise software license, so surely it must be cost effective to stick it in and use it? Without an information architecture, in all but the smallest organisation, this will at best result in a nicer looking way of doing what you already do, or at worst, produce even more information silos, less control and less usability. For example, simply replacing folders on your network with SharePoint Team sites for anybody who wants them, reproduces the chaos and lack of findabiity that you already have.
Too much Information Architecture
Of course, this situation is significantly rarer, but it does happen. Some organisations are so risk averse, that they architect too much, designing and planning for a perfection that can never be delivered, and is out of date from the second day of the project.
I have observed however, a growing trend for treating SharePoint in this way. I think the reasons for this are clear: there are now sufficient horror stories in the public domain that the late adopters see a highly prescriptive design as the solution. But too much can be as counter-productive as too little: we have merely changed the project's cost profile from low-then-high (too little IA - all the work is managing the deployment), to high-then-low (too much IA - all the work is designing the deployment).
Getting it right
The most efficient, cost-effective and user-friendly approach to designing the SharePoint environment should tread a middle path. One needs to do enough information architecture to cover those things that need to be specified up front to define a framework upon which SharePoint can be built, without being too detailed or inflexible. This is the art of a good information architect. In SharePoint, however, there are other (frequently hidden) challenges to overcome.
Much as we'd like to design thinking only about corporate strategy, user needs and the nature of the content, information architecture can never be truly technology neutral. This is never more the case than with SharePoint and there are some fundamental reasons why:
- Extent. With the exception of the big ERP systems (SAP, Oracle etc.), there are few off-the-shelf systems with such a wide and comprehensive set of functions.
- Integration. As has already been mentioned, SharePoint is very richly integrated with all its component parts, and even with non-Microsoft technology. The sum of the parts is much more complicated than the individual parts.
- Quirks. There are many of these! This is partly a result of the two points above, but also because the product had to ship. There are many perplexing omissions in the product but, for the SharePoint product managers, that's better than taking another year to fix them.
- Inconsistency. For the information architect, this is the big one. Again, because of all the points above, there are far too many inconsistencies - in the underlying information structures, in the user access model, in the navigation systems, in the administrative and configuration interfaces, in the application of functionality across the environment, and many more areas.
A Pragmatic Approach
Despite my criticisms, SharePoint can be delivered to good effect and experience has taught me a set of useful steps when approaching design and implementation. Many of these steps can be applied to any complex information system, but are especially apposite for SharePoint:
- Get some basic technology infrastructure set up as early as possible, but expect it to change once the business requirements are clearer. It's one less thing to worry about and, crucially, allows all the next steps to happen.
- Prototype first. Try some things out, see what it can do, experiment. This can take a while if you are new to SharePoint, so get experts to show you what SharePoint can do if you need a helping hand to start. Plan to throw the prototype away. Do not be tempted or forced to make it live. A prototype is not the same as the real thing. Use the experiences from the prototype, not the prototype itself.
- Define senior management expectations. What are they expecting the implementation to deliver, in particular what business benefits are they looking for, and how will you measure whether they've been delivered?
- Involve users as soon as possible. It builds buy-in, increases their understanding and gives crucial feedback into what they want and how they want it. Agile, user-centred methodologies work well with SharePoint - use them.
- Don't over-customise. This is the step that I've seen most organisations get wrong. There are many ways to customise SharePoint. Some are very easy, some are very hard. Don't do the hard ones (yet). You may want that button specific to be pink, but is it really essential and are you prepared to spend development days and ongoing management to get it?
- SharePoint is for life, not just Christmas. SharePoint going live is not the end of the work. It is a complex system that is likely to sit at the heart of your organisation. It will need ongoing technology, business and information management to avoid falling into disrepair, let alone extending and improving. Look to how many people run your email, intranet and Web site - SharePoint could be as complex and important as all these systems put together.
SharePoint is here to stay
There are good and bad features in SharePoint, just as there good and bad ways to implement it. However, too little information architecture will not support sharing and findability, too much will incur unnecessary costs and time. SharePoint is not going away - we're going to have to get used to it. For the next decade, it will be as important to users as the Office suite is today. Microsoft will continue to extend and improve it, IT departments will continue to install it but, hopefully, information architects will get the best from it.
By Marc Stephenson
Marc Stephenson is co-founder of the information architecture
consultancy, Metataxis. He has spent over twenty years in a range new
media, publishing and information management roles, encompassing
software development, business analysis, programme management and
information architecture. Marc's degrees in Computer and Cognitive
Science allow him a technical perspective of information management
issues, whilst still being information, not technology focused.
FUMSI articles by Marc Stephenson »
![[Get Copyright Permissions]](http://license.icopyright.net/images/icopy-w.gif "[Get Copyright Permissions]")
Click here for copyright permissions!
Copyright 2010 Free Pint Limited
Related articles:
You may also be interested in:
|
