Category Archives: Requirements Analysis

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 Ball1.

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

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 1 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


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

If not duffers, won’t drown

Better drowned than duffers 
if not duffers won’t drown

The young teenagers in Swallows and Amazons spend their entire summer camping and sailing around Lake Coniston.  When their father gives them permission by telegram, he explicitly states that he trusts their common sense and sense of self-preservation to keep them out of danger, and he puts in a  rider about the Darwinian consequences of stupidity.  

This may seem a long way from good Business Analysis, but it’s too easy to let caution drive out common sense and pragmatism when you are in the world of risk avoidance and business rules.  I’d forgotten what it was like to live in a world where I’m trusted not to be stupid.  Shetland is a delight because it is just such a world.  Let me give you three examples:

The Broch at Mousa is an archaeological site of international importance.  Brochs were large cooling-tower shaped buildings built by the Picts in the last few centuries BC.  They were only ever built in Shetland, Orkney and Northern Scotland and little is known about them because the Picts seem to have been wiped out by the Norse in the first millenium AD.  The Broch at Mousa stands 13 meters tall (about 4 storeys) and is the most complete.  

The Broch at Mousa

The Broch at Mousa

Compare it in your mind with Stonehenge, the Pyramids at Giza or the Taj Mahal in terms of unique cultural importance.  The building isn’t particularly fragile but it’s a dry-stone building so it is vulnerable to souvenir hunters.  

Get this: there is a cupboard containing torches to help you climb the staircase spiraling around the broch inside its double-skinned walls.  

Inside the broch at Mousa

Inside the broch at Mousa

The underlying assumption here is that they can’t stop you, so they might as well make it safer.  They assume that you’re bright enough to realise that it’s risky particularly so in the wet or the winter, and that you have enough imagination to work out the consequences of breaking a leg on an uninhabited island. If not duffers, won’t fall.

Sign on the door of the Broch at Mousa

Sign on the door of the Broch at Mousa

Second example:  we had a long chat about shipwrecks with the chap who was manning the Croft House Museum.  He had a practical interest in the subject because he’d been the last man to sound the foghorn at the light-house where we were staying.   We talked about the ferry that ran aground at Blackpool.  

The Blackpool Ferry - originally came to rest tilted at an angle but has now settled on to its side

The Blackpool Ferry - originally came to rest tilted at an angle but has now sunk on to its side

He simply could not understand why there were security guards around it.  If not duffers, won’t be crushed.  

Final example: the coolest level crossing in the world is where the road crosses the runway at Sumburgh airport.  There are lights, there is a bloke and a barrier but there’s nothing to stop you hanging a left and drag-racing.  If not duffers won’t burn up and down the runway as fast as your souped up Purgeot 206 will take you.

It would be easy to distract myself with a Daily Mail style rant about ‘elf an’ safety gorn mad, and it would be equally easy to speculate romantically that life on Shetland was so hard for so long that common sense is ingrained (the duffers presumably having been darwined out of the population) but that’s not really the point I’m making.

I am just going to note that if part of the role of the Business Analyst is to design lean systems that do just enough and no more, systems that are as simple as possible but no simpler, then Shetland is a living case study in how to do it.

Besides being a superb place for a holiday.

The medium is the model

One cardinal sin of requirements gathering is to discuss the solution during a meeting arranged to understand what the Business wants.  Traditionally, the Business tell you their requirements and you go away and build them.  You don’t bother their pretty little heads with technical limitations, you overcome them.   You are custom coders, geeks and gods.

I’m not so sure.  I think discussing what is and isn’t possible is an essential part of the requirements process, one you should introduce into the debate early on. The “no solutioning” rule may have been valid when every system was hand crafted from scratch by guys with PhDs  and leather patches on their elbows.  In those far off days better IT systems gave you a strategic advantage which could last for years.  But as Nick Carr reminds us, IT Is a commodity now, and our systems are customised rather than custom-built.

I believe it can be appropriate to touch on solutions during a requirements gathering exercise, so long as the discussion doesn’t suck all the time out of the room.  Technical limitations provide constraints, sure, but constraints don’t have to be a bad thing:  necesity is the mother of invention, and all that.  I would argue that the medium is the model.  You can only push the boundaries once you really understand them.  The Business don’t have an unfettered imagination; they want what they’ve already got but faster.   But maybe there’s a completely different way that’s better, and they need to be shaken up a little to be able to think of it:  I’m trying not to say ‘break the mould’ or ‘paradigm shift’ here.

Here’s a concrete example: Wikipedia and a BBC site called H2G2.  As you know anyone can correct an error in a Wikipedia entry at any time.  It’s hard now to remember how new this shared authorship model actually is.  No encyclopedia could be written like that before the Internet.  A few years before Wikipedia was launched, Douglas Adams created H2G2 as ‘The Earth Edition of the Hitch Hikers’ Guide to the Galaxy’.  It’s an online encyclopedia, but to get an “edited” entry on H2G2 takes months or even years.  Correcting one takes even longer.  This is because H2G2 has a print-based model with locked-down page ownership and a process of peer review with sub-editors and editors.  This model perpetuates constraints imposed by typescripts, compositors and printing presses.  It’s sad, but the only thing that stopped the team from building Wikipedia was their own imaginations.  They focused on what they wanted to build (the same thing, but on-line) and then built it.  They could have broken that mould and shifted that paradigm if they had let themselves riff off how it could be built and let that influence what they wanted (a new way of people to work together to create an encyclopedia).  I don’t blame them: it was 1998 and the web was new and no-one really understood it.

This is why I think it helps to introduce solutioning to the conversation because it helps the Business move on from the-same-but-faster (or larger, or pinker, or whatever) and in to areas that really are different and new.  You may introduce constraints, but you also open up new avenues and spark brand new ideas.

So I don’t think it’s wrong to talk about solutions in requirements meetings.

Heretic that I am.

So why did the MTAS site spring a leak?

It’s taken me almost two weeks to calm down enough to think clearly about the MTAS leaked documents fiasco.

I now have three questions to ask Mike Clement of MTAS:

Does he ascribe the MTAS leaked documents to:

  1. Lack of clarity about the requirements for the system – was it being used to do things that were not agreed with the client at the requirements stage?
  2. Lack of technical skill in those who specified the security architecture of the system?
    or
  3. Lack of user-training – were users over-empowered but under-trained?

I’ve emailed him to ask the questions, but I doubt I’ll get any kind of answer.

Slide from an MTAS presentation - reassuring that they take it seriously, eh?I’ve been thinking about this off and on ever since it happened, and I can only ascribe it to one of the above three causes or a combination of them all. They are of course interlinked:

  • if the requirements weren’t fully thought through then MTAS staff would do what was necessary to get the functionality they needed;
  • if the system’s security had been properly built in from the start, then they would not have been able to do it even if they wanted to;
  • if they had been properly trained then they would have known about crawlers and bots (which are automated systems dedicated to finding and harvesting personal data) and understood why they should only publish the data on a secure server even if they had the ability to publish it on open servers.

Whichever way you look at it, it’s a fuck-up; call me histopathological, but I want to understand why.

I nicked the slide from the Ferret Fancier. This is not just any jokey slide about IT security. This is from Sarah Thomas’s illiterate and uninformative slides specifically about MTAS.

They’d make great satire, but Ms Thomas (Dr Thomas?) is one of the masterminds behind the flawed MTAS: she is the Lead Dean for National Electronic Recruitment and MTAS is based – very very loosely – on some of her research. Oh, and call me a quibbler, but she cannot spell. I am now feeling a whole new wave of rage about this thing.