I witnessed this over and over again at the recent Enterprise 2.0 conference in both presentations and in discussions with participants. Executives, IT managers, communications directors, and HR leaders tend to focus on what they know best and how they relate to the Intranet, through the four lenses mentioned above.

Of course, what makes the Intranet a fascinating design task for people like us, the developers of Intranet systems, is that it’s the perfect collision of all of these things.

What other corporate asset has the responsibility of improving service delivery, retaining organizational knowledge, reducing travel, encouraging culture and employee engagement all at once?

I’d argue there is nothing like it in the enterprise. This is the challenge of the Intranet.

We have come to conclude that the most successful model of the intranet exhibits a high degree of sociality. Or said another way, it’s a human-centred intranet, focused just as much on the people interacting in the system as the content stored there. We believe the intranet articulated in this fashion exhibits behaviours remarkably similar to a complex adaptive system. And in my last post, I stated I’d elaborate more on the characteristics of dynamic systems, information ecologies, and intranets, which I will in good time.

But first, we need to talk a bit more about the intranet’s identity crisis.

The Four Purposes of the Intranet

The purpose of the intranet is rarely questioned by companies – and that’s really a shame. What’s it good for anyways?

If you’ve worked with us for any period of time, you’ll have heard us use one of our favourite questions to challenge the assumptions of our clients, “To what problem is the X (in this case where X = the Intranet) the solution?”

James Robertson, a leading intranet consultant and content management expert with Step Two Designs in Australia, presented his 4 Purposes of the Intranet in a presentation at the IA Summit in Miami in April 2008.

Robertson outlines four basic purposes:

• Content
• Communication
• Collaboration
• Activity

Content is defined as the publishing and storage of information on the intranet (corporate policies, forms, procedures, project information, etc.). Communication is traditionally seen as the broadcast model of employee communications, the sending of corporate messages from headquarters to staff. Collaboration is defined as the still-maturing field of web-based project collaboration tools, allowing teams to work together, share documents, and produce project artifacts. Finally, Activity describes the self-service applications that use the web browser as a delivery mechanism to connect staff to mission critical business systems (payroll, timesheets, issue-tracking systems, financial, HR, and ERP applications).

Set against this four-purpose framework, the traditional Intranet’s focus has clearly been delivering a Content and Communications platform for employees. It is not uncommon to find organizations with distributed publishing models and centralized content management systems that allows for employees to publish content into a centrally defined information architecture utilizing standardized templates and visual design. Internal communications staff use the intranet to publicize internal news items and corporate initiatives to staff, in a few-to-many broadcast model. Activity can also feature prominently on the intranet with links to various line-of-business applications launching from the intranet and connecting to employees’ desktops through the internal web channel: payroll, benefits, ERP, expense reporting, and timesheet systems being a few examples.

Collaboration is still an emerging area where internal websites are being used in modern enterprises. Mini-project sites and document repositories are increasingly popular, while communities of practice cluster around intranet-hosted discussion forums.

In analyzing the four purposes of the intranet, Robertson argues that while traditional investment has been made in the intranet as a Content and Communication platform, the real benefits that drive business value reside in its ability to be a Collaboration and Activity platform. Increasingly, organizations around the world are recognizing this and are re-framing the purpose of their intranet, enhancing its design and functionality to drive business transformation, affect change, and generate value.

Robertson’s Four Purposes, originally presented as a brief 13-minute PowerPoint presentation at the 2008 IA Summit, is the result of more than 15 years of thought and active practice in the domain of intranet, content management, and knowledge management consulting. It is a great starting place, but does not provide adequate depth in understanding for charting an effective intranet strategy. The concepts outlined by Robertson, in particular those of Communication and Collaboration, require further attention to be better understood and put into context.

In my next post, I’ll tackle some of the issues we have at ThoughtFarmer with the traditional ideas of Communication on the Intranet.

A handsome and slimming ThoughtFarmer t-shirt

Bevin Hernandez, the project manager who led the hugely successful ThoughtFarmer roll-out at Penn State University Outreach, is presenting on how to launch Enterprise 2.0 in Oliver Mark’s and Sameer Patel’s session on Selling the Case for Accelerating Business Performance with Enterprise Collaboration and 2.0 Technologies.

A marketing piece that was part of Penn State’s intranet launch

Gentry Underwood, who leads IDEO’s Knowledge Sharing discipline, is leading a session on the Best of Boston track entitled “How to Build Collaborative Software That People Will Actually Use“. ThoughtFarmer is a critical component of IDEO’s intranet.

Gentry presenting IDEO’s knowledge sharing platform at Web 2.0 Expo San Francisco. Photo by Paul May.

We’d love to meet with you too. Contact us via twitter at @thoughtfarmer (that’s me) or @gordonr (that’s Gord) and let’s set something up.

Companies talk to us all of the time about their problematic intranets. Messy, out of date, confusing, unattractive, unreliable: we hear about all kinds of nightmarish intranets.

So when companies come to us and tell us about their intranet problems, we listen intently, ask questions, and listen some more. We do our best to understand the nuances of the company, their particular issues, their constraints, and how we could be of assistance. Often, we are part of their solution.

What’s striking about our customers’ stories is how the “fundamental problem” of the intranet is framed in those conversations. It is important to consider, but rarely questioned, for once the “problem” is framed in a particular fashion, certain strategies and solutions become possible, while others are lost.

We’ve seen several frames or lenses through which to view the “problem” of the intranet:

• intranet as technical problem (issues of performance, content management technology, search engine technology);
• intranet as information design problem (content structure, navigation, IA, usability);
• intranet as productivity problem (measurement of gains made through self-service applications and access to information, ROI, enhanced efficiencies); and
• intranet as social capital problem (employee engagement, culture, job satisfaction).

These frames relate directly to intranet ownership and governance, explaining why different areas of the business are responsible for the intranet and its management. It also demonstrates some of the common turf wars inside organizations as IT, Communications, and HR square off with different visions of what an intranet can and should be.

Problem solving is the domain of design, a small word that encapsulates a wide range of activities, ideas, and topics depending on how, when, and who uses it. As design theorist and academic Richard Buchanan notes, “No single definition of design or branches of professionalized practice such as industrial or graphic design, adequately covers the diversity of ideas and methods gathered together under the label.”

A useful distinction that helps with our conceptualization of the intranet problem is how Buchanan outlines four broad areas of design as a discipline. These are the design of symbolic and visual communications, the design of material objects, the design of activities and organized services, and finally the design of complex systems or environments for living, working, playing, and learning.

These four areas of design are easily recognized by their corresponding outputs:

Source: Wicked Problems in Design Thinking, Richard Buchanan; Margolin, V., & Buchanan, R. (1995). The Idea of Design. Cambridge: MIT Press

Of these four broad design genres, where does the intranet belong? Is it a classical piece of visual communications and graphic design, like a brochure? Or due to its technical nature, does it belong to a class of material objects, subject to fixing, like a car engine? Perhaps given the process automation that it affords, it might be considered as an organized service? Or is it really a complex system for working and learning?

Our hypothesis is that while intranets are traditionally seen and framed as a visual design and material object design problem, they in fact have more in common with complex systems than printed brochures, especially when it comes to social intranets and Enterprise 2.0.

Due to this complexity, the intranet design problem can be deemed “wicked” as initially defined by German design theorist Horst Rittel: “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.

Challenging the assumption of “intranet as object” and reframing it as “intranet as complex system” is the first of a few key assumptions that need to be recognized and understood to ensure social intranet success. Framing the intranet as an object leads to trying to design an object and expecting it to behave like one, subject to standard cause and effect type statements. Framing the intranet as a complex system changes our perception of it: no longer is it a static thing, but a dynamic environment, one which responds to different attempts to control and shape it.

In future posts, we’ll elaborate more on the characteristics of dynamic systems, information ecologies, and intranets.

So when Dachis Group went looking to partner with the best social software technology vendors, who’d they call? Oh yeah, you know it, baby. Us. They called us.

ThoughtFarmer is amongst a handful of select partners that Dachis Group will leverage to service the business needs of their customers. Other technology partners include IBM Lotus Connections, Atlassian Confluence and coTweet.

What does this alliance mean for you, our clients, partners and potential customers? First, you can take advantage of Dachis Group’s complete range of strategic services when introducing ThoughtFarmer to your company. And second, it’s another reason you can be confident that ThoughtFarmer is the best-of-breed solution for your social intranet.

Related news:

• ZDNet places ThoughtFarmer in Enterprise 2.0 “Sweet Spot”
• KPMG & Backbone Magazine name ThoughtFarmer to list of Top 20 Web 2.0 Companies in Canada
• Intranet Journal calls ThoughtFarmer a “versatile intranet solution”

Want a sneak preview of our upcoming release, ThoughtFarmer 3.6? Contact ThoughtFarmer Sales.

Tip #1: Pilot around a specific event or project

Before eHarmony purchased our intranet software, they piloted ThoughtFarmer by using it for all the collaboration around a 3-day off-site meeting with the senior team. That real-world scenario let them see how the software would perform under real use. (Read more about eHarmony’s intranet.)

Without a real-world scenario, pilots devolve into random clicking that might test edge cases but does little to test how successful the intranet will be in real life.

Some real-world events or projects that you could use for a pilot:

• An off-site strategy meeting
• An upcoming tradeshow
• The intranet project itself

eHarmony used an off-site strategy meeting to pilot their intranet software.

Tip #2: Choose the right group

Size: Don’t make your pilot too big, or it will become as big a job as launching to the whole company. But don’t make it too small, either: You need enough people participating to make it interesting. 10 to 50 people is probably good.

Attitude: Choose keeners — people who aren’t afraid to try new things or to use new technology. Choose people that will be enthusiastic about the potential for open collaboration at your company.

Seniority: Try to get one or more people from the senior team to actively participate in the pilot. If they set the example, the rest of the pilot group will be more likely to actively participate and view the pilot as important.

Tip #3: Include an influential senior person

If you don’t hold the budget, get the involvement of the person who does. If that’s not possible, involve a senior person who can make things happen. Your pilot can’t be successful unless it influences the people who hold the purse strings.

You need to influence the people who hold the purse strings

Tip #4: Set up a basic navigation structure

Blank slate = bad. No one knows what to do with a blank intranet. So set yours up with a basic navigation structure.

Sample top-level navigation structure:

• People (or Staff Directory)
• Locations
• Projects
• Departments
• Tools & Links

You might also try building out the information structure underneath some of the top-level items:

Departments

• Finance
• HR
• IT
• R&D
• Sales & Marketing

Caution: Be careful not to be too granular in the way you define the initial information structure, or your intranet might seem too restrictive. With a collaborative intranet, it’s easy to move pages if you need to subdivide or rearrange sections in the future.

See the WikiPattern on Scaffolding for more information.

Blank slate = bad. Set up scaffolding in advance

Tip #5: Populate some initial content

Users learn by example. If users see lots of examples of how others have populated content, they find it easy to imitate. Social intranets are generally easy to use — as long as users see that something is possible, they can usually figure out how to do it on their own.

Users. User profiles are a central part of any intranet. Populate them with an initial import from your directory system, importing as much data as you have available.

Barnraising. You can populate a whack of content in a single day. Try getting 4 or 5 of your pilot members together for an all-day barnraising. (Penn State University used a barnraising to populate content prior to their hugely successful intranet launch.)

Give users a reason to return. In the early stages of the pilot, make sure there’s something new on the home page every single day. News items, polls or the cafeteria lunch menu work well for this.

Hold a barnraising to populate some initial content

Tip #6: Set up email notifications

Many social software solutions can send you an email when someone responds to your comment or edits a page you’ve created. Make sure these notifications are enabled — they keep online conversations flowing and drive repeat traffic to the pilot intranet. (See how ThoughtFarmer handles email integration.)

Alternatively, you can rely on RSS feeds for these notifications. But RSS may still be poorly used or understood by many people in your pilot group.

Email notifications keep conversations flowing and drive repeat traffic

Tip #7: Assign specific tasks to pilot group

Assign your pilot group specific tasks to accomplish with the intranet that support the event or project you identified in Tip #1. Sample tasks:

1. Add a photo of yourself and detailed background information to your profile
2. Use the intranet to share the agenda of your next meeting
3. Forward a valuable email thread to the intranet (if it supports automatic page creation from emails)

Tip #8: Promote, launch and follow up

Promote. Prior to the pilot, send several email communications to your pilot group to get them excited about participating.

Launch. Have an event to launch the pilot. If you’re in a single office, reserve a boardroom, do a short demo, assign tasks, and eat some doughnuts. If you’re in several offices, launch via a web conference.

Follow up. Schedule group or individual follow-up meetings for the week following the pilot launch. See how users are doing with their tasks, and answer their questions. A weekly or biweekly group meeting to review progress will help keep things moving along.

Brainstorm your top usage scenarios at the outset of the project

One more tip: Usage scenarios

Before you commence a pilot, describe your top 5 usage scenarios. Here’s a sample usage scenario we developed when working on a ThoughtFarmer project with Vancouver Coastal Health:

Problem: Dr. Tom has a patient on both a beta-blocker and calcium channel blocker. The patient presents with ongoing GERD symptoms. Dr. Tom would like to prescribe ranitidine as it does not have the same drug interactions as cimetidine. Dr. Tom needs to find and print the special authority form on the intranet.

Possible solutions:
1) Dr. Tom searches on “special authority form”. He finds the PDF form in the search results and prints it.
2) Dr. Tom navigates to Forms > Department of Health > Special Authority Form. He sees the PDF form and prints it.
3) Dr. Tom navigates to Common Conditions > GERD > Medications. Under the subheading ranitidine, he finds a description of the drug and a link to the special authority form. He follows the link, see the PDF form and prints it.

Usage scenarios keep your project focused and ground the pilot in a real-world environment.

In contrast, how do you make a social intranet pilot fail? See Dion Hinchcliffe’s 14 Reasons Why Enterprise 2.0 Projects Fail.