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

My new year’s resolution: no more effing flies

How important is presentation? Does it matter what your work looks like so long as the thinking is sound?

It’s all in the context. I’ve worked in very large organisations where high standards of accuracy, detail and presentation were the norm. I work now for a company which is smaller, more entrepreneurial, fleeter of foot, and where what matters is the message not the medium. Some environments – academic, technical and medical for example – take great pride in making sure their presentations don’t look “too corporate”.

Accuracy matters in Great Big Organisations (the ones with customers in the millions and employees in the tens or hundreds of thousands) because of the way that scale multiplies the effect of errors. Herding 10,000 cats (pcs, people, pension payments, whatever) is not just 10 times harder than herding 1,000 of the wretched things. It’s nearer 10 to the power of 10 (or 100) times harder. Trust me, I’m a cat.

Detail matters in these behemoths because the systems are too big for one person to understand them, while completeness matters because people cycle in and out of the two year and three year change programmes taking their knowledge with them. Documentation is the baton that passes the knowledge from one team to another.

But the reason presentation matters in these modern-day Versailles is not because it contributes to profit or effectiveness, it is because your credibility is on the line: an obsessive focus on presentation standards is a product of power imbalances. This makes it understandable in companies with corporate clients; in fact some consultancies have entire teams whose job it is to take a document and make it look beautiful. Institutional clients judge the book by its cover and assume that a lack of effort in the sales process indicates a lack of effort in the delivery.

But where is the value-add in highly polished work when it’s only being done to negotiate internal fiefdoms? I am talking about work-places where people use phrases like

trying to get traction

socialising the idea

getting face-time

and

executive buy-in

I have spent weeks of my life polishing slide decks while I waited for my five minute slot in front of – say – the Heads of Strategic Operations Support at the monthly Governance Committee Change Review Meeting after next.  Where is the value-add in that?  I found it comforting, mind you. It meant I’d done my best and wouldn’t be damned with the faint praise of “could try harder” in my next 360. It also meant that the Heads of Strategic whatever whatever were less likely to find something to criticise in my proposal. And – best of all – it looked and felt like work and didn’t require much thought.

Don’t get me wrong, some aspects of polishing do add value.  I am hot on spelling and grammatical correctness because they reduce confusion and stop you annoying your reader. When a colleague who translates everything they say to me from French to English in their heads and says

We are giving the test scripts to Pete so we can test him

I have to remind myself it is the system we are testing not Pete. My French colleague is entitled to make grammatical errors in English, but anyone whose first language is English has no excuse. Good grammar and spelling mean that what you say doesn’t get in the way of what you mean.

But when we get down to that extra round of refining and polishing, what a Danish friend of mine called

Fly f***ing

how necessary is that?  Fly-f***ing is when you move a comma from one side of a word to the other because you’ve revised the damn thing to death. I’m fond of the term, but the English equivalent isn’t as blue. It is:

Nit picking

And clearly, no, messing with insects doesn’t add value, outside the situations where professional credibility affects the bottom line. Quite the reverse: I have discovered with joy that stopping when you’ve got the meaning down is a great way of clawing back some time.

PS – I’m fascinated that just thinking about Great Big Corporates has re-jargonised my language.  Have a link.

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.

When words are not enough

This is a simple plea for mixed teams and visual tools.

I once asked a friend if he dreamed in colour or black and white, and he said ‘neither, I dream in concepts’.   By contrast with both of us, many post-modernists  seem to believe that thought can only be verbal, but that way madness lies: The only validity of 1+1=2 is as a representation of words, and ‘one plus one equals two’ is a social construct.  Oh dear.

I challenge this doctrine that the Word is god.  When I want to work out how things relate to each other I find words are completely useless. They are are ok for communicating concepts (sometimes) but often I find them bad for uncovering concepts, and they are next to useless for working out how things relate to each other.

Years ago I learned a consultancy or counselling exercise whereby you or the client list(s) all the factors on 3x5s and the client organises them in groups on a table.  It is great for aggregating things together.

The house is a mess, the dog has fleas, the kids are in trouble for losing their home-work, and you’re broke because you’ve been buying lunch at work all month.

Write ’em on cards and put them all on the table along with everything else, and suddenly there’s the Eureka moment: the common thread is being short on time.  Deal with that and the other problems melt away.

But until you get the chance to move them around and play them off against each other, you think you’ve got dozens of impossible little problems, instead of one or two larger  ones.

There are many variations on this, and it’s used formally in a lot of project planning workshops for grouping activities into work-streams and blocking them out in time.

The pure gold in this approach is its value in working out the relationships between things.  You can do  on whiteboards, you can do it with cards, you can do it with post-its.  These days I am lazy, so I do it in PowerPoint or Visio. The point is that it’s a process, you won’t arrive at the finished diagram in five minutes, but the very activity of moving things around, like blobs in a lava lamp, will enable your thoughts to coalesce and clarify.

This isn’t just a post about tools, though. It’s saying that there are some conclusions you will never arrive at if you stick to words.  It helps to understand how your team think.  NLP divides thinkers up between the auditory, the visual and the kinesthetic.  I am increasingly doubtful about this, and find it more useful to place them within a venn diagram with circles for the numerate, the verbal and the visual.

Get one of each on your analysis team and so long as there’s no explosion, you will really be cooking with gas.  And I’ve said it before and I’ll say it again: if you get stuck on a problem, change  your tool.

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

---

Re-validating the wheel

Crop Circle Swirl (from Wikimedia Commons)

Here’s a bit of fun for a Friday. Somewhere deep in our genetics there’s obviously a need for answers.  I should give that a capital A really.  Somewhere deep in our genetics there’s obviously a need for Answers.

Answers are good: when you know the answer to a question you can move on to the next one.   That’s how progress works, by not reinventing the wheel. Newton stood on the shoulders of giants, and all that.

However, there is a danger in this.  Sure, no-one wants to waste time re-inventing the wheel but we should certainly revisit the blue-prints every now and again.  If we didn’t, we’d still be burning witches because we’d settled for a crude and inaccurate answer to the question of why a single woman might prefer to live by herself.

There’s a sequence of thinking that goes something like this:

We don’t have an explanation for crop circles…

… so we say “it’s a mystery” meaning we haven’t yet found the answer …

… which is an un-answer: it is an unanswered question to ponder or to research or to put on one side until more data is available …

… but people don’t like un-answers,  so they answer the question, saying “it’s a Mystery” (meaning aliens or ley lines or the Ancients) …

… and the question’s been answered and doesn’t need revisiting because it is a done deal …

… but it’s a non-answer which shuts down debate …

… so when we get more knowledge, and it turns out to be two blokes and a plank of wood …

… only some of us say “ah, the mystery is solved” while others say “No, no, no! We knew the answer already.  It’s a Mystery”.

The difference between answers and non-answers is invidious.  They can be hard to tell apart because they both feel like closure.  The wheel’s invented. Nothing to see here. Move along now.  By contrast, un-answered questions itch and scratch and nag and gnaw away at us; and that’s good, that way progress lies.

Many invalid assumptions are based on non-answers masquerading as answers. We have to check that the wheel we are using has an axle in the middle. Questioning those assumptions helps us root out the non-answers. But it is uncomfortable because we then have to live with those itchy, scratchy, nagging, gnawing un-answered questions, and keep them open, keep on asking them, possibly for ever. We have to be willing to live with not knowing all the answers about what Tim Minchin calls ‘this beautiful complex wonderfully unfathomable natural world’.

Ach, he puts it much better than I do, and this is the Friday Fun that I promised you, though I worry about the red wine and the white carpet.

Enjoy:

---

Like this post? Share it:

‘Things done’: as important as ‘Things to do’

If you’ve got a lot on your plate, it is all too easy to get to the point where you cannot think of the task in hand because five or ten other things nag away at you saying they need to be done Right Now.  This more than just having a lot to do like the Red Queen in Alice who runs as fast as she can and stays in the same place.

Alice and the Red Queen

This is the state of confusion, where stuff we haven’t yet got to looms larger and larger.  We get into the state described in the general confession in the Book of Common Prayer:

We have left undone those things which we ought to have done … and there is no health in us.

This confusion is about priorities. To give you an example: many years ago when first worked from home, I was only contracted to work 15 hours’ each week. Easy enough, you would think, but I still got into this state of confusion. I was racked with guilt while I worked because I was at home and therefore should be doing housework, but the moment I started on the housework I felt guilty because I should be working. That state of confusion is made much worse when there actually is too much on your plate, of course.

Alice and the cards

One way to break the cycle is to give yourself credit for the things you do get done.  At these times I make a things done list as well as a things to do list.  Of course, you should do all the standard time management stuff like differentiating between what’s important and what’s urgent and prioritise accordingly, and turning off your email and your phone.   (Things have to be pre-apocalyptic for me to turn off Instant Messenger).

So here goes.

Last week I:

• went to the doctor and dentist which had been nagging away for ages because both were important but neither were urgent
• switched electricity suppliers and bank accounts
• dealt with a stack of post THIS high, and turned it into a stack of recycling this  high and a stack of filing this ___ high
• wrote a cheery chatty letter to my family (thank goodness for email, there’s no need to post it)
• put £4.50 into one of those booths and got myself a photo that the Daily Mail will use if I ever turn out to be a murderer, and posted it off to the driving licence people
• got a replacement sock for the New Phone of Shininess  (even my phone loses socks)
• tore down my Geocities accounts

And

• decided to ignore the fact that my wireless network needs reconfiguring and trailed a cable through the house instead

Some of it was important some of it was urgent but all of it was getting me down. I thought I was running as fast as I could to get nowhere, but when I looked at this list I realised that actually I had made a lot of progress on all sorts of things.

So that’s Ben’s Top Time Management Tip:  Keep track of what you’ve done because it gives you a sense of forward movement even when your to do list keeps on growing.

---

Like this post? Click to share:

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?

Type before you think

I’m losing the ability to write. Not the ability to type. Ho no. Just the ability to sit down with a blank sheet of paper, a pen and some ideas and write out a clean coherent argument. PowerPoint broke the other day so I used a piece of paper to draft up the bullet points the slides I was working on.  Three pieces of paper later I had arrows all over the place. I didn’t make any headway until the help desk had helped and PowerPoint was up and running again.

Writing logically is hard. When I started my MSc we had an afternoon’s lectures and exercises based on Minto’s Pyramid Principle. It’s a powerful way to communicate and it’s radically changed how I write and to some extent how I speak. What I took from that afternoon was to start with the punchline and then fill in the details. This is how good news reports should be written – though heaven knows all to often they aren’t. It is also how I was taught to write.

Ideally, someone reading the first sentence of every paragraph should have a summary right there in front of them. A mix between a precis and an acrostic, if you will. My history teacher taught me how to do that by making us put a five or six point essay plan at the top of each piece of homework. It takes a lot of effort though. You actually have to think before you write. Um. Make that sentence: “You actually have to think”.

The more logically we think, the harder it is to write simple and accessible prose because  we tend to start with cause and move on to effect. But this is not the best way to take the information in. For most people the best way to take an idea in is to start with the big picture and then fill in the details. Tabloid editors know this and they have mastered the art of grabbing our attention.

• The tabloids and the headlines that say it all
• Greatest Tabloid Headlines
• Loads of pun – best tabloid headlines to make you smile

One interesting effect of putting the meat of every paragraph into its first sentence is that a lot of the “essential explanation” turns out to be padding and guff. Pushing the important bit to the front of every paragraph means that what you write can seem abrupt or rude. But boy is it lucid.

So writing simple clear prose is hard in the first place, but the software is seductively helpful. The Outline views in Word and in PowerPoint help you to do what my history teacher taught me; to structure your piece of writing first and then to put in the detail afterwards.

Outline View in MS Word

I was really rather rattled to discover just how hard I found it to do the same thing on a sheet of paper.