Over the last few years, user experience has become my primary focus when building processes and systems. But, I never truly understood the importance of interface design until I read this post by Andy Rutledge.

Andy intelligently draws a metaphor where words represent content (what you are saying) and body language represents interface design (how you look as you say it). He also beautifully illustrates that a huge component of all communication is non-verbal, although it is less than the sensationalist 93% that people inaccurately extrapolate from Mehrabian's communication study.

What is your interface design saying?

Introduction

Janssen-Cilag is one of the fastest growing, research based pharmaceutical companies in Australia. It has more than 300 employees, split across Australia and New Zealand with around half based in the field. It is one of 250 Johnson & Johnson operating companies, which total about 121,000 employees across 57 countries.

In 2006, Janssen-Cilag completely replaced our simple, static HTML intranet with a Wiki solution. Over the 16 months since launch, it has dramatically transformed our internal communication and continues to increase in both visits and content contributions each month.

History of Janssen-Cilag's Intranet

Janssen-Cilag's previous intranet, InfoDownUnder, was a static HTML site, originally developed in 2001. Content was maintained using FrontPage, with only a handful of active editors throughout the company. IT was involved only to upload latest versions of content files from the development site onto the production server.

While some areas were lovingly maintained to a high standard, large sections of content were out of date. There was no search capability. Trust in the information was very low. News was distributed via email, not the web. The site featured excessive use of the blink tag, and New! icons highlighting content that was up to 3 years old.

Latent demand for change was strong.

Intranet requirements gathering

The culture at Janssen-Cilag is highly consultative and relationship based. As such, gathering information and buy-in is often achieved through a series of conversations and discussions, building a coalition of support.

Requirements for a new Intranet site were collected through 27 interviews with a variety of people from all levels of the business. Three themes emerged:

1. We need a trusted source of information
2. Whatever we do has to be simple
3. Just do something!

Each conversation varied widely in focus, but the format usually went as follows:

1. The floodgates open with a dump of information the user considers vital for the Intranet, which lasts about 15 minutes. (What can I get?)
2. They highlight search as a key requirement.
3. I would steer the conversation to questions about how content should be maintained. (What can you give?)

Pitching a Wiki to the business

With many years of experience building one of the first large scale completely open collaboration platforms for the web and then building heavyweight enterprise CMS systems for large organisations, I've personally come full-circle to the idea that the best collaboration systems are incredibly simple and open. Wiki's are a powerful starting point for any organisation, but latent demand at Janssen-Cilag created the perfect environment.

As such, I used the requirements gathering session as a chance to pitch the idea of a Wiki as the solution to our Intranet problem. After bringing the conversation to understand our content maintenance requirements, I'd talk through the Wiki approach and how it may work for Janssen-Cilag. My sales pitch went as follows:

1. We need a system where editing is immediate and very simple.
2. Getting people to contribute at all is hard, so we need to concentrate on letting people do things rather than worrying about what they shouldn't do.
3. The risk of letting anyone change anything is low, since we'll keep a complete history of changes so we can quickly undo mistakes and we can hold irresponsible individuals accountable for anything improper. (Reactive moderation rather than Proactive moderation).

In general, the response was incredibly positive. Predictably, the main argument against this system was fear of improper changes to content, particularly for information subject to regulatory control. I would counter this argument in two ways:

1. There are two ways to control people's behaviour: social forces and technical forces. Currently, we successfully rely on social forces to control a wide range of things like who calls or emails the CEO with their latest crazy idea. Technical forces are powerful, but with each technical feature we increase training and raise the bar against collaboration. Surely, we can see if social forces will be enough for all but the most critical of content?
2. Anyone can choose to monitor any content that they are concerned about (e.g. automatic email alert with changes). So, they can quickly jump in and correct any mistakes.
3. For exceptional cases, we may choose to lock down critical content and define clear ownership and responsibility for its maintenance.

At the end, showing people around Wikipedia was an incredibly powerful way to seal the deal, particularly since they have often used it to find information in the past.

There were no major objections to trying a Wiki-style concept.

Implementing a Wiki for your Enterprise Intranet

We purchased, customised and launched a pilot Wiki Intranet within two weeks and with a budget of $11,000 AUD. This included all graphic design and single sign on integration.

After evaluating a wide range of alternatives including MediaWiki, Twiki and FlexWiki; we selected Confluence by Atlassian. Our main concerns were support for a hierarchy of pages, strong attachment capabilities, news features, LDAP integration, high quality search and a decent rich text editor.

Our customisation focused almost completely on usability. People shouldn't know or care that they are using a Wiki. All that matters is that they can easily browse, search and contribute content. (In fact, after 16 months, only a small set of Janssen-Cilag staff would think of our Intranet as a Wiki. To them, it just seems natural that Intranet software would have evolved to something this simple to use.)

Here were our implementation decisions:

• Integration with LDAP and use of NTLM for automatic single sign on is essential. We even hacked someone's starting point and open sourced our improved version.
• Rich text editing must be available and as Word-like as possible.
• Users like hierarchy and structure, the Wiki should not feel disorganised or completely free-form. (Confluence supports this with an exact page hierarchy capability.)
• Sacrifice power and flexibility for simplicity. For example, our page design is fixed into a title, alphabetical list of subpages, page content, alphabetical list of attachments. While it would be nice to be able to change this at times, or order the attachments, or change the look and feel; it's far more important that everyone can contribute and clearly understands how things work.
• Remove as many unnecessary features as possible. For example, labels are a great idea, but we already have hierarchy and most users don't really know what labels are.

Launch & user training

We started the new site as a pilot, launching as the source of information for a relocation of our head office. (Nothing drives traffic like the seating plan for a new office!) Information around the relocation was fast moving and changing daily for the two weeks between announcement of the move and our actual relocation.

Building on that success, we obtained executive approval to replace the existing Intranet. Over the next two weeks we worked with key content owners (most particularly HR) to show them how to create pages and migrate appropriate information. We made the decision to not automatically migrate any content, mostly because it was so old and trust in the existing intranet information was so low.

Our launch was timed with an informal head office monthly meeting, where around 100 people stand and listen to an update from senior management. We switched the site to live during the meeting, and had 5 minutes to present:

1. 1 min: Highlight the desire for a trusted source of information that was simple to use.
2. 3 mins: Full training that showed how easy it was to view, search, edit & maintain.
3. 1 min: Point out that responsibility for building that trusted source is now in your hands!

That launch presentation remains the only formal training we've ever provided on how to use the system.

Continuing training has been provided through short one-on-one demonstrations (we only show, we never do) and a detailed help section (I'm happy to show you now, but for future reference here is the help page).

Adoption, statistics & business impact

The adoption of JCintra has been remarkable. After only 3 months, 111 people had contributed more than 5,000 changes. After 12 months, we had 18,000 contributions from 184 people within the business.

Most significantly, our contributions per month has continued to grow since launch. People are engaging and collaborating more with time, they are not losing steam as you might expect.

To drive adoption, we've primarily focused on owning the flow of new information. Early on, we established a policy that all announcements must be on JCintra. When necessary, they may be sent via email in addition to posting as news on the Intranet. Today, announcements ranging from major restructures to new babies for employees flow through the news page without clogging up email inboxes.

Owning the flow of news has established JCintra as a trusted source for the latest information. This translates into an expectation that the stocks of information (e.g. policies) will be available and up to date. Own the flow and the stock will come.

Business information that was previously scattered in email (e.g. Business Planning presentations) is now collected into a permanent, secure online space. We have a growing reference and history of information to build on and make available to newcomers. Knowledge management, previously a big concern, has moved off the agenda for the time being.

Content ownership model

For many Intranet owners, the model for content ownership is a key point of focus. With JCintra, our philosophy (successfully so far) has been:

1. If someone isn't willing to maintain a piece of content, it can't be that important to the business.
2. We happily show people how to do things with the site, but we don't do it for them.
3. Occasionally we highlight sections of the site on the home page, which is a great way to drive the defacto owners to clean it up a little.
4. We encourage people to have high expectations for content on the Intranet. If something is missing, please report it to the appropriate area of the business, or better still, add it for them.
5. The answer to verbal queries for many departments has become, "it's on JCintra". This reminds people to search first and ask later.
6. In the end, the quality of content in an area is a reflection on the defacto department owner, not the Intranet itself.

As a result, we've seen some departments embrace the Intranet in a big way, while others don't update content as much as we'd like. As expected, service areas of the business have been strong adopters, which means the main areas of Intranet content have been well maintained.

We've not yet adopted a formal content review process, but believe this will become more important in the next year of the sites life.

Keeping momentum & next steps

The primary barrier to continued success of JCintra remains the same as our initial barrier: encouraging a culture of collaboration and transparency. Some areas of JCintra have been highly successful in this regard, while other sections have never gained clear ownership or momentum.

JCintra works best when it is established as the source of truth for information and becomes the place where the work is done on a day-to-day basis. While ever the Intranet is a place that has to hold a published copy, it will remain as "extra work" and struggle in the competition for people's time.

Conclusion

Implemented with usability and simplicity as the key focus, a Wiki is a fast, cheap and highly effective way to run an Intranet. Users do not perceive our Intranet as a Wiki, with all the anarchistic overtones that brings. Rather, they see the simplicity and flexibility as a natural evolution of Intranet technology.

In a culture full of all the typical trust, transparency, workload and security concerns common to big companies; the simplicity of this system and its content ownership model cut through. Problems of driving collaboration and content updates remain, but they are exposed as the cultural and people problems at their heart since the technical and workload "excuses" have been stripped away.

Note: Our Intranet has evolved significantly from the screenshots above, which were taken from the time of launch to avoid business confidentiality issues in this public forum. The site now includes a wealth of content and tight integration with our data warehouse, CRM and internal operational systems. Read more in Building Enterprise 2.0 on Culture 1.0.

3 months after her birth and simultaneous notification to the Google Crawler for indexing, Elimena.com was still not showing up in Google's results (or other search engines for that matter). I was shocked it was taking this long, and had resubmitted multiple times.

In desperation today, I thought it might be related to the Javascript trick I'm using to show the Flash Movie Header as a link that doesn't require activation to use. Looking at the source code, I noticed this fatal tag on every page of the site:

<meta name="ROBOTS" content="NOINDEX,NOFOLLOW"/>

being added automatically by the Blogger template tag:

<$BlogMetaData$>

I was confused, since my e-gineer blog, also powered by Blogger, doesn't add this when using the BlogMetaData template tag.

To fix this check the following Blogger setting:

1. Login to Blogger.
2. Go to Settings, then Basic tabs.
3. Ensure that Add your blog to our listings? is marked as Yes.

If your blog is suspected as spam by Blogger, and they force you to enter a captcha code everytime you post, you can submit your blog for review by Blogger staff which should fix the problem.

If all else fails, simply copy all the code you need that is produced by the <$BlogMetaData$> tag and paste it into your template in place of the tag itself.

Introduction

Earlier this year we conducted a review of the cost allocation model used to charge our local operating companies for support centre services like helpdesk, IT procurement, server management, etc. This post outlines the model we came up with and draws key principles for any agreement of this type.

The key is to keep everyone focused on costs, not on cost allocations. (Cost allocation just shifts costs around.)

When allocating costs from a shared service, the key aims are:

1. Provide customers with transparency and control over cost drivers.
2. Provide flexibility over the way resources can be used, while keeping a single consistent allocation model.
3. Leave choice over resource allocation and daily control with the service provider.

The costs for a shared service can be divided into 2 components:

1. Infrastructure
2. People

Infrastructure costs

Infrastructure costs should be completely separated from overheads and people costs. Examples of infrastructure include data transfer, rack space charges, outsourced server monitoring, etc.

Each infrastructure item has a total cost, which must be divided among the customers according to an allocation model that best represents the cost driver.

Example: Allocation of Infrastructure Costs

Data transfer into the data center for July cost $100. The allocation model for this infrastructure item is bytes transferred by each customer company. Foo Industries generated 75% of the traffic during July, while Bar Incorporated generated the remaining 25%. As such, the data transfer bill for Foo is $75 and Bar is $25.

Racks for housing servers in the data center are depreciated at a rate of $50 per month. Costs are distributed based on the number of servers used by each company. Foo has 10 servers in place, while Bar has 15. As such, Foo's rack charges is $20 for July while Bar pays $30.

Server monitoring is compulsory for data center servers and is charged at $200/server/month. This is billed directly to each company based on their servers in place so Foo pays $2000 and Bar pays $3000.

In the end, we have this equation to give the operating company cost for each infrastructure item:

ItemCostToCustomer = TotalCostOfItem x (CustomerUsage/TotalUsage)

People costs

People in a shared service spend their time on 3 things:

1. Project work
2. Ad-hoc tasks, maintenance and incident management
3. Managing other people

Each person working in a shared service has a specific cost. This will typically include:

• Salary & benefits
• Building and space costs
• Equipment costs

Time spent on project work and ad-hoc tasks can be directly allocated to customers, but time spent on people management is harder to quantify. To solve this problem, we calculate the cost of time spent on people management and allocate it among all reports under the manager.

Example: Allocation of people costs

Alice is the manager of the shared service and spends 100% of her time managing people. She does no direct project work and does not complete any ad-hoc tasks. Her cost, including salary, building and equipment costs, is $100.

Alice has 5 direct reports, each of whom have 4 reports, giving a total of 25 staff in her team. Alice's cost is divided evenly among all 25 reports, adding $4 to the cost of each person.

Alice has no time to allocate among customer companies (she's done no "real work" afterall). But, her cost is effectively distributed by the work completed for customers since it is allocated to staff who do "real work".

Bob reports to Alice. His cost, including salary, building and equipment was $80. With the management allocation from Alice, his cost is now $84.

Bob spends 50% of his time on people management, 25% on projects and 25% resolving ad-hoc issues. Per the model, 50% of Bob's total cost of $84 is evenly distributed among his 4 reports ($42/4 = $10.50 each). The 25% project work ($21) and 25% ad-hoc work completed by Bill are billed to the customers directly.

Chris reports to Bob and spends all his time on ad-hoc tasks. His cost, including salary, building and equipment was $60. With the management allocation from Alice and Bob, his cost is now $60 + $4 + $10.50 = $74.50.

Of the ad-hoc tasks performed by Chris, 50% were done for Foo Industries and 50% were done for Bar Incorporated. As such, Chris's cost to Foo Industries is $37.25 and to Bar Incorporated is $37.25.

In summary, the allocation of people costs follows these principles:

• All people costs are allocated and paid on an individual person basis. So, a company that uses 25% of Derek's time will pay 25% of Derek's cost.This is not the same as using 25% of total time spent by the shared service team and paying 25% of their total cost. For example, if we use resolved calls as the metric to determine ad-hoc time spent and include both L1 (average 300 calls) and L2 (average 50 calls) engineers in the cost calculation there is no potential reward for moving calls from L2 resolution to L1 resolution.
• Time spent on people management (an rough estimate for each manager) is added to the cost of the people being managed. So, you are only charged for actual work being done but we recognise that part of the cost of using those resources is the management team in place.
• Time spent on project work is directly allocated and billed to the customer requesting the project. It's important to appropriately separate these tasks from ad-hoc time. This ensures that we can see the real cost of project activities and keeps ad-hoc tasks reasonably consistent in complexity (thus evenly cost distributed).
• Time spent on ad-hoc tasks is assumed to be the remainder after calculating time spent on people management and time spent on projects.

It's only a model

As always, this model is an approximation of reality. It will never be perfect, nor should we aim for it to be perfect. It's important to remain pragmatic and remember that a lot of the small inconsistencies and errors will correct themselves. (Two slightly wrongs can make a right in this context.)

You'll need to think about how to handle events like extended sick leave or annual leave.

The key is to remember to keep all cost drivers transparent and controllable. Try not to let generic buckets like "overheads" or "maintenance" creep into the model.

Conclusion

After 6 months use on a team of 25 people divided among 5 operating companies over 2 countries, we've found this to be a simple, flexible model that has given us unprecedented insight and high level of control over cost drivers.

We're now dealing with the hard (and important) problem of seeking real process improvement and cost control rather than looking for temporary advantage by playing with cost allocations to get temporary local advantage.