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

How do you know when you’ve done enough?

The other day someone asked me an interesting question:

How do you know when you’ve done enough analysis?

I’m not really sure how to answer that one.

Sometimes you are forced to stop when you run out of time. But if time is your only guide you risk ending up  with something too vague to be implementable. Which means someone has to make quick and dirty decisions about how to implement it. And that’s a fast route down a short road to a lack of business buy-in. A short road too many of us have been forced down by sponsors who care more about delivery than quality or by project mangers who confuse analysis with planning on the one hand and specification on the other. No bitterness here, then.

The perfectionist’s answer is that you stop when you’ve nailed down every last detail. But that way another kind of madness lies.  Over-specification produces inflexible processes which cannot accommodate the unexpected. Remember those early web forms which required “Zip Codes” to be numerical, and therefore couldn’t be used by people outside the USA? Over-specification also infantilises the people using the process, which may or may not be a good thing. And it can give you processes or requirements that are just plain wrong unless the detail has been provided by practitioners.

But it’s usually lumpier than that because there’s never time for infinite detail. The bit that’s easy ends up being over-specified but the hard stuff is still vague, as exemplified by my favourite systems diagram:

Good work - but I think we might need just a little more detail right here

This of course is why we use tools like use cases and swim-lane diagrams to impose standards, drive out that ambiguity and ensure we have detail where we need it, but not where we don’t.

In the end it’s a judgement call. You use your tools, consult the business, trust your developers, empower your users, and deliver on time.

In the words of Albert Einstein:

Make everything as simple as possible, but not simpler.

Make everything as simple as possible but not simpler. Albert Einstein.

The song that’s been driving through my head as I type this is Don’t Stop Till You Get Enough, which is eerily appropriate in so many ways. The difficult thing, as Jackson himself illustrated so clearly, is to know when enough is enough.

The Business Analyst: Facilitator or Designer?

Craig challenged me on the role of the BA recently.  I said that Web 2.0 is something you can only understand in practice and he posted:

Having said that what do you say to the role of the professional Business analyst; the person who doesn’t use the system but makes many of the key decisions about what goes into it?

It’s a good question and one I’ve been mulling over since he asked it. For the sake of brevity I’m going to park the generic question ‘what is the role of the Business Analyst’ and the vexed issue of whether or not the user should be the primary arbiter of what goes into a system.

Users do know about user experience.  One of the things I like about Lean Interventions is that you go to the people enmeshed in using the process and get them to re-design it.  If a BA has a role in this, it’s as an educator about Lean principles and as a facilitator. The BA does not design the process, the people using the process do that.  I should probably also mention focus groups as a way of involving users in the design phase, but I can’t really comment since I’ve never worked in that way.

But users are rarely available. In my career to date the actual end user has rarely had a seat at the table because with web stuff the user is quite often outside the organisation.   The Business is frequently the proxy for the user, and the Business is sometimes the team sponsoring the system, but it can also be a programme team whose expertise is in change not the system they are changing.  Either way they are representing the user, which brings us back to the underlying question:

‘is it possible for the user to be represented by anyone else?’

After thinking about it for some days and toying with this post for several hours, I think the short answer to that one is: Not always, but that is what use cases ¹ are for.’

So what to do about it?

I’ve mentioned focus groups, though I’ve not run any myself.  But let’s hear a shout out for prototypes and pilot studies here. Oh, the difference when you prototype a user journey! It’s like having a mystery shopper before the shop has opened. The great joy of a prototype is that the thing comes to life and suddenly everyone involved can have a go at being a user, and pilot implementations tell you where the weak spots are. This is closely linked to O’Reilly’s perpetual beta of course, and is also why Anything 2.0 is better than Anything 1.0.

Craig didn’t ask whether the BA could represent the user, he actually asked:

What do you say to the role of the professional Business Analyst?

I think my answer is that the BA should be a facilitator not a designer.  The facilitator enables the Business to produce a design that IT can use whereas a designer does that for them.  (Other operating models are available). It’s the BA’s job to use tools like use cases and prototypes to help the Business represent the user. That doesn’t mean the Business will do a good job of representing the user, but it’s a step closer than if the BA tries to do it. And even so, it’s a tad idealistic. At times the Business Analyst who’s a facilitator has to make calls that affect the design, but I think that’s something that we shouldn’t do by default.

As  you can see, Craig’s question gave me pause for a considerable amount of thought, a lot of it typed directly into this post and most of it cut straight  out again.  To pull it all together:

• Organisations deliver user-aggressive or ineffective systems for a myriad of reasons which include
  • organisational culture during the design stage resulting in a lack of user representation
  • pressures of time and cost
    which frequently result in
  • methodologies which lack rigour, in particular sloppy requirements definition and sign-off
• Good design requires holistic systems thinking (that’s one for the buzzword bingo) which incorporates the user’s point of view
• Only users are users, but tools like use cases, user journeys, prototyping and testing get you closer
• Ideally, the BA’s role is as a facilitator rather than a designer
• The local challenge is whether you
  • go directly to the user (eg a Lean Intervention)
  • allow the Business to act as a proxy (so much of my life to date)
  • use a prototype, or focus group or pilot study (love those)

I’m quite surprised Web 2.0 evangelists aren’t yet hypothesising Open Source Organisation Design which would be well wiki’d.

(Boom boom).

O’Reilly says ‘Users must be treated as co-developers’ which takes open source software build on into open source software design. If he or anyone else has taken this idea into the realms of open source organisation design and I’ve missed it, please drop a link in the comments.

---

1 – a Use Case is – for want of a better term – a scenario: ‘A white horse walks into a bar’; ‘A funny thing happened on the way to the theatre’; ‘Writing a blog, (what’s that all about)’. A use case can be large: ‘Government bails out banks’ or small ‘Customer buys a bottle of milk’.  If you want a less flippant definition, here’s the one from Wikipedia. But much better to go back to post

---

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?

The Good, the Lean and the Ugly

My car was written off a few weeks ago.  The insurance claim made an ironic conterpoint to a Lean course I went on the same week.  

“Lean” isn’t an acronym, though it sounds like one.  It’s a description of how Toyota make their cars.  They don’t waste a thing: not time, not effort, and certainly not materials.  No fat: it’s all lean.  Lean is about a lot of things, but ultimately it’s about cutting out waste and making sure that each step in a process explicitly adds value for the customer.  

There’s a lot that I really like about Lean, for instance it assumes that the people who operate a process know more about it than anyone else.  Who’d have thunk?  

I don’t want to turn this into a whinge-fest about my insurance claim.  You’ve been there, you know what a nightmare it is if your car is totalled by three unknown lads in a stolen transit.  

However it seems entirely ludicrous that I ended up with the notes from 15 phone calls made to four different companies on my pad, and those were only the calls when there was something worth noting down. And why four companies? Why was I  the one co-ordinating the insurance claim itself, the legal claim for uninsured losses, the loss-adjustor’s valuation, the purported hire car while the claim was settled and the other purported hire car while the claim was settled?  Actually, that’s five companies, isn’t it?

Breathe in, two, three

Breathe out, two, three

Think of Calm Blue Light

It made an interesting case-study on the Lean Course, and I wonder if there is money to be made creating a “Lean and Mean” accreditation for organisations.  If an insurer could prove they had a Lean Claims Department, it would make me choose to use them.  

Just one phone call to sort out a claim?  Who wouldn’t go for that?

More on Lean: 

• The Machine that Changed the World – the original book on Lean published in the 1990s
• Wikipedia on Lean Manufacturing
• Wikipedia on Lean Software Production