“build a Wiki and crowdsource ideas". It’s similar to Wikipedia. It involves the creation of an internet platform that enables managers and employees to add relevant information, and that information can then be edited and peer-reviewed.

Another idea is to “build an internal social network.” Employees can design their own profiles, upload images, provide useful links, add work-related content, and eventually “this will reduce the volume of email communication". In an era of email overload, that can only be a good thing.

Other than this article spreading the usual FUD about social media in the workplace (here is an alternative view), this is pretty simplistic advice for SMEs thinking about trying to proactively utilise Web 2.0 and social software.

Even large businesses struggle with the idea of creating internal Wikipedias - small businesses simply don't have the critical mass. However, there are some practical ideas (use cases) for enterprise wikis (like Atlassian Confluence):

• Managing Meetings.
• Project Management. 
• Reporting.
• Document Drafting and Commenting.
• Publishing and Maintaining Policies and Procedures.

With some tools you can even build simple forms and workflows, although the emphasis is really on uisng a wiki as a lean management tool.

The internal network is a better idea, but in a small business they don't necessarily need to know who each other is but rather what each person is doing and using streamlined methods for sharing information. Microblogging tools - like Yammer - or even instant messaging - using tools like Skype chat - can fill that need. Better yet, these tools are often optimised for smartphones too and younger staff will love using them.

With the right tool, some or all of these ideas above can be combined. For example, Google Apps.

The key themes that small business should be thinking about using social media internally for are:

1. Communication. 
2. Team work. 
3. Productivity. 
4. Information management.

For SME's with a consumer focus, they might also want to think about how the internal use of social media can connect to their external social media and traditional marketing activities. SMEs focused on B2B services can also create extranet wikis for collaboration with their business customers or even extend their microblogging tool to them, focusing on creating an extended private social network rather than an internal one.

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.

The other day I blogged about 3 Intranet Truths.

Looking at my first Intranet Truth ("No two intranets are the same. If they are, you are doing something wrong - stop benchmarking and start leading") its worth reflecting on the first two themes from Step Two Design's Intranet Innovations 2011 awards:

• A culture of continuous improvement; and
• Innovations that are based on very simple ideas

One of the examples they share that embodies these themes is computer animation house, Framestore:

The intranet team created a tool to project manage the visual effects they produce for movies such as the Harry Potter series. Built in-house and displaying data from a third party system, the company’s artists can access tabbed views of complex data about every scene and shot.

Framestore's success isn't based on nice to have features or "best practices" blindly copied from others, but by designing an intranet solution specifically for their users. If you want to replicate their success, show leadership by focusing on learning from their method not their design.

You will also see this same mindset in the way Headshift | Dachis Group approaches our projects, including examples such as Reynolds Porter Chamberlain.

This is a long anticipated play by Yammer to expand the foot print of its platform. I haven't had a chance to play with these new features just yet, so can't comment on the user experience or maturity of the new tools. However, I am wondering how this will affect Yammer's business model in respect to the enterprise and government sectors - the more it adds, the more chance that a purely viral deployment approach will bump into other enterprise applications and systems, which may result in the need for a more formal adoption and procurement approach.

UPDATE: Alan Lepofsky provides a more detailed review and point of view.

E2.0 tools today are typically not integrated with the rest of a company’s applications. So the unstructured / emergent / social work happens in a totally different digital environment than the structured / pre-defined / formal work. Orders get filled using the ERP system, while conversations about why the order’s not getting filled happen in email, IM, a wiki, and so on.

For some purposes, this is OK. Narrating your work via blogs or microblogs so that others can find you and access your expertise is a great standalone use case, as is narrating your ignorance —   asking questions to the enterprise as a whole without guessing in advance who will know the answer.

But most informal collaboration, I bet, happens ‘close to’ the formal work of the enterprise. So the digital environments that support the formal and informal work should also be very close to each other, either within the same application or across tightly integrated ones. Data and decisions (“OK, go ahead and increase the customer’s credit limit so we can ship the order”) should be able to flow easily between the systems for formal and informal work. This is not a new point, but it bears repeating for exactly the reasons Laurie mentions. Unless and until this happens, E2.0 is much less than it could be.

Yes, its easy to drink too much social 'Kool Aid'. But that applies as much to the process centric view, as it does to focusing only on the "social, humane, people-centric" perspective.

My point about the impact of electricity on industry still stands. Hard nosed contextual collaboration built around a bad or inefficient business process is only stop-gap measure (if even that), but is probably easier to sell in the short-term. This kind of digital Taylorism is bad not because it ignores the soft stuff, but because the pseudo-science of scientific management was debunked a long time ago.

Part of the problem is that we still get confused by the differences between ideas such as user-driven computing, lightweight enterprise IT approaches, creating good user experience in enterprise apps and social software. Each offers benefits and there is a strong relationship between these four, but they aren't mutually inclusive all of the time.

For example, improving a process might not be so much about contextual collaboration but could simply be about applying lighter Web inspired IT solutions to enterprise problems. I remember seeing this example of a shipping company having a bottom line impact with Enterprise RSS back in 2008.

There are lots of examples, especially at the team level, where you have people taking the initiative and bringing in software, especially for low cost or free, and they are getting value out of it. But because they are not documenting the value in any systematic way, or spreading the word about it, these tend to remain relatively fragmented, isolated instances.

Interesting, but valid point from John Hagel at Deloitte. We sometimes talk about "Return on Collaboration", but for workforce collaboration we probably need to be thinking about this in terms of the return for the individual, the group (team, department, division, business unit, etc) and ultimately the whole organisation. The question is then, for a particular tool is everyone getting their fair share of the return?

Microblogging inside an organisation provides staff with the ability to post short messages to everyone in the organisation or a select group. A variety of online tools can be used, for example Yammer, SocialText or an internally built solution.

Deploying microblogging involves more than understanding the technology, because it is really about providing opportunities for conversations between staff. The content of microblogging messages can vary widely, from accounts of what staff are working on, and questions for other staff, to updates about products, projects or situations.

The growth in microblogging is a relatively recent phenomenon and its success within organisations varies greatly. Where it has been successful, microblogging has been able to better connect staff, break down hierarchical structures and improve the sense of belonging felt by staff.

As with many of the social media tools, there is an impact on the intranet, particularly on communication channels and siloing of information. This article outlines:

• strategic considerations
• practicalities on how to set up microblogging
• how to drive adoption

I've been talking a lot about enterprise microblogging lately (see my post about how Deloitte is using Yammer). This is a nice article from Catherine about enterprise microblogging, however just to add a few points:

• Its worth highlighting from Catherine's post that some enterprise microblogging tools offer a freemium model (including Yammer), where they offer a free and a paid premium version. The premium version provides access to advanced features, such as ActiveDirectory sychronisation (so you don't need to remove users if they leave the organisation). The fact that you are reading this and 'thinking' about deploying enterprise microblogging probably suggests that you need those features, so you should be factoring a budget into the planning process. Remember also that most of the hosted tools are priced on a per user per month basis.
• I've already disputed the statistics mentioned, although I agree there are good and bad deployments of social business software - personally I would also worry less about adoption rates and participation, focus instead on understanding the return on collaboration. For more on this, see my post of Designing Social Workplaces and Amit's great post on Adoption Strategies for Social Software.
• Catherine focused on the people-to-people interaction in enterprise microblogging, however we are also increasingly looking at how we integrate these systems of engagement with transactional information systems ("systems of record") - what I call machine generated content (MGC). Tibbr is a good example of this.
• Finally, if you looking into technology options don't forget to consider if you want to integrate enterprise microblogging with other tools (e.g. SharePoint), build it into an existing platform or implement a social suite that also has status updates in it (most offer a lightweight microblogging feature).

 

So then, how did the experiment go? First, let’s remind ourselves of the prototype’s primary objectives

1. To test, in public, a prototype of a new, single UK Government website.
2. To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.

The prototype was developed in 12 weeks for £261k. It launched 1 day late, but given the need to recruit and gel a suitably skilled project team from inside and outside government, Objective 2  can reasonably claim to have been delivered. A boundary-pushing experimental prototype (aka a Minimum Viable Product ) was delivered by an in-house team working in an open, agile way, placing user needs at the core of design process.

This isn’t a new approach, but it’s one that still all too rare across government...

But what about Objective 1? The reaction to the prototype itself?

...

...the reaction that really matters came from real users. Actively asking people what they think about a new product is always chastening yet ultimately rewarding, akin to a visit to the stern dentist. And we were thrilled with the volume and quality of user feedback garnered. People are so keen to help Government improve our products. We just have to ask for help, listen and respond.

The prototype was by no means perfect - and the Alpha team recognise that. But it was a prototype and that's the important difference - a completely different approach to IT in government is on display here.

At last week’s E2.0 conference in Boston, I was surprised and pleased by the way my “in-the-flow” phrase has gained common currency.

I was also surprised, but less pleased, by some of the “best practices” I heard flying around. Whether in keynotes, sessions, or just hallway conversations, I heard a lot of claims of dubious merit, claims like:

• Start with a small pilot and let it grow virally
• Invest heavily in community management, because a community is only as successful as its managers
• Workers won’t use social software without personal incentives
• Workers who don’t belong to the Facebook Generation don’t “get” social software.
• Social software adoption requires a culture of collaboration
• You shouldn’t launch collaborative tools without a collaboration strategy

There’s a common theme behind all this advice: You should be scared of launching enterprise social software, because achieving adoption is really hard, really time-consuming, and really expensive.

Sorry friends, but I’m calling Bullshit.

I had to read Michael Idinopulos' post a couple of times to make sure I understood it.

Basically - in a round about way - he is describing two things:

• The complex nature of organisations. 
• That social business tools work, because they help people get work done 'in-the-flow'.

I agree entirely - and this makes the AHA case study a great example.

But lets address this issue of organisational complexity.

Sometimes a simple intervention - like introducing a new technology - can make an immediate impact. But we don't actually know why, although we can observe the benefits when it works. Do the same again in a different situation and you take a gamble on the outcome. For systems of engagement, this is the problem of copying macro level case studies when change actually happens at the micro level of individual groups and individuals. Sometimes it only takes an influential blocker, a critical system that doesn't integrate well, a policy that can't be side stepped or a group that has already picked their own solution - suddenly the dynamic changes.

I use those words deliberately, because the character of some organisations is to be conservative, others are prepared to to be more reckless. Smart organisations take a design-led middle ground. They don't follow knee jerk reactions to new technology, but they don't fall for shallow thinking either.

To help make that point, here are some different case studies (I'm focusing on enterprise microblogging, as there is a level of commonality between them - but this also follows on from some earlier posts):

• Yammer at Suncorp - the viral adoption pattern.
• tibbr at CIBER - tried a couple of solutions, before finding what worked for them.
• Yammer at a small medical practice - hit a technology challenge.
• Chatter at Den-Mat - ran into people and skills issues. 

Each of these examples had a different journey (Micro), but each had a positive story to tell (Macro).

Incidentally, the CIO behind the case study that Idinopulos described has written a detailed post describing the "15 Key Steps for Successful Implementation". This isn't simple, but the steps make it less complex; and its all about finding that fit so that users can get into the flow easily.