SharePoint isn't an end in itself

I was at a conference this week - Knowledge and Content UK. I learned loads about knowledge management and content stuff, but also I learned an important lesson about SharePoint.

It wasn't really something I didn't know, it's just something that became starkly clear during the other stuff I was learning about KM. And it's all about having a clear vision before you start.

Now, I wasn't in my current organisation when they decided to implement SharePoint. And when I started, I had never heard of it. But as someone joining the project team, I was led to believe that the reason we were doing SharePoint was to have a better document management system and intranet. And also to improve collaboration. And also to improve communication. And also to foster a more open and transparent way of working...

Now, I'm not saying that we shouldn't have been aiming for all these things. But what we lacked was a real coherent vision. What exactly were we trying to achieve?

And the reason this came to mind at this conference was because virtually everyone who spoke mentioned SharePoint as one of many tools for achieving their KM strategy. And that's what it is - a tool. It's the KM strategy itself which seeks to change ways of working.

SharePoint is a brilliant tool for people who like to collaborate, and it offers them loads of ways to do it. But you need more than just SharePoint to change a whole organisation's way of working - to make them use a system that is so alien to what they've been used to.

You need a vision for the future.

So I think that's where we went wrong. We missed the point a bit I'm afraid. We gave the organisation a brilliant tool for collaborating, but forgot to make them want to collaborate...

Shall I just get a consultant in to do it?

There are a lot of SharePoint consultants out there. Seriously, if you lay them end to end I'm sure they'd reach the moon or something.

So if there are so many of them, organisations must be using them. And from what I've heard, they are. Relentlessly so. What concerns me is what happens once the consultants have been and gone. Who looks after SharePoint then? How much in-house SP skill do most organisations have?

We used a consultancy for the initial set-up, but after that we did everything ourselves. It's true we didn't know very much at the start, but we had a small close-knit team and we made mistakes and learned quickly. We were learning SP - what it could do, how it could be used - but most importantly, we were learning how to successfully implement it in our organisation. And as I've said before, the installation and launch is just the beginning of a long road.

The decisions you make as you travel along this road can and should be affected by the answers to these questions, and others like them:

What do people like about it?
What do people hate about it?
What are the tangible benefits for them?
How difficult do they find it to use?

The answers to these questions will be quite peculiar to your organisation, and will differ from person to person. Consultants can offer you advice on how to deal with getting 'buy-in' from staff, but in reality, you need someone who knows the organisation, and who can deal with all the different attitudes coming from different areas of it.

So, once the consultant moves on to his next job, make sure there are people in your organisation who know what they're doing with SP. People who can move the project forwards. People who understand what compromises were made in the initial stages, and why they were made. People who can provide training and ongoing support to staff. Otherwise, you'll end up with staff who hate it and no one to defend it.

Then people won't use it. And if they don't; project failed, simple as that.

I'm not trying to do consultants down. I've learned a lot from consultants, and there's no doubt they know SharePoint. Just remember, they don't know your organisation.

Customising SharePoint (to brand or not to brand...)

Some organisations have. Some haven't. I have heard a fairly standard argument for each side.

Against: The reason is generally that SP is an IT application, like Outlook, and you wouldn't put your branding on that, so why SP?

For: It's a corporate tool, and therefore should fit in with the corporate identity.

We chose not to brand or customise SP in any way. The point above seemed to be our official line, but in reality, the actual reason seemed to be that any kind of customisation would make an upgrade more difficult. We were of course implementing the 2003 version at a time when we knew the 2007 version was imminent.

Things are slightly different now. The 2007 version allows easier customisation - master page templates and CSS files can be changed in the browser and there is much more you can do using SharePoint Designer. This implies that customisation done on 2007 will not impact too much on future upgrades.

So, it's easier to customise now, so are organisations more likely to do it? Well, I can't speak for everybody, but we are.

We found that out-of-the-box navigation and look & feel, although much improved in the new version, is still not good enough for our needs. Also, where SP provides Themes, which can be a quick and easy way to give it a bit of a fresh look, they generally make content impossible to read. (Who ever thought that green text on a similarly green background would work?!)

So we're going down the route of a fairly simple customisation programme to amend the CSS and the master pages. Nothing too drastic, but hopefully something which will appeal to our users and make it a little bit easier to use.

Yes, it's just an application, but it's our application!

Training, Training, Training!

If you're the kind of person who picks up new technologies really fast, it may not occur to you just how complex a product SP is.

But don't overestimate your users. Most office workers are familiar with Word and Excel, but ask for anything more than that from them, and you're going to have to invest time and money in training.

We realised early on that the amount of training we were offering was nowhere near enough to allow most users to use SP effectively. And in almost all cases, the users hated the system (and avoided using it) until they understood it properly. Catch 22 then. You have to invest that time in order to make the implementation successful.

To give you an idea of how much training we offer:

• When someone new starts at the organisation, they have to do a 3 hour SP training session.
• We then offer a further 2 hour session for people to become a bit more advanced.
• Finally we offer two 2 hour sessions for people who will become Site Owners (those who are responsible for maintaining and updating their team workspace)

To a Project team starting out with a SP implementation, this seems like an awful lot of training for something that they themselves may have picked up very quickly. Believe me, it's not an overestimate, unless you're lucky enough to be implementing SP in an organisation which deals with technology and where your staff are all IT geeks!

We do all our training internally, but there are companies which offer training courses aimed at every level of SP use from User up to Developer. The only one I have experience of is Combined Knowledge, but there are loads out there.

I personally think the cost is justified to make sure your Project Team is completely at one with SP, but if you were going to send all your users on an external course, the cost would likely be prohibitive. Better to employ a trainer for 6 months, a year, 18 months, whatever you think, as they can then support users on-site and make sure that people really are using it properly.

In short, plan for a certain amount of training per person, then double it!!