Case Study: Creating a SharePoint service

This post was written in 2010 or 2011, but sat in my drafts folder for a couple of years. Enough water’s passed under enough bridges for me to dust it off and publish it now.

I was reminded the other day how important it is to get the questions right when I caught up with a pal at the Contractors Reunion Ball¹.

He told me how the right answer to the wrong question had produced internal tension within a service delivery team for over a year so that the service they delivered scored ‘6/10 – could do better’ but no-one could work out why.

This is a story about SharePoint. All you really need to know about SharePoint is that anyone who runs a blog can understand how to set up a SharePoint site. Rocket science it ain’t unless they make rockets out of widgets these days. However there is a huge difference between doing it and doing it well and hereby hangs the tale.

The service team’s job was to help the people who used SharePoint in the organisation to get the most out of it.  They provided the skills to bridge the gap between having an empty SharePoint site (a site address, a welcome page, a place to store documents and another to store pictures) and a fully configured SharePoint site which is more or less whatever you want it to be.

Two levels of service were clearly needed and during the year this story covers, the team discussed what these two levels of service were.  Were they

• templated sites vs custom-build sites
• off-the-shelf vs bespoke
• off-the-shelf vs configuration
• standard sites vs project work
• simple vs complex

The service went live with two services based on a couple of customer scenarios or use cases.

• collaboration and
• gateway

A collaboration site would be a place for a team to work together, co-ordinate holidays and manage their workloads.  A gateway was much more one-off, it would be a mixture of shop-front, shopping basket and check-out.  The team expected to be able to deliver a collaboration site and walk away from it, but they knew that gateways would require weeks of consultation, configuration and user-testing.

However more and more people asked the collaboration team for advice because – guess what – they wanted to do do other stuff with SharePoint like publish process documents or whatever. So the team ended up with three de facto services

• delivering templates
• one off consultancy
• gateway projects

This meant that the team were delivering a stellar service but failing to meet their yearly objectives and their work wasn’t recognised because they couldn’t report it to the service owner.  It also messed up who reported to whom within the team.  Meanwhile, the customers of the service were confused because there was no formal way to ask for the advice they needed.

The team muddled through, as teams do.  There was an intermediate service design built around the way the sites were actually used, which was more or less like this:

• collaboration templates
• document repositories
• gateway projects

But the tension was still there because highly skilled customers were building their own gateways and customers with cash but no staff wanted fully-finished templates.

Despite that, the team played for a while with an even fuller offering based around more customer scenarios (use cases) but still it didn’t work.

Eventually, it dawned on my pal that the distinction wasn’t what the customer wanted SharePoint to do, it was what they wanted the Team to do, and there really were just three services:

• Empty template with some rules, standards and help files
• Occasional advice and QA
• Full delivery

The problem, he said, was that the wrong questions were asked. He jotted them down for me:

1. What does the organisation want SharePoint to do?
2. What templates can we create?
3. What skills do we have in the team?
4. How complex are the customer requirements?
5. What does the customer want SharePoint to do?
6. What does the customer want us to do?

He said that it wasn’t until they had got to question #6 that they could finally create a service that was fit for purpose.  As I rather cruelly said to him, ‘ask a silly question you’ll get a silly answer’ and as he replied, nursing his hangover the next day, ‘hindsight’s a wonderful thing’.

---

1 – Ladies and Gentlemen, please welcome Mr and Mrs Net-Developer and their daughter Dot…. Net-Developer.

I guess you had to be there.

Return to top

Selling collaboration services within an organisation

Selling collaboration services and development services within an organization? – Art Gelwicks recently posted this as a question in the SharePoint Users Group on LinkedIn, and I found myself writing more than would fit in a discussion forum. So here it is.

Are you selling ‘bottom up’ by putting SharePoint out there and letting people use it spontaneously, or are you selling ‘top down’ by finding a sponsor with a requirement and using SharePoint to fulfil it?

There are pros and cons to both. The keys to working out these pros and cons for your organisation are

• culture
• use cases and
• champions

Culture

How your organisation takes to SharePoint depends in part on the culture. Some cultures are enthusiastic about collaboration tools like Instant Messaging, Live Meeting and SharePoint, and others see these sorts of tools as time-wasters. Here’s how to work out which one yours is.

Goffee and Jones do a great 2×2 for the culture of an organisation. They say that the glue that enables a team (department, company) to work together is either sociability or solidarity; organisations with high sociability scores are ‘networked’ and organisations with high solidarity scores are ‘mercenary’. There’s more to it than that, their book is very readable and includes diagnostic tools.

I have seen people in departments where the glue has been sociability take well to the collaborative features of SharePoint like discussion forums, alerts, review workflows and MySites. I’ve not tested this, but if your organisation is networked (and read Goffee and Jones to decide if it is) then a bottom up approach would probably work well. Look out to see whether the people are already comfortable with tools like Instant Messaging and LiveMeeting, whether they are active on Twitter, LinkedIn and FaceBook, and whether Monday mornings start with a chat about the weekend. This isn’t about people who are early adopters of technology, it’s about people who like technology because it is a social and work enabler.

By contrast I have seen people in ‘mercenary’ organisations who are so busily focussed on deliver-deliver-deliver that they don’t have time to ‘waste’ learning how to use a new tool like SharePoint. In an organisation that’s mercenary (again read Goffee and Jones – they mean it in a particular way) you need a sponsor and a project. Work out what your sponsor’s driver is and fulfil it. They may want to cut down storage costs, or improve a specific set of working practices, or control the published versions of training material.

Find a sponsor with a specific need and fulfil that need.

Rinse and repeat.

This brings us on to:

Use Cases

One of the problems with SharePoint is that it’s a swiss army knife of a tool – useful for such a large number of things that it’s hard to stay focused on just one or two. In a ‘mercenary’ organisation the problem is handled for you – your sponsor has a specific task and you focus on that. The challenge is in the ‘networked’ organisations where everyone who comes across SharePoint wants to play with it all, now, as soon as possible, shiny, shiny, new, cool.

Rolling out the whole of SharePoint across the whole of the organisation is a distraction for them and a management nightmare for you. You need to identify a single use-case, but it is much harder because there isn’t a single obvious business requirement and there may not be a single sponsor. Worse, you may have a sponsor who has a vague vision like ‘collaboration’ or an unrealistic one like ‘getting everyone to use their My Site like an internal FaceBook profile’.

If you are going bottom-up you need to roll out solutions to one or a maximum of two use-cases at a time. To find out which one, put together a survey and ask what stops people collaborating well right now. Word it terms of how they work, not in terms of the SharePoint features so:

• full mail-boxes – not – emailing urls
• ‘shared’ drives you can’t share – not –local control of permissions
• documents you don’t know are out of date – not – control over the full document life-cycle
• keeping track of document sign-offs – not – workflows

Pick one of the popular ones, create a simple solution, and run with it.

Let’s read that again.

Pick one. Not a couple because they’re similar. Not three or four because Internal Communications want them (that’s your sponsor-and-project scenario and a very nice place it is to be too). Not two or three variants to cover all the bases. Just one.

Create a simple solution. Yes, there are half a dozen different ways to build and display a discussion forum in SharePoint. If you can’t tell which one works best, then put together one that works well and stick to it.

Then run with it. Get it out there. Get it used. Get comments and feedback. Improve it.

Only then move on to the next one. Bite size chunks. Could be as close to a month apart, but bite size chunks for you and your users.

The subtext here is simplicity. Turn off the ability to make subsites, remove most of the templates, switch off the themes. Lock it down. Shut it down. SharePoint is a casket of magical delights. You can always open a lid you’ve kept shut, but it is much harder to shut down a lid on something you’ve left open. SharePoint baffles new users and new organisations with choice. Lead them step by step through those choices.

And finally:

Champions

People like SharePoint. They really like SharePoint. Not everyone, but enough.

These people who like SharePoint are your friends. They are natural evangelists, experimenters and testers. They’ll pester you for the features that you’ve turned off, and they’ll come up with workarounds that’ll have you blessing and cursing them by turns. But they’ll promote it and provide free consultancy to their co-workers and come up with solutions to problems you didn’t know existed.

Really work your champions. Create a user forum and refuse to answer questions unless they are posted there. You’ll feel very prissy, but your Champions will gravitate there and get to know each other and do half your support work for you. Invite them to do in-house webinars on cool things in SharePoint, (20 minutes demo, 10 minutes Q&A). Create a SharePoint community of pratice with these people at its core. Take their advice on how to move your service forward.

So, how to sell collaboration services?

They key is asking the right question; in this case not ‘how do you roll-out SharePoint’ but ‘what does your organisation want to use SharePoint for?’

Oh, and bite size chunks.

Always bite size chunks.

---

When you have a hammer, everything looks like a nail

To what extent do the tools we use shape how we think? If we habitually use a certain set of tools, do they prevent us thinking outside their very own box? For example, if I use PowerPoint or Word in Outline mode I can really only think in bullet points. So if I want to move concepts around and see how they relate to each other, then I need Visio or the drawing options in PowerPoint, or even post-its and a whiteboard.

Anyone who is paid to think should worry that the tools they use impose boundaries and blindspots on how they think.

Recently I’ve been using SharePoint a lot, and one of the features is the ability to create categories or assign property to your information. You probably use properties instinctively already. For example, if you want to find an email from a specific person you click on the top of the ‘From’ column and the senders’ names show in alphabetical order. Know it came last week? Date is another property: sort by date. SharePoint lets you do the same thing, but you can create your own columns (categories, properties … whatever).

I use SharePoint a lot and I help people define columns a lot. It’s got to the point where I spot categorised columns in places where SharePoint has never been:

Meat / Sauce / Carbs

Categorising information in this orderly way is now a habit. It is also something I am good at, since I am blessed with the ability to spot a category error at 60 feet.

I'll have a tall skinny loft apartment with roses above the door

But what worries me is whether this habit of defining top level categories imposes its own blind-spots. If everything I eat is “Meat / Sauce / Carbs” then how can I have ice-cream for desert?

These blind-spots don’t matter as much if you can get enough eyes to look at the problem. But you know and I know that you can spend all day in a workshop and come out with nothing but a biscuit-rush and a headache.

A good, nit-picking, sceptical colleague who’ll give your final documents a really good going-over is invaluable.

We also underestimate the value of sleeping on it: model it visually on Friday and then on Monday write it up in words.

Now I’ve written this post, and now that you are reading it, this all seems rather obvious. But when you’re under pressure to deliver it’s quicker to do the same-old same-old than it is to think outside the toolbox. And that’s ok if fast really is more important than right, which sometimes it is. But sometimes it isn’t.

So when was the last time you used a different tool and looked at a problem in a slightly different way?

Wiki vs Word

I had a colleague who banged on and on and ON about wiki-documentation. His point, and it’s a valid one, was that all IT systems documents should be wiki and anyone entitled to read a systems document should be entitled to update it.

He’s right of course, culture and software permitting:  it wasn’t revolutionary when he propounded it 4 years ago and it’s even more obvious now.

In fact we did this for years without the need for Web 2.0 platforms. Almost all corporate documentation is multi-authored and multi-layered.  Click File>Properties on any word document from your corporate intranet (the expenses claim form, the new starter’s induction pack, whatever), and you’ll find out when and where it was first written.  These documents are are like DNA code, with sentences left over from the Paleocene switched off and invisible but still tucked away in Track Changes, and with other bits added in fresh and shiny and new today.  I use a timesheet first put together in 1998, it’s fit for purpose, so it’s survived.

Two recent examples brought this into focus for me:

I’ve been working on help files which have been through three incarnations that I know of since they were written in 2006, and some of them were copied and pasted from elsewhere before we got hold of them. A phrase here from 2006, some bullets added in 2008, a shiny new screenshot now, and here you go.

Likewise the training material I’ve been reviewing today has edits from numerous other people and the properties file shows it originated outside both the company I work for and the company we bought it from, and a lot of the wording reads like sales brochures for the product in question – not hard to work out why.   (I should say here that I know the purchasing path, and this material has been re-used and changed entirely legally).

So the benefit of Wiki software is not that it allows us to steal and plagiarise (I mean ‘allows us to re-use existing intellectual capital’ of course).  We do that already without special tools.

No, the benefit of Wiki software is that it lets us track who’s added what.  It is certainly a benefit: it would be nice to know what fool messed up the formatting and lost me 5 hours of my life sorting it out.  But to some extent that’s just prurience: I’m as interested as anyone in checking back through the Wikipedia articles I’ve edited to see how they’ve developed since.  (You mean you don’t do that? You should!  It’s fascinating, in a bin-searching stalkery kind of way.)

Once the prurience is over, the only real benefits of actual wiki software are the ability to revert to a previous version at the touch of a button, and to hold people to account. Don’t get me wrong, I’ve served enough time in governance and business controls functions to know that these are real benefits.  But people have been stealing each others’ stuff – er – working collaboratively over time – for years already without Web 2.0 tools to help them.

Towards a corporate hierarchy of needs

Most of us are familiar with Maslow’s hierarchy of needs which suggests that we prioritise bodily needs over security, our sence of belonging over our own self esteem (which is how peer pressure works) and that we won’t tackle the things that fulfil us until the rest of our needs are met.  

What is discussed less frequently is that organisations have a similar hierarchy of needs, and that organisational focus shifts in turbulent times.  

As I understand it, Donald Marchand suggests that organisations focus their attention on information like this:

1. Minimise risks
2. Reduce costs
3. Add value
4. Create new reality

This is a sequence I recognise, in large organisations at least.  Mind you, it seems to me that small organisations and entrepreneurs run the sequence in the opposite direction.   Maybe that is what makes them entrepreneurs.

Marchand presents it diagramatically thus:

I’ve not yet read Marchand on the subject (I came across the idea in an excellent book on Taxonomies by Richard Lambe).  I need to go to the source to understand the details of he is saying, why he has drawn it like that, and whether or not I agree with him, but this a useful thought-provoker, and may also be helpful tool for working out where strategic attention is or should be focused.  I’m tempted by the tabloid thinking which suggests the banks’ sudden attention to risk is because they spent too much time in the previous years creating a new reality in terms of mortgages-repackaged-as-“securities”.   It’s tempting, but I think there’s more to it than that.

Marchand’s framework is about knowledge.  Lambe, who references it, thinks it misses out two important areas of corporate knowledge, specificially: strategic planning and talent management.    As I said, I’ve not yet played with the framework, so I’m reserving my final judgement.  

However, translating the hierarchy of needs from people to organisations is something well worth doing in these interesting times.

---

Sources:  

Lambe, Patrick Organising Knowledge: Taxonomies, Knowledge and Organisational Effectiveness. Oxford: Chandos Publishing. 2007.  

Marchand, Donald, (ed) Competing with Information: A Manager’s Guide to Creating Business Value with Information Content. Chichester: John Wiley. 2000.

Wikipedia: Abraham Maslow.