Digital Workplace Structure

The digital workplace is more than architecture and people who are still thinking in terms of putting things in boxes are doomed to failure in the short to medium term.

In fact if you can draw the architecture of your Digital Workplace without it looking like an inked-up spider drunkenly wandering around the London underground map then you’ve probably not got to grips with the digital world at all.

My thoughts go along these lines:

Traditional structure is dead.

In the past we did everything we could to get structure to our navigation.

We copied the way we built our internet sites. We built sites at departmental levels then we learned to think a bit about how the user would want to navigate and if we were really advanced in our thinking we started to impose new structures based on themes or processes more than departments.

Breaking down structure is harder than it sounds.

The human animal thinks in structures and groups. We’re at home with phrases like ‘that department’, ‘those people’, ‘bloody IT’. If we try to break those structures down, impose new structures or different paradigms for thinking then we run into two big roadblocks:

• Thinking roadblocks – “I want to think of that in this way”
• Political roadblocks – “Don’t break down my silo on your net, we’re not structured like that…”

Unless the Digital Workplace is the strategic platform upon which your entire business is built.. Adding structure is doomed to fail.

Everyone needs a different structure… At different times…

The issue we have is that the structures are not always the same and your structure isn’t my structure.

Thinking about the simplest thing in the world, expense claims.. Is that in:

• the HR structure (because they wrote the policy)
• the Finance structure (because they set the deadline and pay it out)
• the working as a salesman structure (because this is how you do your job)
• the ‘things you need to do this week’ structure… (because it’s just that time)

If you want to address all your users then the answer is all of them, which is a bit of a problem if I’m trying to organize my information by hierarchy.

Orientation is everything.

Our need to belong means that we have to have some kind of orientation as an information consumer. I need to be able to establish:

• What am I looking at? (You’re looking at the submission tool for expenses)
• Who is responsible for it? (IT maintain it for you and HR have contacts to help you if you’re stuck)
• How do I get here again? (It’s one of the many tools that we have)
• What’s around this theme? (Are there other things I should know like the policy for submitting expenses?)

Interestingly, how did I get here may be less important than how do I get here again. Especially in terms of search.

Objects and Orientation.

The new paradigm is to think in objects and to consider those objects against two tensions:

• Flexibility: if we break everything down into the smallest possible parts we can easily regroup them in a myriad of flexible ways..
• Manageability: if we break everything down into the smallest possible parts we lose sight of what’s what and can’t manage them easily

The hybrid solution, somewhere between the two extremes is probably the correct one, there are things that do belong together (your policies), that’s a real home, that’s something the user can orientate themselves on (I’m looking at policies), and it’s something that can be linked to a myriad of other things… here is the policy on xyz.

Start thinking about how to structure meta information to give the illusion of structure.

We can get clever with the metadata surrounding objects so we don’t spend our entire lives building link lists. There are some places that do that pretty well, they’re places we like to shop and explore like Amazon. The Digital Workplace that starts to focus on commercial values for structure, engagement and findability is certainly moving in the right direction.

 

 

i2 Swiss Internet and Intranet Summit

I had the pleasure of attending and speaking at the i2 Summit in Zürich last week and I have to say the quality of the event was excellent. I had a really interesting day and that’s always something to write home about!

My first highlight was meeting Tim Walters from the Digital Clarity Group again. Tim and I worked together on the kick-off  workshop for a large SharePoint digital workplace project (which was actually presented later in the day) and it was great to see him again. Tim is a great presenter and his zombie stories were not only entertaining but really landed the message:

Things are getting faster, you don’t have time to change slowly anymore.

The day continued with a number of very interesting intranet case studies at different levels of development along the transformation to the true digital workplace.

It was nice to see so many people using our very own Infocentric maturity model to position their work and it is noticeable how many people have made significant steps forward in the last 2 years.

Especially noteworthy was the excellent presentation from Dave Shepherd from Barclays Bank, not only the presentation style and delivery but also the great work at digital transformation within what would outwardly seem to be a very traditional institution. Search for “Digital Eagles” and you’ll see a whole lot on Dave’s sterling work.

My takeout from the presentations was very much that we are no longer talking about just content but more importantly context and there is a real understanding that enabling people is the way forward.

Enabling people of course means not only your staff, but also your customers and I’m always a little disappointed when I hear that we think this is a new idea. We talk a lot about increasingly demanding customers and yes, there is a piece that says customers are now more fickle but we shouldn’t forget that the basic human requirements for good service, good product, good prices and good clarity are the things that kept us going to the same corner shop for years. Only when the storekeeper went on holiday and put a useless temp in charge, did we TRY the guy down the road…and liked it… The same is partly true of the web, make the experience count and deliver on your promises and good things can happen.

My word of the conference, ‘Digital-Vegetarians’, we’ve all met some of these and our job has to be keeping these guys nourished. Despite the acceleration in the digital transformation, a lot of intranet managers are still fighting to get the necessary management attention and commitment. I believe a large part of my job for the next few years will be helping those managers to pick the right cases and battles and to bring real value to the business without impacting on the shareholders dividend payments. It is possible, we just need to think differently, the ‘Tofu Digital Workplace’ may well be required.

Some hidden factors that should influence your intranet design thinking

Something I’ve noticed with all major Digital Workplace and Intranet projects is that a lot of people focus on the important features and forget the important factors.

When people think about designing an intranet or digital workplace, there are a myriad of tools and methodologies available to help them consider the features and content they need to support. Today, most projects are getting pretty successful at looking at these things:

• Content – What the site says
• Features – Everything from feeds to self-service elements
• Navigation – What do you need to navigate to, and why?
• Corporate Identity – What should it look like? Of course it needs have the corporate identity.
• Usability – Make it easy for your reader? Can the user orientate themselves? Can they find their way around?

But there are a number of more subtle balancing factors which you can play with to determine what lands on your pages and they have a non-traditional impact on the simple answers we get from normal business requirement analysis.

Strategy

Do the choices you are making reflect the corporate strategy? Are you able to adapt when that strategy changes?

If your strategy is to consolidate there is a strong case for a single corporate intranet but if your strategy is to have diverse brands with diverse strategies then a single corporate intranet isn’t really going to add value. However, syndicating content directly into the separate intranets may just be a good answer.

Brand values

Much deeper than corporate identity, does the intranet represent your values?

If your values encourage openness and active feedback, then refusing to put a commenting facility on news doesn’t really live up to that. It’s easy to send out the wrong message and often intranets fail to give any really meaningful message at all.

Staff Impact

Can you roll out without training people? Are you actually changing something more fundamental then just the screen they are looking at?

When you roll out your intranet then all the fantastic work you’ve done on usability should minimize the roll out impact. But the soft changes can be really quite far reaching, if you think back to the dim and distant past email destroyed many quick discussions around the coffee machine, stopped people picking up the telephone and actually slowed down the process of communicating especially when tonality needed consideration.

Manageability

Can you actually manage the structure that you have set in place? Do you have the resources, governance and willingness to take the journey you have started?

I often see great expectations for what a new Intranet will deliver, but the consideration of how much resource can be put into generating, editing and controlling content is often overlooked. There is no point designing a highly visual news rich corporate communications portal if you don’t own have a couple of good writers, a plethora of good images and a copy of Photoshop.

The X factor:

Of course there are also a secret set herbs and spices that actually deliver the real flavour.. this is where it gets fun.  It’s the behaviour you want to encourage, or even drive. This is what transforms organisations and this is where you need to consider usability in a totally different way.

I put it to you that it’s not always about making things easier for your users. If you want to change the way people deal with polices or standard operating procedures, you may want to make it harder for them to find a policy stored in collaboration spaces than it is to find official (and governed) policies.

The take home is that intranets and digital workplaces are complex beasts. Really good system design has to go beyond that of the internet, we don’t want to make people work hard to use an intranet but we might want to help them learn new ways to work.

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

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