Archive for January, 2008
Helen Day’s article, Self-Service Publishing: Implement with Care, posted on the Intranet Benchmarking Forum on January 14th discusses how care is needed in the implementation of these important web tools. Besides a great list of tips, the most interesting observation made in the article is to take care not to introduce Wikis and Blogs until formal publishing processes are in place. She warns:
… it’s important to provide Wikis and Blogs only after processes for publishing “formal” information channels to the Intranet are well established. If the right people are publishing to the right place on the Intranet, and there is good editorial workflow and governance, then the Intranet is sturdy enough to add an open, less-structured layer of content. If there are no good controls in place, then handing everyone a Wiki to use will blur the lines between informal and formal communication. What’s worse, it may threaten the information structure needed to support robust personalization and effective information discovery.
~ Nina Platt
As mentioned in a previous post, research is one of the phases of an intranet initiative. In fact it may be the most important part if the goal is to develop an intranet that meets the needs of its users. This phase allows you to learn more about what your organization needs, what platform is best for your needs, and what resources you will need to deliver a new portal or intranet. Yet the research phase of an intranet implementation is often overlooked for several reasons:
There is often a need to get the project done and involving the end users in the process slows the implementation down
There is a limited understanding of what an intranet can provide to a firm – if the concept of the intranet is narrow, implementer’s may think they can develop without involving others
The intranet team is putting a portal in place and thinks the portal as is, will be all that the firm needs
Decisions about platform and development tools have been made without consideration of needs
While I may have put a negative slant on some of the reasons, the simple point is, developing an intranet without spending time on research can set the project up for failure. Besides giving the end users what they need, involving them in the research phase will create better adoption and use of the intranet.
Given that we all agree that research is important, how does one go about it? It’s done by reviewing the successes or failures of the existing intranet, communicating internally to determine needs, looking at what other firms are doing, and reviewing potential technology. To break it down a bit further, let’s look at each task separately.
Current Intranet/Portal Review
Metrics – Review web statistics to determine what parts of the current intranet had the most use and alternatively, what had little or no use
Help Desk System – Review help desk calls that involved use of the intranet
Surveys – Survey end users to determine what they think needs to be kept and what can go
Individual interviews – talk to individuals to determine what they find most important, what new functionality is needed, what doesn’t work, what long term need they might have, etc.
Focus Groups – similar to individual interviews but in this case the audience is a group which might be based on roles, practice areas, or offices
Usability Testing – conduct testing of how functional the current intranet is – hiring an expert in usability will pay dividends in the long term
Benchmarking – contact other firms with a set of questions that will illicit what they are currently doing with their intranets
Published surveys – Find and analyze publicly available surveys – your firm library should be able to assist you in locating these useful tools
Case Studies – Case studies are readily available from vendors and publications – your firm library should be able to assist you in this as well
Technology Review **
Best Products lists – Many technical publications publish lists of the best products available for given needs. While these lists are useful for finding alternative products, realize that many times the products aren’t necessarily the “best” but are on the list for a fee
Product Reviews – Find and read articles reviewing the technology you are considering
Whitepapers – many vendors provide written information about their product in this format
Demos – Ask vendors for demonstrations of their products
RFIs – Responses by vendors to requests for information can provide valuable insight into how the product meets your needs
* this will include review of the existing intranet as well
** Don’t limit yourself by narrowly focusing on technology you already know about
User Requirements Document – The result of the end user research should get documented as the user requirements for the intranet
Usability Test Reports – This provides the results of the testing
Summary of Technology Review – This document lists the technology that could be used, what each product does, pros and cons, and other information regarding the technology. This information gets used during the design phase as the technical requirements get developed
How the research process get’s done depends on the team you put together to plan the research. The research planning team should consist of the intranet team and representatives from lawyer, professional staff, and support staff ranks. The technical review team needs these representatives as well in addition to IT staff. If you haven’t already involved librarians on the intranet team, please note that librarians have information management skills that often go untapped. They understand information, how it is used and the best way to store and retrieve it.
Look for the next posting of this series soon: Intranet/Portal Redesign: The Design Phase.
Conducting Intranet Needs Analysis, KM Column, September 2005.
Designing an Intranet User Survey, Intranet Journal, 12/13/2004.
Intranet Review Toolkit, StepTwo Designs, March 2006.
User Requiments Analysis: A Review of Supporting Methods, Proceedings of IFIP 17th World Computer Congress, Montreal, Canada, 25-30, Kluwer Academic Pulishers, August 2002.
Web Site User Centered Design: Techniques for Gathering Requirements and Tasks, Internetworking, June 1998. While the article is almost 10 years old, it still has information worth knowing.
~ Nina Platt
Intranet staffing or Intranet team size is often at issue once an intranet goes into production or as the demand for new resources/content grows. To many firms, the idea of having even one full time person assigned to manage the intranet seems excessive. Additionally, what works for one firm, may not for others because their needs are so different. Still, using benchmarks to determine the size of the team can be a good start.
Jane McConnell posted Intranet resources: numbers, “way of working”, what next with 2.0? recently on Globally Local ………………. Locally Global : Intranet Strategies by jmc. She mentions three surveys (including her own survey, Global Intranet Survey of 2007 ) that provide benchmarks. She concludes that the findings are very similar and provides a summary of the numbers from her survey:
- Less than 1,000 employees – 3 intranet headcount
- 1 to 5,000 employees – 8 intranet headcount
- 5 to 15,000 employees – 12 intranet headcount
- 15 to 30,000 employees – 19 intranet headcount
These numbers don’t focus on law firms. We, Nina Platt Consulting Inc., are conducting a study of law firm intranets that provides this type of benchmark along with other information. If you are responsible for your law firm’s intranet and you haven’t already participated, go to Intranet/Portal Development Methods and Investments Benchmark Study to get started. The survey will be closed on 1/31/08 (we extended the deadline). Participants will get a summary of the results of the study.
~ Nina Platt