Chapter 8: Planning and Implementation

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

---

• Introduction
• An Approach to Organizational Development
• Basic Roles
• Enabling Functionality
• Adoption
• Participation
• Rules of the Road
• Awareness Seminars
• The Planning Workshop
• The Publishers' Workshop
• The Editors' Workshops
• Author Training
• The Web Council
• A Few Words About ROI
• Summary

Introduction

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

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.

Basic Roles

• Administrator
• Publishers (sometimes called "Content Owners")
• Editors (Sometimes called "Content Managers")
• Authors (sometimes called "Content Creators")
• Webmasters

INTRANET ADMINISTRATOR

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

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

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

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

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

• 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.

• 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.

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

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.

Participation

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

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

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

Awareness Seminars

• Internet and Intranet Background
• Intranet Benefits
• Intranet Issues
• The Management Model
• The Implementation Model

The Planning Workshop

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

The Publishers' 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

The Editors' Workshops

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

Author Training

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 following is a generic structure for a Web Council:

CHARTER:

MEMBERSHIP:

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

A Few Words About ROI

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

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

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