iorg.com logo

Top

White Papers
 

© Copyright 2000
iorg.com

TOC - Ch 1 - Ch  2 - Ch 3 - Ch 4 - Ch 5 - Ch 6 - Ch 7 - Ch 8 - Ch 9

Chapter 8: Planning and Implementation

Intranet Organization: Steven L. Telleen, Ph.D. 

Introduction

Great Intranets are not great because of their sophisticated design or the level of automation they have achieved. Great Intranets are great because they help people communicate in new and useful ways. A high level of sophistication or automation may, in fact, inhibit true communication, by limiting free input and response to all but a sophisticated few. When an Intranet achieves true greatness, it is impossible to single out individuals responsible for its success, because the energy and innovation are in conversations spread widely around the organization, and the participants all feel responsible.  This chapter assumes that the goal of an Intranet  is to enable as many people in the organization as possible to be full participants in the communication process.

Understanding what you hope to achieve, your vision for your intranet, is an essential first step in the planning process. Without explicit expectations, there will be no way to determine success. Either anything you do will be considered successful, because there are no expectations, or nothing will be successful, because the odds of accidentally hitting unstated expectations (that are likely a moving target) are almost zero.

Expectations for an Intranet  can range from existential visions (We expect to change the way we do business or the business we do) to referential goals (We expect to make these processes faster or more efficient). The level and scope of expectations will determine the best approach for planning the Intranet. For example, expectations based on an existential vision generally will focus more on the development of individuals and organizations, and the technical infrastructure will be viewed as a set of referential goals in support of that development. Expectations based on referential goals generally focus on web enabling existing applications and processes as a less-expensive, more-efficient (and user friendly) way of providing computing and network services. The main focus of this chapter is on development of organizations and individuals, but first a few words about technically focused intranet implementation projects.

If your intranet development effort is oriented toward technically-based, referential goals, then you or your technical specialists most likely have some idea of  how to plan for your intranet implementation. It is similar to other application development projects. As long as the scope of the Intranet application  matches the existing application scope, an Intranet application project will be faster, cheaper and easier than traditional development efforts. However, many organizations quickly evolve requirements for (or use the Intranet as a justification for) applications that require new integratation of data from multiple, legacy, sources.

Many of these projects quickly begin to look like a traditional back-office database integration exercise, rather than a web project. The only web parts are the scripts that create the user interfaces. To get more benefit, the solution can be re-architected to include  more web-based functionality in the application delivery. However, this takes both an understanding of the paradigms and approaches, which as indicated in earlier chapters of this book, can be quite different from traditional approaches, and skills with the new languages and tools (see also: Telleen & Meltzer,  Intranet Systems Integration).    There are  tools designed to integrate multiple data sources (usually through some form of  meta-dictionary) and insulate the applications from direct knowledge of the underlying databases or data structures (see Allaire Cold Fusion and NeXT WebObjects as two popular examples).

Perhaps the biggest differences from many earlier application development approaches are the continuing, rapid development of new applications that can be integrated into the solution and  the ability to rapidly develop end-user access to traditional data sources. Therefore, it should be no surprise that the two biggest differences in the planning and management of a complex Intranet application project are the need to accommodate shifting options and expectations and the use of prototyping techniques, rather than the classic "waterfall" planning and development  techniques. This requires good expectation management and change management skills, in addition to understanding Rapid Application Development (RAD) techniques. It also requires a technical architecture that  supports diversity through modularity. I generally tell clients to develop their architectures  with  the ability to change support for any  function using a newer component,  from a different vendor, every 18 months. This requires architectures based on community-owned standards rather than products.

My observation has been that, in general, the length and complexity of a technical application development project can have more to do with the understanding of the new Intranet architectures and tools by the planners and technicians than with the type of project. Approaching the development  with a traditional mental model will produce traditional results. If you do not have the experience in-house, you may want to contract for it initially. But even here you need to beware. There are still a lot of traditional implementation houses that have picked up the Intranet marketing mantel as a way to sell traditional integration services and approaches.  You can easily end up with a mega-intregration to maintain rather than a modular architecture of standard components that allows you to evolve functions  independently over time. If  the project does not quickly deliver useful applications that stand on their own and easily integrate with newer applications as they develop,  you need to take a critical  look at the architecture and approach.

In contrast to the complex, structured, web-application, an Intranet effort that is  focused on the development of individuals and organizations  tends to have much more modest enabling technology requirements. In fact, complex application development projects, and complex applications themselves, tend to inhibit effective Intranet adoption for the more conversational, learning and knowledge functions an Intranet can support. In this area, the technical aspects fade into the background as basic infrastructure, and most of the functionality can be purchased at moderate prices and managed with increasing ease. The complex issues shift to the productive integration of the new functionality into the organization, and the shifting of responsibilities and behaviors of individuals.
(top)
 

An Approach to Organizational Development

If the objective is to distribute responsibility and decision making, then any organizational development program must support this goal. This creates an implementation challenge, since any decision made at the top undermines the objective. One approach to implementation is a series of workshops that introduce  the participants to the issues and initial support structure and help them define the initial decisions that each needs to make. A major objective of the workshops is to create a community  that supports each individual in making responsible commitments and decisions from within her role.

The workshops take place within a larger implementation structure. The critical steps in the larger  implementation structure  (in implementation order) are to:

  1. Create appropriate roles and organizations for managing informal, formal & controlled content,
  2. Implement the baseline technical functionality to enable self-support,
  3. Facilitate the adoption of the required roles and skills by the people in the organization,
  4. Create a critical mass of intranet participation within the organization,
  5. Create "rules of the road" (standards & policies) that promote the efficient flow of information with minimum imposition on the communicators.
The first two steps are done prior to the workshops. The remaining  three are outcomes of the workshops. All these steps are preceded by an Executive Awareness Program designed to increase executive understanding of the issues, generate support for the process and help each executive  identify the initial workshop participants (their designated Publisher).
(top)

Basic Roles

The publishing model developed below is based on the concepts of managing formal and informal content as described in earlier chapters. The primary function of these roles is for managing formal content, although a few rules apply to informal content areas as well. Organizations may have other roles defined, but these are the core roles that every organization needs to fill:
  • Administrator
  • Publishers (sometimes called "Content Owners")
  • Editors (Sometimes called "Content Managers")
  • Authors (sometimes called "Content Creators")
  • Webmasters
These are roles, and the names may vary from one company to another. For example, the editor role at one company is called a "Gatekeeper." However, the role is essentially the same, a project manager for formal content. A brief description of each of the roles follows to help you identify the substance behind the various names.

INTRANET ADMINISTRATOR

Description:

The Intranet Administrator is responsible for coordinating and facilitating the overall functioning of the Intranet. The focus is primarily on the strategy, organization and quality of the Intranet as an effective communication environment. Where the Intranet Administrator reports organizationally varies widely from one company to another. I have seen the role filled by  CIOs, direct reports to the CIO, the V.P. of Quality and the V.P. of Corproate Communications. Regardless of where they report organizationally, this position should be filled by a senior level person.
 
 
Responsibilities: Skills:
  • Chairperson of the Web Council 
  • Develops and champions the overall Intranet strategy within the company 
  • Monitors, facilitates and coordinates the development of all Intranet policies and standards 
  • Coordinates policy, standards and management interfaces with other organizations 
  • Develops and presents executive awareness and update programs 
  • Monitors and coordinates Intranet skills requirements and training at all organizational levels 
  • Owns the Intranet standards documentation 
  • Owns the top level of the Enterprise Map 
  • Understands Intranet technology capabilities and their pragmatic application 
  • Able to focus on business needs and opportunities over technology 
  • Has a passion for enabling distributed capability and decision making 
  • Able to synthesize diverse opportunities into cohesive strategic frameworks 
  • Excellent speaking, writing and leadership skills 
  • Able to develop rational justifications for Intranet programs and investments 
  • Able to generate credibility with and respect from participants at all levels 

PUBLISHER

Description:

The publisher is responsible for determining what information her organization regularly provides to others, both inside and outside the corporation. Each major organizational or functional unit will have a publisher. When we view information as the primary driver of business functions, this role defines the interfaces to all other organizations and clearly is the responsibility of the functional head of the business unit.  In practice today, this role is filled by a person who reports directly to the functional head of the organization or business unit.
 
Responsibilities: Skills:
  • Develops the content approval process for her organization 
  • Identifies and negotiates the information input requirements of her organization 
  • Identifies and negotiates the information output requirements of her organization 
  • Chairs her organization's Editorial Council 
  • Monitors, facilitates and coordinates the implementation of all Intranet policies and standards within her organization 
  • Owns her organization's standards for formal information 
  • Represents her organization on the Web Council 
  • Understands the business and how information drives her organization's functions 
  • Able to understand Internet technologies and their application to the business functions 
  • Has a passion for enabling distributed capability and decision making 
  • Able to develop and implement effective policies and standards 
  • Excellent speaking, writing and leadership skills 
  • Able to develop rational justifications for Intranet programs and investments 
  • Able to generate credibility with and respect from participants at all levels 

EDITOR

Description:

The editor performs the role of project manager for the creation and management of formal information related to a specific area or focus in his organization. Most large or complex organizations have several editors, one for each focus. The editor determines  which specific information needs development or attention, identifies and obtains the authoring (or programmer) resources, manages the project through the development and review cycles and formally publishes the sanctioned information for which he is responsible. These roles  generally exist outside the Intranet with titles like, Product Manager, Marketing Manager, Software Development Manager, etc. Note that information also can be software logic, product specifications, product designs or manufacturing processes. Therefore, the term "editor" as used here includes the project managers of these functions in addtion to the traditional document-based meaning, if the output is published on the Intranet.
 
Responsibilities: Skills:
  • Identifies specific information required for a project 
  • Identifies and obtains the resources required to complete the project 
  • Develops and manages project schedules and timelines 
  • Ensures that information follows corporate and organizational policies and standards 
  • Identifies and manages the appropriate reviews and sign-offs 
  • Publishes the the approved content on the proper servers 
  • Participates as a member of the Editorial Council 
  • Works with the webmaster to ensure proper availability, access controls, backup and archiving 
  • Excellent organization skills 
  • Ability to identify and document project requirements 
  • Ability to develop, document and manage to realistic project timelines 
  • Ability to understand and manage to corporate and organizational policies and standards 
  • Excellent speaking, writing and leadership skills 
  • Understanding of when to use pull versus push publishing technologies 
  • Ablity to generate credibility with and respect from participants at all levels 

AUTHOR

Description:

Authors create the basic content on the Intranet. The content may be textual, graphical or logical (software code). Generally, content is created for a specific purpose. However, once available, content often is redirected toward other purposes. The Intranet can amplify the ability to reuse and redirect content. Intranet authors need to keep this in mind, and create content that both meets the proximate requirement and remains as modular and flexible as possible.
 
Responsibilities: Skills:
  • Meet the information requirements of the immediate audience 
  • Adhere to creation, presentation and interface standards 
  • Design and organize content to be flexible and reusable 
  •  Expertise in the content field 
  •  Understanding of Intranet presentation technologies and options 
  • Good presentation (writing/progamming/etc.) abilities and practices 
  • Ability to use appropriate creation (authoring/programming) tools 
  • Good understanding of vendor-independent, Intranet standards and protocols 

WEBMASTER

Description:

The Webmaster is responsible for maintaining the Intranet technical infrastructure and provides the bridge between the technology and its use by non-technical specialists. The focus is on enabling the domain specialists and their communities of interest  to communicate and innovate on the Intranet with as little direct dependence on technology specialists as possible. The role has two major aspects: technical architecture and administration, and support and user services. A Corporation may have multiple webmasters filling these roles for one or more web servers. The "grand-webmaster" coordinates the overall technical standards and may chair an Intranet Technical Council consisting of the other webmasters.
 
Responsibilities: Skills:
Technical 
  • Administers and maintains one or more web servers and their software 
  • Provides backup and archiving of web server content 
  • Administers and ensures that access control and security requirements are met 
  • Acquires and installs shared applications, tools and libraries that enable domain specialists to create and maintain their own content and solutions 
  • Provides and maintains the Intranet search engine 
  • Provides interfaces to corporate databases and legacy applications 
  • Provides or arranges for custom Intranet application support to domain specialists 
Support 
  • Reads and takes timely action on "Webmaster" email: 
  • Forwards domain specific Webmaster mail to the appropriate people 
    • screens out "junk" mail 
    • answers generic site mail 
  • Informs domain specialists of new Intranet enabling capabilities 
  • Provides or arranges for training on how to use the client-side tools 
  • A strong desire to enable non-technical users and make them self-sufficient 
  • Experience with systems administration, systems programming 
  • Experience with web servers and web-based applications 
  • Experience with object-oriented approaches 
  • C, C++, Java programming 
  • CGI, Perl script programming 
  • Experience with DataBase Management Systems 
  • Good interpersonal communication skills 
  • Strong writing skills 
(top)

Enabling Functionality

The functionality required to support the basic organizational development process is neither complex nor expensive, if the basic IP network infrastructure already is in place.
  • Each publisher and editor needs to have access to the intranet (connection and a browser)
  • Each publisher and editor needs to have a user-friendly HTML authoring tool and basic graphics tool that saves in GIF and JPEG formats
  • Each publisher and editor needs to have a place to publish his/her pages and an easy way to put pages there, by themself
  • Ideally, a web-based discussion forum (threaded discussion) capability will be provided on the Intranet for use by the Intranet Council
  • Early in the implementation, a spider-based search engine needs to be implemented, to find and catalog content.
One additional consideration:
  • A room needs to be provided for the workshops where the participants can share computers (ideally 2 to a computer) that contain the authoring and publishing tools they will use and a connection to their intranet publishing sites.
For organizations with slow responding technical support, most of this functionality can be provided with a Micro-webserver. These servers require zero technical administration and are priced at around $1,000 (see  Cobalt Microservers, Compact Devices and Microtest).

A word about browsers. As stated in an earlier chapter, the community-owned standards are  what make this technology work, and the browser is where those standards become real. Since the two major vendors continually have some features that are not yet standard, and not shared by both, the consumers are left with the responsibility of enforcing the standards in their own organizations, if they want the benefits of this revolution to last. There really are three choices. The first is to give up, standardize on one brand of browser and let the organization drift into the proprietary hooks - a solution with many expensive risks down the road. The second is to standardize on one brand of browser and attempt to enforce the adherence to community-standard features in all pages  - an expensive, on-going policing and  enforcement exercise. The third is to mix both major brands of browsers among the community - a structural checks and balances solution. The authors  have to stick to the common standards or half the audience cannot  use their content. 

MIS types often argue that it is too expensive to support two brands of browser, an argument I have never understood. Browsers are one of the least support intensive applications on computers, ever. And, if the issue is that individuals will call the help desk when a page contains a non-standard construct that  their browser  cannot  read, the solution is just as simple. There is an owner name and contact information on the page, tell the caller to register the complaint there. This is not an MIS or help desk problem. It is cheaper to support two brands of browser  than to try to enforce the standards explicitly, or face yet another ad hoc integration effort when the next unforseen requirement emerges. 
(top)

Adoption

The adoption process can be accomplished through a series of staged workshops that help each participant:
  1. Understand the role
  2. Accept the challenge
  3. Identify key decisions
  4. Explore the issues
  5. Discuss known strategies
  6. Receive support in the decision process.
I generally use a seminar and three types of workshops to facilitate the adoption process. The Awareness Seminar is used to educate executives (and others) on the general nature of an Intranet, specific management issues that need to be addressed and the publishing and roll-out model that I use.  The Planning Workshop is for the publishers. Using a series of exercises, it helps the publishers understand the issues and the role. At the end, the participants are asked to accept the role for their organization or identify the correct person to replace them. This is followed by the Publishers' Workshop. The exercises in the Publishers' Workshop help each publisher identify and begin making key decisons. At the end, the publishers capture their results by building their Map Pages and identifying their editors. The last exercise in the Publishers' Workshop is the formation or initialization of the Web  Council. The exercises in the Editors' Workshop continue the process down to the editors' level. In the process, the editors extend the Map Pages and begin identifying Intranet content and projects that they intend to implement.
(top)

Participation

 The biggest barrier to participation is the lack of an enabling infrastructure for the publishers, editors and authors. If the technology is too complex or restricting, the policies and rules are too severe or the initial publishing standards are set too high, the publishing and communication will remain spotty. If the publishers and editors are encouraged to experiment and push the knowledge and publishing ability further down into their organizations, a critical mass of participation will emerge rapidly. This is why an important component of the workshops is to provide a permanent publishing space for each participant, and to have them publish at least one page in that space during the workshop.

During the participation  phase it is important to use the Web Council as a source of both support and competition to slowly raise the content quality bar, not through official policies, but through pride and competition. It is during this period that the few simple policies, the  Map Pages and the organizational roles will help keep the process manageable. It is also during this phase that a spider-based seach engine will become a required function.

If you begin to hear many complaints about "too much" information (or content of unknown quality because you did not implement an identifying logo for formal information as suggested below) take that as a sign that you are reaching critical mass. Your Intranet now has a life of its own, and the Web Council can turn its attention to tuning and coordinating activities.
(top)

Rules of the Road

Policies should be viewed like traffic laws. They should be kept to a minimum, and their function should be to help everyone reach their individual destinations with minimum interference and maximum safety. The first rule of the road should be that all other policies that apply to behavior using other communication media, also apply to the Intranet. This includes all of the harassment, good taste and confidentiality policies that your organization most likely has.

Second, there are some rules that apply to all pages, formal or informal, to help others who might access the page determine what they are looking at. These rules are what I call the "Triad," because there are three of them:

Rules for Every Page
Every page, formal or informal must include:

  • Explicit Identification of the Page Owner
  • The Date of Last Revision
  • A way to Contact the Owner
In some companies and industries, a fourth rule is added: the level of confidentiality, so the viewer knows immediately with whom they can share the information on the page.

Formal Publishing Standards
In addition to the rules for every page, it is wise to develop rules for formal pages - those pages officially published by a sanctioned organization within the corporation.

  • Each formal organization should develop an explicit Review Process
  • The corporation should adopt an Identifying Logo for formal content that can only be used by the editors on pages that have completed the sponsoring organization's review process
  • Formal pages should state the official Access Status - who can see this content
  • A corporate or organization specific Look and Feel may be appropriate
  • Consistent high level Navigation Aids should be developed as a standard
(top)

Awareness Seminars

The Awareness Seminar is a lecture format presentation used to introduce intranet organization concepts to executives and potential publishers and editors. The basic structure of the presentation I use is:
  • Internet and Intranet Background
  • Intranet Benefits
  • Intranet Issues
  • The Management Model
  • The Implementation Model
The Awareness Seminar creates a common level of understanding about the process and sets expectations for what is to come.
(top)

The Planning Workshop

The workshops all follow a similar pattern. They begin with generative exercises designed to explore the conceptual territory to be covered. This is followed by individual (or in this case, small group) exercises designed to begin focusing. Next are review exercises that support decision making. Finally, there is a "planning" exercise that focuses on what needs to happen next.

Specific  goals or outcomes to be achieved at this workshop

  • Understand  role as both  information consumer and publisher
  • Understand responsibilities as an information publisher
  • Identify key classes of information that need to be managed
  • Identify specific publishers for the information classes
  • Identify technical support and training requirements to fulfill publisher role

What is expected of the participants in the workshop process

  • Collect, share and explore their own domain requirements and commitments
  • Support (and challenge) each other  in focusing and decision making
  • Identify and plan individual and community goals
(top)

The Publishers' Workshop

The Publishers' Workshop follows a sequence of exercises similar to those described in the Planning Workshop.

Specific  goals or outcomes to be achieved at this workshop

  • Understand the structure and role of the publisher
  • Support each individual publisher in making basic decisions
    • what information his/her group will sponsor
    • who will create and manage it
    • how it will happen
  • Create the top level of the Management Map
  • Initialize the Web Council

What is expected of the participants in the workshop process

  • Collect and explore their own domain requirements and commitments
  • Support (and challenge) each other in focusing and decision making,
  • Plan and implement community goals
  • Recognize that this is a community, everyone is both a producer and a consumer of information, so everyone will be expected to put on both hats at different times during the day
(top)

The Editors' Workshops

The Editors' Workshop follows a sequence of exercises similar to those described in the Planning Workshop.

Specific  goals or outcomes to be achieved at this workshop

  • Understand the structure and role of the editor
  • Support each individual editor in making basic decisions
    • what information (s)he is responsible for managing
    • how it will happen
    • what support is required
  • Aquire basic strategies and skills for creating and managing intranet information
  • Create the editors' level of the Management Map
  • Create an  index page to support brokering to different audiences

What is expected of the participants in the workshop process

  • Collect and explore their own domain requirements and commitments
  • Support (and challenge) each other in focusing and decision making,
  • Plan and implement community goals
  • Recognize that this is a community, everyone is both a producer and a consumer of information, so everyone will be expected to put on both hats at different times during the day
(top)

Author Training

 Author training is not the same type of workshop as the previous three. It focuses more on teaching new skills required for this medium than on management decisions. However, in addition to teaching how to use the various authoring and publishing tools, it is important to educate the authors on the management concepts and policies of the organization. Therefore, if you choose to have a third party provide the technical training on tools for your authors, you  still  should create a session that covers the management and policy basics. In most organizations I have worked with, the role of author training and support has been  handled by the webmaster function, often as a half-day, hands-on class offered at regularly scheduled times.

Two points to consider in author training. First, while it is important to encourage content creators to adopt these skills, training the secretarial and administrative support staff in authoring skills can be one of the most effective approaches to developing critical mass. It often is a secretary who "types-up" and distributes meeting minutes and other documents that are ideal for Intranet publishing. They often adopt the new medium faster than other positions in the company, and can act as a facilitator in moving the managers and staff they support to the new approaches, particularly if coached to do so. Second, don't just teach technology; teach HTML style too. A book that I find particularly good in this area is Bryan Pfaffenberger's The Elements of Hypertext Style.
(top)

The Web Council

The Web Council often goes by different names. It sometimes is called  the Intranet Council, the Intranet Steering Committee, the I-net Council, or other names.  The function is to provide a forum for community discussion, coordination and decision making. In a very large organization, for example a conglomerate of companies or a large government body, one might have more than one level of Web Council. Each company, operating unit, or agency might have their own Web Council, with a cross company or agency Web Council being formed of  the Web Administrators from the constituent organizations. The concept is scalable if need be.

The following is a generic structure for a Web Council:

CHARTER:

To guide the development and evolution of Web technology as a tool to improve communication, business processes and profitability within the enterprise by promoting effective business use and supporting community owned standards, diversity and enablement of the intranet community and its individuals.

MEMBERSHIP:

Each major line and support organization should have a member on the Council. This person will be considered the "Publisher" of information for that organization. Publisher in this context refers to the business and organizational authority, not the technical implementation. The member should have the ability to commit his organization to the development, maintenance and sharing of specific intranet content and to negotiate information requirements from other organizations. Members need to understand the business processes and information flows of the organization they represent. They do not need to start with an understanding of  Web technology, but must be committed to gaining an understanding of intranet capabilities.

COUNCIL RESPONSIBILITIES:

  • Provide a forum for discussion of issues on effective  I-net* use and usability
  • Negotiate organizational and individual commitments for ownership of key I-net content
  • Share and promote useful  ideas and skills among the Council and within the members' organizations
  • Facilitate the development and brokering of  I-net  policies and standards
  • Collect and  support requirements on current and future I-net needs
* I-net refers to the enterprise use of this technology across the Intranet, the Internet and Extranets. The broader context is included here, because most Web Councils broaden their scope to cover the use of the technology and infrastructure regardless of the access decisions made about specific sets of content.
(top)

A Few Words About ROI

Return On Investment (ROI) is a question that frequently gets raised during Intranet planning exercises, so it needs to be addressed here, even if definitive answers are not possible. A number of studies have been conducted on Intranet projects with ROIs ranging from over 1,000 percent to a more modest 20 to 40 percent. Why the big difference? It  depends on who did the study, who was studied and, most importantly, what variables were considered legitimate in calculating the  return. Like the security discussion in Chapter 5, ROI can be reduced to a very simple formula:
 
ROI =
Incremental Revenue
or Savings - Investment 
Investment
 X 100

But also like security, applying the ROI  formula in complex strategic decisions will involve the participants' assumptions and comfort levels more than straight arithmetic.

If you require an ROI to proceed with an Intranet project, then surfacing these personal assumptions and discomforts becomes critical. There are no easy answers on how to do this. Peter Schwartz's, The Art of the Long View provides one approach, based on scenarios and story telling as a way to understand the variables and implications of decisons. Peter Senge's, The Fifth Discipline, provides another approach, based on systems thinking and language to help see inter-relationships that are separated by perception and time.

However you get to the variables that will be used, there are three steps that must be completed for a credible ROI:

  1. You must have explicit objectives for the project
  2. You must have appropriate measures for the objectives
  3. You must collect baseline data before starting
Because many Intranet projects deal with existential objectives, rather than referential objectives, coming up with appropriate measures can be a major challenge. The easiest measure is calculating direct monetary outlays, which is why organizations have a tendency to rely so heavily on this measure, even though it often is not the most important factor  for the organization's long-term health. The next easiest is calculating increased revenue. However, even here assumptions and feelings begin to dominate the equation. As we move to time, knowledge, innovation and satisfaction as important organizational outcomes, the difficulty of agreeing on explicit value continues to increase. Yet these latter outcomes often are the ones that  keep organizations from getting to the desparate point where cutting costs in a struggle for survival becomes the only option in a re-enforcing,  downward spiral.

I find it interesting that ROI seems to work best when the project involves improving an existing, budgeted, process. "By doing it the new way we save this much or can produce that much more for the same cost." It is more difficult to produce ROI numbers for new processes, new approaches and new infrastructures. We can tell the ROI on the new phone system (compared to the cost and features of the existing one), but how many companies, even today, can calculate the ROI on having a  phone system at all? Even with all the experiential information we have, from decades of use, it still would be a difficult undertaking to quantify and get agreement on the value of the basic phone system in new-project, ROI terms. If you don't believe it, try it in your own organization.

However, the importance of subjective decisions  is not confined just to  projects involving existential objectives. Even projects with the easiest measurements, direct money outlays, can involve subjective decisions and untested assumptions. Let's take a look at an important, and expensive, cycle to which nearly every business can relate. 

A high percentage of companies use Microsoft Office for their primary document creation. A high percentage also pass these documents around electronically. This requires the reader to have Microsoft Word or Excel or PowerPoint in order to read the electronic version. Most companies and consultants like myself have these programs for just this reason. Our clients and partners pass us documents in these formats, and we can't read them without the proprietary software. 

We are about to enter on another round of a predictable cycle,  a new version is being released. Like most new versions of proprietary  products,  previous versions of Word, etc. cannot read anything created with the newer version, even if the document does not use any new formatting or other features. Of course, the author can explicitly save a copy of the document as a down-level version, but this adds a level of complexity to the management and sharing of documents that is annoying at best. The result is tremendous pressure to upgrade to the latest version, even if you don't need the new functionality,  just to share documents with the partners, clients and other internal departments who upgrade first. 

I suspect that most companies eventually will make this upgrade without a serious ROI study of the options. In fairness, many companies will evaluate the worth of the new features compared to the costs of upgrading. And many will delay the upgrade for some period of time. However, most will make the switch eventually  based on the reactive costs of not being able to share documents with those who have switched, or finally,  lack of vendor support,  rather than positive forward benefits. 

As stated above, ROI seems to work best in comparative situations, so an obvious scenario would be to investigate the ROI of moving to community-owned standards for documents as compared to upgrading to the latest version of the proprietary product. The Internet and Web technologies are based on community-owned standards. This is what makes them work. One of the major standards is the HTML document standard. There are several advantages to this standard over the proprietary document protocols of the past. One is that any HTML document can be read or modified with any HTML editor (even a straight text editor for those with the inclination). Therefore, documents can be shared with anyone without worrying about whose brand of software was used to create it. A second advantage is that HTML readers (browsers) display what they know, and just ignore what they don't. Thus, if I have a down-level reader (browser) I still can read much of what is on most pages. 

Nearly every company today has the ability to generate their documents in HTML. What is the ROI for moving your company to an HTML standard as opposed to upgrading to Office '97? On the expense side, you may be able to forgo the proprietary upgrade for many employees by looking at other,  less expensive, WYSIWYG HTML editors that provide more HTML functionality, and you probably won't have to upgrade the hardware. Anyone who has Office '97 can use it as an HTML editor by saving the documents in HTML format rather than Word format. How would the ROI shift if you requested your partners to send all documents in HTML instead of Word, and began using HTML versions as the "official" managed versions of documents for your department or company as opposed to upgrading to Office '97? It used to be that printing was an issue with HTML, but ForeFront's WebPrinting for Windows  now provides a solution. 

On the cost side, you may have to do some additional training if you decide to move people to a less expensive, more functional  HTML editor. And, some people complain that HTML does not let them do formatting that is as sophisticated as their proprietary applications. However, one should even do an ROI on this. What is the cost of the sophisticated formatting capability that cannot be duplicated in HTML versus the return  that the sophisticated formatting provides to the business? You may even want to investigate if  moving to more basic formatting actually improves business content and understanding.  On the training side, look at how much training really would be involved for people who already use word processors, and is it really any more than the training required to use the new word processing  functionality that you are paying for in the latest version of your proprietary word processor? 

Finally, don't forget the run-out to the next cycle. We can assume that a new version is already in the works. What is the ROI on beginning the move to community-standard content now, so that when the next cycle comes around you have more choice in whether and how fast to transition to new features. In general, the community-standard content allows you to add functionality in pieces, and continue to share content in highly mixed environments more easily and for longer periods of time than the mega-application model of the proprietary products. 

The point here is not whether you should or shouldn't upgrade to Office '97. The point is that most companies will not even ask these questions in an ROI context as they prepare to spend the money. Not only do ROIs contain many subjective assumptions and drivers, but the process often is applied unevenly and with varying rigor across our businesses. 

The final point mentioned above on ROI was collecting baseline data. This is critical, unless the ROI was just a project rite of passage  that will be put on the shelf and ignored once the project is approved. This is particularly true if you need measures for anything other than the basic accounting numbers that most organizations collect routinely. If you don't know the starting point, how do you know if you really improved? As an example of a non-accounting measure, in my planning  workshop, I use a pre-workshop data collection exercise that gives the participants some insight into their own (and the aggregate group's)  information overload quotient. I encourage the participants to do this exercise on their own again as their intranet develops, as a very personal way of seeing how (or if) their control over their own information flow is improving.
(top)

Summary

Implementing an Intranet begins with an explicit understanding of the objectives being sought. If the primary focus is on implementing specific technical functionality for delivery on an intranet, then existing application development approaches can be used, with appropriate modification  for the new tools and techniques. If the primary focus is on organizational adoption and development, then a people oriented approach is required. 

The approach presented here was based on five steps: identifying the roles, providing the enabling functionality, facilitating adoption of the roles and skills, encouraging participation and providing enabling policies and structure. Roles were suggested and defined, and a series of workshops was described as a way to introduce and support distributed decision making in the organization. The creation and publishing of Intranet Map pages by each participant during the workshops, in a way that each could continue on his own after the workshop,  was viewed as critical to the success of the effort. 

The chapter concluded with a discussion of the issues around ROI and Intranets. Calculating ROI can be difficult, and requires some careful thought. While the formula for ROI is simple and appears objective, there are many implicit assumptions behind the numbers that complicate the issues. The most effective use of the ROI technique appears to be the comparison of an already implemented and budgeted process to the new process. An example of how such an ROI might be constructed to justify moving to HTML as the document standard in an organization was given. 
(top)

Next Chapter
Table of Contents


Original Version: October, 1997
Last Updated: October, 1997
Copyright 1997 - Steven L. Telleen, Ph.D.
info@iorg.com


  top page | papers


For more information contact: info@iorg.com
© Copyright 1997-1999 iorg.com