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!

Advertisements

6 comments on “The Room of Requirement – 10 Magical Tips for Intranet Requirement Gathering

  1. Dear Richard. Thanks for this nice written post. I just like to give some feedback to your thoughts. First of all i am impressed that requirements engineering is such a big topic and there many books and methods for it.

    Thought no. 5:
    Who is allowed or supposed to prioritise? Business or IT? How to find out the real needs for an intranet. I think surveys are good to get a first impression what web worker really need, but surveys can bring lot of workload.

    Thought no. 6:
    Choose a good implemantation partner and the right software, whicht supports AD or LDAP and which is build on a futireproof technologgy.

    Thought no. 7:
    In my experience one of the most important topic in big projects. Don´t do the mistake and walk in and say: We will save a lot of money by introducing a new ERP, Intranet. So we wil lbe able to fire people. After that people will block the project and it will fail! Explain them that you new system has advantages and hopefully will improve their daily work. Also give them some control for their department and take ONE person from each department for important decission.

    Thought no. 8:
    Use KISS. Do not use too much workflows with review, reject, 6-eye-princip,…

    Thought no. 9:
    Step by step. This helps the customer to get a feeling for what he needs.

    One last thing. Use as many pictures, graphics and visual stuff as possible in specs/requirements documents. Read an 120 pages text about requirents is very boring and leads very often to missunderstanding! Even after 5 one hour meeting I was sure that knew what the requirement was. But during the implementation there so many intepretaions and questions. Sometimes a simple hacked screenshot would explain more that 1000 words!

    • Hi Thomas,

      Thanks for the comments! So glad that you enjoyed the read and took the time to comment. Here are my thoughts on your comments.

      For 5:

      Who can prioritise is a very good question, in most large projects you would expect a core team and a steering committee and both should comprise business and IT members. In an ideal world you prioritise within your core team when you can and escalate to the steerco when there are additional costs, times or differences of opinion that can’t be resolved.

      It’s worth thinking about all requirements in terms of business impact, technical complexity, re-usability, generic-building block etc. and using weightings to help decision making processes.

      For 6:

      As we say in Swiizterland Jein or yes and no… Obviously a good partner and good software helps, but in my opinion there is no such thing as futureproof technology, there is just strategic direction (at that time). Even within a technology product things can change so dramatically that you have to rebuild almost for scratch with one major release. What is important it to build with an abstraction layer between the things that change quickly and the things that don’t so you don’t need to rework everything throughout the infrastructure. This helps both with short term requirement changes and long ‘forced’ changes. My golden rules for this are:

      – Separate presentation from content
      – Separate business logic from system code and storage

      And the big one…

      – Make content and data futureproof. Sure, big intranet projects run into some big numbers for specification and technology work, but they usually have a price per seat that is far more reasonable than you may think when you look at the lines of 0’s on the page. However, when you have to get a few hundred / thousand people in the business migrating content or changing content these numbers get very large indeed. Protect the business from this as much as you can.

      For 7:

      You’re totally right, communication is vital. Alongside any Intranet project there should be positive communication. Most of the large projects that I work on are replacing older departmental Intranets with larger single systems and this means that there is a huge power-loss feeling. It’s important to pimp the benefits and show how the Intranet will make life better. I will always take a look at the pain points of these departmental nets and see if I can bring something to them, providing that it is in line with the vision and strategic direction of the new intranet.

      Involvement in an ideal world yes, but for many projects you just won’t be able to reach out to all the people that have something to say or *think* they have something to say. That makes the communications piece so much more important.

      For 8:

      Couldn’t agree more. KISS is king. It’s important to remember that with a really radically new intranet or digital workplace, that even contributors will have to learn, not only the technology but also the possibilities that have been provided. It’s often the case that, for example, new communications opportunities within the Intranet are used in completely different ways to those planned by the project team. If you can keep governance to a sensible level these can be explored and refined, if you lock everything down they will never arise and you will get a bigger change request log and more grumbling on the shop floor!

      For 9:

      Again totally agree. I have a feeling that you mean step by step in the gathering whilst I had meant step by steps with the requirements themselves, but I still couldn’t agree more. I’d go one further and say that here I would explore requirements by breaking them down into small bits with tension points… do you want to be more alpha or omega – one subject, two extremes and see where they land. It’s often not easy for people to articulate the whole function, but if they can be given tools to help them express their needs, things run much better.

      For your additional comment…

      Oh boy that’s the big one! Wireframes, Diagrams, Pictures and even quick prototypes (from tools like Axure or quick HTML mock-ups to clickable Photoshop or PowerPoint), they all help. They help the business articulate, they help the business see (and sign off) on what they want, they help you see what you’ve missed and they help the developers see what you really wanted. Couldn’t agree more…

  2. Hi Richard

    Thanks for your quick feedback:
    For 5:
    I know this process from a location study where you quantify the factors. After that is easy to see the most important needs.

    For 6:
    Yes as a programmers we always try to separate the logic and the presentation layer, but sometime i have seen the logic also in a Javascript at clientside in a brower!

    For 7:
    I recomend ULTRA fast track 😉

  3. Hi Thomas,

    I guess you’re driving me to the subject of my next blog 😉

    I think Social Intranet is an exceedingly bad choice of wording for many of the customers I work with. It’s like an off switch to progress…. ‘Our employees are here to work, not be social’.

    A similar effect could be gained by trying to use Gamification, which is another example of where an industry term makes sense but when misunderstood ends up as a massive rocket strike in your own foot.

    Sure, there will always be some superpositive execs who latch on to the latest buzzword, but the majority of Intranet managers will find even the term a barrier to success with the board.

    As with all features it’s down to context and need. It’s a sad fact that technology can react and deliver far more than the business needs and that it is ready to adopt. IMHO, the trick is to drip feed the right bits and transform culture at a speed the business (and employees) can cope with… but as I say the subject for another blog!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s