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

Kicking and screaming with the digital workplace.

In my post “Is the Digital Workplace in danger of being the board’s next taboo?”, I wanted to explore the dangers of spending too much time on the esoteric nature of giving modern business evolution a completely different name. I firmly believe the greatest danger of the Digital Workplace is that someone associates that term with their product as a cute marketing idea and connected to this is risk that key decision makers start to think that a single product is the solution.

However, I do believe that the Digital Workplace, as a goal and a differentiator from today’s clunky information handling is a worthy objective and one that we will see adopted by all businesses in the near future, the question will be if they have moved seamlessly towards this new world or if they have been dragged kicking and screaming all the way.

James Robertson’s excellent paper “A week in the Digital Workplace” runs through a real world example of how Morris, a company’s Digital Workplace can help a new employee through the pains of onboarding and being productive fast in her new role. But this approach, whilst totally valid, allows us to easily miss an important part of the message. The digital workplace is not just a tool for a knowledge worker, it’s not just a really cool intranet; it’s the enabler for the business.

In thinking about what the Digital Workplace looks like for another class of worker all together I thought I’d start right at the beginning with a birth (I said we would be talking about kicking and screaming). I’m not going to suggest that we stick a Logan’s Run style chip in the kid… but let’s look at what happens with the Digital Workplace for the midwife.

I’m able to use the case of a small local hospital with around 500 births per year and some scarily chaotic processes, mainly because my partner is one of those midwives but also because Infocentric Research is involved in some exceedingly interesting information management and Intranet projects in other hospitals.

My first observation is that midwives in hospitals often start without the right information at hand. This is certainly scary; it’s totally possible that a patient comes into the hospital and that her patient records have not been processed and that key facts such as blood group information is not to hand. The midwife is expected to do the intial processing. The patient is expected to be the custodian of much of the information and to remember to bring the right documents and papers to the right people at the right time.

In a true Digital Workplace that information will be at hand for the midwife the moment the patient staggers into the maternity ward. We will know that Mrs. Smith is here for the delivery, the key information such as blood group is at hand, we’ll know all her allergies and even what her thoughts on an epidural are so far. It’s very likely that Mrs. Smith will have already pre-registered with the hospital via the Internet and may even have been provided with an app for her mobile phone to give the hospital a status update, before she leaves the house for that one time that the police may turn a blind eye to a little heavy-footed driving.

If some part of this vital information is missing, a string of telephone calls will no longer be necessary. Instead, a simple request from the midwife’s hand held device will initiate the procedures to get the information, be it from the doctor or by activating the call-out service for the lab technicians.

The Digital Workplace must be:

  • Connected
  • Relevant
  • Process driven

My second thought is that midwives spend a lot of time doing what they shouldn’t be doing;  this goes for care and emergency services as a whole. They spend of lot of time documenting. Even in a slightly less litigious society than the U.S. such as Switzerland or Germany, a great deal of documentation is required for any birth.

Most of this documentation is done after the deed itself, there is little time during the process to visit the systems and they are too cumbersome to deal with quickly. Here the Digital Workplace will be capturing and sharing data when possible. For example, cardiotocography data (heart and uterine conditions) will be stored automatically; a simple recording app will be used by the midwife to enter milestone events on the fly, such as examination results, medications given, patient well-being etc.

Data entry will be highly process based, so it’s not a case of hunting for right fields all the time and all this may even be connected with expert systems that start to react to unusual events.

The Digital Workplace must be:

  • Invasive
  • Multi-device
  • Mobile
  • Simple
  • Effective

The doctor will often only attend part of the birth, but in the Digital Workplace they are able to remain informed of the whole process so far. The midwife is able to give the youngster’s ETA directly from her app and the arriving doctor will already know what’s happened so far.

In the case of a birth at home, the midwife will still have access to many of the same tools and will also be keeping the e-paper trail running. The trail will not only inform the doctor, but will also be passed to the health insurer who ultimately pays the midwife’s bill. If things go wrong, or change, then the data from the birth so far arrives at the hospital before the ambulance.

The Digital Workplace must be:

  • Interconnected
  • Flexible

In summary, in the modern world even non-information workers have to deal with information of some kind, the Digital Workplace is not somewhere that you go, it’s the environment in which you move.

Someone once asked me what Intranet stands for, whilst tempted to make something up, I resisted and was able to describe what a typical Intranet is. With the Digital Workplace, I hope to be able to say, “It’s all the things going on in the background to make your job easier”. Which just leaves me to wonder, how easy is the birth of the true digital workplace going to be?