why do we provide our users with out of the box [SharePoint] Team Sites that contain a bunch of senseless containers for information that offer no guidance as to what they should be doing with these things (Shared Documents, Discussions, Tasks, Announcements and so on)? A SharePoint Site is simply a medium with which to accomplish a business goal, outcome or process. You need to provide your users with clear guidance around what function the site will serve. Simply telling them to use a Team Site is not going to provide clear context to users working within.

Further exacerbating this is that now not only do users not have any idea where to store things, they now have little idea about how to store them. With the new capabilities that SharePoint offers beyond that of a simple fileshare users are further confused about what is the best medium for their content. So should be they putting a team meeting in the shared calendar, or should it go in the announcements list or maybe they should email out to everyone and store it in a document library?

The Fix?

The fix is to inject the context that users need into the sites that you create. To accomplish that you need liberal doses of Information Architecture, an understanding of user requirements, an appreciation of the processes they are using all combined with the SharePoint configuration options that leverage this (metadata, content types, document and list naming, navigation and so on).

All sound advice for SharePoint champions from Michal Pisarek, but it also highlights how much reinventing the wheel goes on with collaboration technologies (actually, in the intranet space as a whole).

Obviously the actual configuration options and methods are specific to SharePoint, but the idea applies to all collaboration tools. If you aren't helping users customise their online workspaces then you will make it harder for them to make sense of the underlying tools. This is potentially one important difference between 'community management' on the public Web versus inside organisations, which should include moderation and curation plus workspace design.

Pisarek's post is also a reminder that so far SharePoint really hasn't taken us far beyond the original Lotus Notes collaboration paradigm - we were doing this kind of contextual customisation at E&Y with Notes and Quickplace back in the early 2000s. Take a look at a product like Newsgator to get a sense of where we should be taking users on their SharePoint journey.

Hat tip Alex.

Claudio Ciborra’s “From Thinking to Tinkering: The Grassroots of Strategic Information Systems” (in The Information Society 8: 297-309) is still (or even more) relevant today, as it was in 1992. Here are some of his ideas:

• Cherish local knowledge and everyday experience
• Value open experimentation, prototyping by end-users and design tinkering
• Establish systematic serendipity, don’t aim for sequential execution in systems design
• Strive on emergence, except failure

Sounds still familiar, right?

Yes.

It’s clear that the once clear distinctions between intranets, internet sites and extranets are blurring somewhat as the technology evolves and business needs develop. Traditional distinctions between internal and external communication teams (and outputs) will also likely diminish, mirroring this application of technology. This merger though will bring some clear advantages.

• A single design with a single user experience for all places, giving a clarity of corporate identity with smaller overall design bills
• Publicly listed companies are obliged to publicly reveal some materials to the markets before telling employees (see our intranetizen post on laws and intranets). A single merged space could limits the chances of a mis-timed publishing.
• Employees read the corporate site too! Merging ensures that there is no chance of mixed messaging especially if the former intranet and internet materials were managed by different teams. Consistency of content is critical when information consumers can compare and contrast.
• Reduced licensing and support costs as to you move to using a single technology foundation.

We are definitely heading down this path - I'm seeing this issue come all the time during the planning stages for social intranets.

However, in practice right now it doesn't necessarily deliver all these benefits - e.g. licensing models for external and inward facing versions of the same platform can throw a spanner in the works. In some companies, the public internet site is also a more reliable source of information than the intranet - so some users might not see this as an improvement.

But there is not doubt that in the medium term, the intranet is definitely going to be a victim of extranet-isation; meanwhile organisations are also building external facing spaces where staff and customers will mingle. Just a question of if and when these will merge.

Cleaner, More Relevant Taxonomy and Architecture Means Cleaner Activity Streams

Having a cleaner social taxonomy will improve the quality and relevance of activity streams. Right now, too many streams inside companies are either a firehose of “everything” — or they filter by an individual group.

But businesses — especially large ones — are way more dynamic than that, and need more fine-grained controls that make it easy to create an activity stream based not only on people or system data, but concepts, ideas and projects related to each. So if you’re able to pull together relevant subjects — or sub-subjects — from your cleaner taxonomy, you’re going to have better, more relevant streams that map to specific business processes.

Conclusion: Finding the Middle Ground

Again, I’m not suggesting we revert back to the days of heavyweight information management that turns end-users and their administrators into managers of digital filing cabinets. At the same time, the sheer volume of information shared by both humans and machines today means that leaving this to the wisdom of the crowd might not work as well as many of us had initially hoped in the early waves of social computing.

Or as I like to think about - don't give users a completely blank sheet of paper.

Some great follow up reading to my Intranet2011 presentation. Intranet managers appear to think in very black and white terms - its either a social intranet or its not, and they may or may not 'control' it. But as Dion highlights here, we have broad options. In fact, we've always had options but we now have even more choice for dealing with brownfield environments and organisational complexity, as the platforms and architectures have matured over time.

What qualities will make or break the next big thing in collaboration?

I think it is not about the technology per se, but more about finding technologies that are resilient against controls [by management]. When I first came to Lotus, I was excited [that] anybody could create a Notes database on a server and set up access control in a very intuitive way. Anyone, not a database administrator, could create a place to meet. Slowly, over time, [IT managers demanded more control]. You would have to submit a request to create a database; you would have to submit a request to change access control. As a result, a lot of places [that use Notes] don't have the "group experience" in Notes, and they just use it for e-mail.

Hat tip to Michael, for spotting this interview with IBM Fellow, Irene Greif. Her interview reflects a great deal of my own experiences of observing how different organisations deploy and control the use of collaboration technology. Its also worth reading Michael's comments on the interview - I think the need manage 'database/site/space' creation is an important issue, however I wouldn't necessarily assume strict controls are necessary. In fact, social computing platforms give us new ways to organise emergent information structures, which is definitely something we didn't have before.

Mark Gilbert from Gartner spoke at the Gartner BI summit in Sydney recently. He said that firms shouldn't deploy collaboration software "out of the box" - I disagree, but I disagree because I'm being pedantic, although I think it is important to be so given this is a Gartner person speaking.

Overall, I think Michael is right to be pedantic. What I'm not clear from Gilbert's statement is that when he talks about the need to adapt collaboration (and social software), is he talking about actual developed customisations or customisations achieved through configuration and user-generated information architecture.

However, Gilbert also mentions SharePoint - and that does complicate things, because of the way I typically see SharePoint deployed, which is with little thought. If we read "out of the box" SharePoint to mean, you've just finished installing the software, switched it on, and announced job done then I can understand why Gilbert might be concerned.

Does this argument hold for enterprise social computing tools? It depends. Architecturally speaking, other "pure" tools of this type (by which I mean, are designed to be or have specific heritage in social software) typically have a greater resilience for dealing with organic and emergent usage. However, I would also encourage people to design for adoption anyway, remaining open to exploring customisation through both development and configuration based on user's and business needs.

Bringing me back to the beginning... you can *sometimes* deploy out of the box. But even while that might be the end of your technical activities, its only the start of the project.

BTW You can come and debate this with Michael and I at the Intranets2011 conference, where we are both presenting.

The stakes a are high for Project Eden, the codename for a long term project to rollout a single electronic document and records management system across all arms of Australia's Defence forces.

The scale of the project is huge and the final cost is expected to lie somewhere between $A100m-$A500m.
Defence estimates it will need to handle 50,000 users within two years and up to 100 million new objects per annum. There will be users at up to 600 locations in Australian and overseas .

Defence has been evaluating vendors since 2006 and has missed previously announced deadlines for making a selection.

I felt very nervous reading this.

I've previously been involved in a very large electronic document and records management system (EDRMS) project for a large international mining company using one of the major systems, so I have a pretty good idea of what the ADF is trying to achieve. I also have a pretty good idea about the challenges, which aren't necessarily technological (and where there are, there aren't necessarily what you might think).

One of the things that concerns me about any implementation like this is that we confuse the desire for a single information system architecture (e.g. one logical EDRMS system to rule them all) with creating a homogeneous information environment that they will try to make everyone use.

This goes beyond simply making the EDRMS easy to use. The typical approach is to use a uniform user interface to meet that goal but all we really end up doing is meeting the lowest common denominator rather than actually satisfying different user needs. Similarly, we also risk ending up with a rigid information architecture that makes the conceptual information system architecture easier to implement, but doesn't actually fit how work is done.

Often these things look great to the guy designing them from his desk in a nice air conditioned office, but the view is very different once you are on the ground (or in my case, 500 metres underground).

Of course, it doesn't have to be that way. I hope they are considering:

• The organisational change aspects and dealing with what I call the "what's in it for me gap" (a user-centred design approach is essential);
• Applying open information access policies within the ADF, with information restricted by exception and managed through activity monitoring and version tracking*;
• How they can apply a Web Oriented Architecture approach, and standards like CMIS, concepts like De-perimeterisation, and even new database architectures like NoSQL; and
• Learning from recent experiences of applying social computing techniques to how people organise, discover and use information (rather than just relying on taxonomies and mechanical search engine techniques).

*Radical I know, but necessary unless you want to end up with a more complex and expensive version of the existing file shares! This isn't about changing information security classifications, but about dealing with information, which is currently hidden by obscurity.

“Wicked problems are a class of social system problems which are ill-formulated, where the information is confusing, where there are many clients and decision makers with conflicting values, and where the ramifications in the whole system are thoroughly confusing.”

Sound familiar? Many intranet design problems share these attributes. Wicked problems require different thinking and design skills to solve than typical problems encountered in the design of symbolic communications, material objects, or even organized services. The intranet, conceptualized as a wicked problem, also needs different approaches.

A *very* well articulated post by ThoughtFarmer's Gordon Ross on why intranets are so simply, yet so challenging. Many people still treat intranets like brochure design projects, but as Gordon explains, intranets really represent a different kind of design problem.

We also hinted at this approach to creating effective intranets in our webinar for Atlassian, on Designing for Adoption yesterday.