The Room of Requirement – 10 Magical Tips for Intranet Requirement Gathering

Harry Potter had it all, amidst the moving staircases, the ghosts and the young wizards and witches, J.K. Rowling gave him the room of requirement. A perfect addition to any school for young wizards and  a stunning example of personalisation at its best:

“It is a room that a person can only enter when they have real need of it. Sometimes it is there, and sometimes it is not, but when it appears, it is always equipped for the seeker’s needs”.

Source: Harry Potter and the Order of the Phoenix  by J.K. Rowling

It has some interesting features when we think of it in Intranet terms:

  • It’s there when it’s needed; de-cluttering the halls of Hogwarts when it’s not needed
  • It’s easy to get there and find it when you actually do need it
  • It’s equipped for the seeker’s need, so it’s going to help you do the task that you want to do
  • It’s not decorated with posters and news items that nobody wants to read, just the relevant ones about long lost relatives and intrigue in the ministry of magic
  • Harry trained an army in it so it’s got some good collaboration capabilities
  • It kept the enemy out, until they used a totally brute force attack, so good security features

On the downside

  • It did have an awful lot of clutter in it though… good enough to hide things that you don’t want to be re-found
  • It didn’t really present a common user experience

I’m sure that Harry wasn’t really all that interested in the Hogwarts intranet, but it would be interesting to see what a typical user made of the Room. Especially given the way requirements are often defined in Intranet Projects.

  • ‘I don’t know what I want, but I’ll know it when I see it’
  • ‘Make sure it’s got all these social features that we’ve heard so much about and plate-spinning elephants’, even if they don’t fit in the doorway.
  • ‘Can’t you just adapt our Internet?’
  • ‘Could the door be a mixture of blue and green with small red spots to highlight where the door knobs are?’, ‘Content? That’s professor Snape’s department’

Requirement gathering for an Intranet project is an art form and in my experience there are a few things you should bear in mind. Here are 10 magical thoughts about business requirements and the gathering thereof.

Thought 1:

There is a difference between business requirements and requirements gathered from the business. Ask 20,000 people if they think the Intranet should stream video the answer will be yes, ask the IT department and the CFO for the money to upgrade the network to support 200 of those people concurrently live streaming the video, the answer may be quite different.

Thought 2:

There is often more to a requirement than meets the eye, it’s important to tease out the real detail. It’s not just a matter of requirement = function, requirement may be resolved with a number of different functions. If your requirements document says ‘we need a personalized news channel’ you’ve probably got something wrong. If it says ‘we need the ability to target specific messages to specific groups of employees’ which will be solved using a personalized news channel, a targeting system based on a taxonomy or channel approach, coupled with features to help employees find items that are no longer on the front page’ then you’re probably going more in the right direction.

Thought 3:

A lot of requirements for Intranets can be copy paste from other projects, even down to the functional description, but beware, just because two different projects use news on the homepage, it doesn’t mean that the REQUIREMENTS for news are the same. One company may require news to keep the employees informed whilst reflecting a radically different Strategy to another, for example showing which department the news came may be interesting for the user, but it may also undermine a single company approach and would be better served with a topic based classification.

Thought 4:

Some requirements will vanish when you follow through the consequences with the business. A seemingly simple function like a CEO blog may be much less attractive when the commitment to generate the content is required before the function to display it can be built.

Thought 5:

There will be more requirements than budget. You will have to prioritise.

Thought 6:

Requirements change, come and go. System requirements should be able to support different business requirements as flexibly as possible. The more you can match sets of generic functions to different requirements the more agile you will be with your workplace.

Thought 7:

Some project requirements may work against the current interests of parts of the business (usually individual department heads). You may need to find ways to create buy-in with transformational requirements. For example, replacing many small departmental intranets with a single portal will lead to ‘loss of control’ & ‘lack of agility’ type discussions, often culminating in masterly inactivity when it comes to migration. Providing migration assistance, methods for spreading migration over a longer period and improved ways of doing things specific for that stakeholder may be necessary.

Thought 8:

Be prepared to launch and learn. Put methods in place for continuing to gather, prioritise, refine and shape. What you think your requirements are can change based on how the system is used. A very detailed permissions model for editors may be so restrictive in practice that it needs revamping totally to be usable in the real world. Which leads to rule 9…

Thought 9:

Think about requirements in steps, are there ways to implement part of the requirements whilst testing the true case for more detailed elements. This can get you some quick wins with the business and help you to be sure that requirements are requirements.

Thought 10:

Don’t get cursed. It’s easy to get hexed into Analysis Paralysis, a state of perpetual requirements gathering. Believe me this is not a magical place to be!

Greece and Microsoft – Language and SharePoint

Boat Picture

“Outside Athens, Greece is still, Greece.”

Well I got you with the title; it’s not what you think. I’ve just had a wonderful holiday in Greece, sailing round the Islands and thinking about SharePoint. In my thoughts I wasn’t quite at the stage of firebombing Microsoft  but I can appreciate that certain customers, perplexed by some of the ‘features’ of SharePoint, may be driven to such desperate acts.

Before I went away, I was battling with SharePoint experts, trying to find solutions to a number of problems, including language.

All I want is enterprise language support, nothing too clever, just a few minor things:

  • True multi-lingual support for the content (I only want to use 25 or so languages at the moment but will increase)
  • A real language concept, which recognises that a base language principle works on a site but not for an enterprise. There’s no way an organisation can deliver on a base language promise in the real world. Especially if that organisation has no base language (welcome to Switzerland)
  • The ability to change attributes and elements on variations easily. Variations are a good idea in principle but it’s the same principle that says the human cannonball is a valuable mass transit solution.  If you try it in the real world you are going to hit a wall one day, the result will be nasty.
  • The ability to detect language at link-to not just on the landing page (and process the relevant fall back rules).
  • Oh and not to create a million pages of dross (ROT) just by having other languages used from time to time.

Sure you can program your way round them, build custom interfaces that break the next time a major patch comes out. However, even in SP2010 the language handling is still ‘My-First- Collaboration-Platform’ and not a true enterprise tool.

I guess this post has been a bit of a whine; I like to bring solutions not problems.

The solution appears to be to step outside SharePoint to do the things we want it to do. That’s not ideal. SharePoint does some things really well and if an organisation is SharePoint-centric then you often don’t have the choice of using different tools to solve the problem, nor do you want to custom develop a tool up to or beyond the bleeding edge.

My key messages are therefore:

  • If you want to use SharePoint at an enterprise level (and you haven’t bought it yet), think about your language requirements at the time you consider your architecture.
  • If you need multi-base-language support then, if you can subdivide into sites you may be fine. If you can’t (perhaps because your strategy drives you to harmony and integration) then be prepared to develop or use a thin layer above SharePoint in your architecture.
  • SharePoint is getting better, from the disastrous language support in 2007, it’s moved forward in leaps and bounds. Unfortunately it’s leapt over some of the fundamentals that would make it a truly usable solution. In some cases it’s as though gravy were spilled over the napkin of inspiration, a huge hole exists in a really damn fine idea. So please don’t fire-bomb Microsoft anymore, at least until they’ve had a chance to get this right in the next release… if they don’t then I suggest a small thermonuclear device may be a more appropriate response.

Just keep banging the rocks together guys! Stone Age Intranets are not extinct.

That pivotal moment, that moment in which the caveman realises that the spark from banging his rocks together can ignite his pet pterodactyl’s nest, it’s a world changer (for both caveman and pterodactyl), he’s warm.

Of course it’s nice to hand the guy the rocks, the right sort of rocks. It’s a delight when those rocks bring real results to his banging… it’s not just the nest but the whole tree and the surrounding forest that is swept by the wave of fiery inspiration.

A new Intranet doesn’t just mean you bang different rocks together, it brings about a wave of change (if you do it right). In fact, almost nothing escapes; only the deep bedrock of the business survives and even that can be left seriously charred. Communication, engagement, peer to peer collaboration, information flow and deep-rooted business process can all feel the heat of change. But beware; if you don’t think first, even banging your rocks together can start a conflagration so large that you will never get it back under control and many organisations just want to start by getting warm.

There are, of course, lots of ways to make heat and as consultants we know that, we often do it just by talking. The match and the lighter are perhaps more effective, if a little passé. However, not all companies are ready for these, there are still a great many organisations banging rocks or even multiple sets of rocks together and doing pretty well out of it. Our job is to help these companies evolve, that sometimes means stepping back from our vision of Fuel-Cell-Powered-Pocket-Laser-Intranets and trying to bring the future in manageable steps.

In large multi-nationals multiple Intranets are almost a disease, lots of little fires left over from the first enthusiastic rock-banging of the last 5 or so years, most of them only partly doing the job of warming the cave and many standing as flaming barriers, keeping real communication away from the troglodytes inside.

Most companies certainly recognise the need to progress. They can feel the break in communication flow, sympathise with the need for the employee to ‘hunt’ the right source and they can even measure the costs of maintaining lots of different sites. However, the barriers to moving the whole organisation forward as one are often simply too great because real-life things get in the way, things such as:

  • Project costs – “Intranet isn’t core business after all”
  • Project priorities – “Yes we know we have to do something, and it’s important but the transformation workshops for the top managers must come first”
  • Analysis Paralysis – “It would take forever to get the requirements”
  • Resources – “I don’t have time to give you my needs, let alone the time to migrate my content if you actually get something going”
  • Complexity – “Well we started looking at this corporate policy material and found we had to involve Ben, Fred, Joe, Karl, Mary and most of Dawn’s team not to mention….”
  • Politics – “I’m not giving up my intranet, it does everything that I need it to do”

And strangely, the one that I’ve heard a lot (probably due to the above)…

  • Believability – “You’ve been talking about this need for the last 3 years and you’re no further, why should it work now?”

It’s often the case that we think big, try to do everything right and in the process spend so long defining our requirements that the world has changed by the time we get the project live and if you promise the world, the gift under the christmas tree is only going to be disappointing. More often, we find devolved responsibilities and aligning those, even with a CEO mandate, is harder than building the time machine to hand the guy the rocks in the first place.

If you want to succeed in this environment, you often need to take a super-pragmatic approach to building new Intranets, simple steps with a view on the big picture (the pocket-laser of internal data systems that is the Digital Workplace). This means I still find myself building Stone Age intranets, from Digital Workplace point of view, but the concepts and structures behind them are very 2012. I don’t often get to play with social media, I don’t get to gamify, but I do get to build a really strong foundation for the future and I get to transform the way the organisation works, in bite-sized chunks.

With all that in mind here are eight thoughts on how to focus the fire-starting, regardless of the tools you use.

  • Get power from the top…

You need top level buy in. Get it. Don’t start without it. End of discussion.

  • Think strategic, build small and assimilate to get big – M&A time for Intranets…

Start with a well-defined and effective nucleus and build out from there. Put the essentials and easily manageable components in to your first build. Don’t get too ambitious but, at a minimum, provide a good routing mechanism to ‘legacy’ Intranet content of worth.

Tackle the integration issues and assimilate your targets, bit by bit and case by case. As with any merger; some parts you’ll want to replace straight away and some will have to merge into other areas of your existing nucleus (which will require some thought). Some parts will be gold dust in their own right, ripe for the picking and some will be superfluous and can be axed there and then.

  • Pick your battles…

Do your due diligence, prioritise based on impact. Identify the areas where maximum benefit can be had and focus your attention there. Then slice and dice the legacy Intranets to get the value under your control. Deliver measurable improvements for the bits you take; better search, better structure, better content or better governance etc.. Help the remainder to die quickly and painlessly.

Have the ‘difficult’ discussions where necessary and argue from a strategic point of view but remember we are talking strategic for the bottom line of the company, not just for the development of the Intranet.

  • If you build it they WON’T come, unless…

Make sure you train and empower your authors. The best system in the world is useless without good content. A common error is to assume that people want to read an Intranet, especially Intranet news. They don’t… Unless it’s interesting or helps them do their job.

If you want people to come; don’t just a fabulous venue, fill it with good acts.

  • Choose Ambassadors…

Pick some super-committed stakeholders and do something good for them. These people become your ambassadors. If you can improve their processes instead of mirroring painful off-line processes then it’s all the better!

Make sure you can measure and prove your success to them. Their support can be used to help  you convince your next troglodyte.

  • Be the belle of the ball…

Build the features and functions that people want and need, make things easy to use, clearly managed and not overly constraining. Make it attractive and fun to play with you. Make it peppy enough that it’s better than the stuff they do themselves. Delegate governance as far down the organisation as makes sense.

Make it attractive and easy for the users too. Make it more appealing than the legacy sites they have to use. Support the legacy environment as it moves, help them find old material that they value and remember; if you try to block their way to it and they need it then they will bookmark and go round you.

  • Use that executive power correctly…

Stop the business building new things in parallel if it makes sense, but don’t stop them doing things that will give them huge wins in the short term.

The world can’t always wait and it may be beneficial to have your focus elsewhere but do take time to think about how to align these activities and nudge them in the right direction.

  • Remember that an Intranet is all about content…

The expensive part of any Intranet project is not the specification, it’s not the design or build and not even the system on which it runs. The expensive part and the valuable part, is the content itself. That means you need to plan your systems to ensure that the business does not need to keep re-touching and re-migrating content each time something new comes along.

Tools change, Suppliers change and IT systems change but your vital business information just keeps growing. Provide ways to help control that growth; try to stop issues building up for the future.

Do things that detach you from the technology problems; Separate your content and information structures from your systems and you are on to a long term winner.  A few other tips are:

  • Have a strong information structure, make it stable and extensible.  Get the core right on day one.
  • Remember that with your extensible structures, you can go into far more detail when you need to; for example with the taxonomy for standard operating procedures. All that detail doesn’t need to apply to the whole Intranet.
  • Lastly, don’t build your information structures on unstable foundations such as organisation structure, unless of course you want to feed hundreds of hungry consultants in the future!

It’s OK to use new tools, better rocks, water proof matches and branded lighters… but warmth is warmth, don’t keep trying to reinvent that. More importantly, there is nothing that puts out the fire of enthusiasm faster than repetition of annoyingly mundane tasks such as content migration!

 And as a closing thought…

I know I’ve mixed my eras up with my metaphors. If that bothers you, my advice is to just think of the Flintstones. Of course, if it still gives you a problem when you do that, then you might just be stuck in the details instead of seeing the big picture.

How many organisations actually have an editorial plan for their Intranet?

I have a lot of customers and I’ve worked on a whole lot of Intranet projects and for the first time in my life, I have a client that does actually HAVE an editorial content plan for each of their portals (both geographic and business). It’s not a single aligned editorial plan, but the nature of the organisation means that doesn’t need to be the case.

With each internal communicator having such a plan, and a series of personae, it was possible to run a workshop testing real content in different display options and assessing the impact of that content structure on:

  • Strategic message (how you group content sends different messages? – if everything is in line of business containers it doesn’t really show a single integrated company’)
  • Usability (what volume of content needed to be displayed on a daily basis, what does that mean over the month in terms of number of items, was it enough to consider different groupings in order to make it easier? Was the content in logical groups for the user?)
  • Manageability (did some groupings become harder to manage for the communicators, did they require changes in editorial planning?)

Of course we only had indicitive content, we had to make some assumptions about the levels of unplanned content, but the exercise allowed us to have a very construtive workshop with communicators and let them see what relevance based targeting of content meant in terms of reducing the clutter their consumers saw.

At the end of the workshop we had 20 internal communicators who all had the same view on:

  • Content types
  • How content would be grouped
  • How relevance based targetting would reduce the clutter on the desk
  • How the strategic message of a single organisation would be supported
  • How the local communications needs would still be addressed and highlighted
  • How editorial plans would need to be aligned for some content types but not for others

2 very long days for everyone but fantastic workshop feedback, total agreement and a strong basis for the next steps of design…

Time for that wine bottle…

“The meaning of life is trying to find a place for your stuff”

In 1986 George Carlin, an American comedian of some note, said; “The meaning of life is trying to find a place for your stuff”. The words echoed around my head throughout a new portal planning meeting with one of my clients. My brain didn’t stop there and during the next coffee break, it went through the whole routine for me.

I found the sketch on YouTube for those who are not familiar with Mr Carlin’s unique style:

As an organisation, the whole purpose of an Intranet seems to be finding a place for your stuff. If we’re lucky we can not only find a place for our stuff, but also find our stuff when we need it again. Maybe we want a perfect Intranet where can find other peoples stuff that help us do our job (often collecting more stuff) more easily. So we need to build not just a pile of stuff but a pile that we can structure, categorise, search and explore.

But there’s more to it than that… we keep collecting stuff, we ALL keep collecting stuff and the great bard George had words to say about that too. He said “Have you ever noticed that their stuff is shit and your shit is stuff? “. Of course their shit may also be in piles, but probably doesn’t have the same structure as my pile of stuff, because that would be helpful.

Was George a secret information architect in his spare time? If not, how was he summing up the principles of relevance based content presentation so eloquently?

Organising stuff into piles and making sure we see our stuff, stuff we like, stuff we want and if I may use his language, nobody else’s shit, is exactly what we’re trying to do as information architects.

In an ideal world we would be able to organise everyone’s stuff neatly ourselves but when we look at larger enterprises that already have many intranets, then we face a whole new range of problems when it comes to finding things in piles of stuff.

During the course of my posts I want to explore this in some detail and will be looking at questions such as:

  • How can you strike the balance between different types of communication?
  • How can you encourage a migration from decentralised to centralised systems?
  • How can you use relevance based targeting without an approved global taxonomy?
  • How do you detach information architecture from design when talking about a new portal?

Of course when it comes to Intranet design George had another real humdinger; “It isn’t fair: the caterpillar does all the work, and the butterfly gets all the glory.” Designers 1, architects 0. It’s time to explain what the caterpillar actually does!