A Two-Tier Approach to Elicit Enterprise Portal User Requirements

INTRODUCTION

Organizations are increasingly turning to enterprise portals to support knowledge work. Portal deployment can be intra-departmental across several business units in one organization or even inter-organizational. Currently in the industry, most of these portals are purchased solutions (e.g., collaboration and smart enterprise suites) and many of these purchasing and selection decisions are primarily driven by the interest of a small group of stakeholders with strong influence from IT vendors. The true requirements for the portal as well as the strategy for its medium- to long-term phased deployment are, in general, poorly addressed. This, together with other reasons, has lead to many failures or to a low adoption rate of the enterprise portal by staff at various levels of an organization. Common problems that hinder portal adoption include lack of an overall governance model, mis-alignment withbusiness processes, poor or non-existent content management (process, tools, and governance), and technical problems associated with the development and configuration of portlets. This article focuses on one critical issue that directly influences the success of an enterprise portal deployment, namely the correct elicitation of user requirements (which in turn lead to the chosen portal’s features and to the style of the portal interface). Taking into consideration the advancement and landscape of commercial portal vendors in the market, this article discusses a bottom-up approach to the identification of high-level drivers for portal usages for its users.

Reasons for a Low Portal Adoption Rate

A survey of387 organizations by META Group (Roth, 2004) has revealed that although portal adoption among organizations is strong (e.g., some 35% in mid-2003), there have been plenty of setbacks in sustaining or enhancing user adoption of a portal after it has been deployed. Based on the authors’ experience gained from working on various KM systems and portal projects (in theAsia Pacific region), prominent reasons why an enterprise portal are under-used include:

• The portal is difficult or unpleasant to use due to poor interface design and to information being difficult to locate. This may include a lack of coordination of the information stored in various portal pages, and inadequacies in the user interface design as well as in the tools provided in the portal.

• Compared to an intranet, the response of a portal is generally slower because of the additional abstractions and messages passing between system components in and outside the portal. Slower responses, needless to say, cause user frustration.

• Portal content may show a lack of integrity because of duplication and inconsistent information in the portal. As a result, users soon lose interest in accessing the portal for purposes of information retrieval. Without a single unique sign-on solution, portal users often get annoyed as they need to remember and enter multiple sets of user “IDs” and passwords when accessing different parts of the portal

• Nearly all portal deployment is top-down and enterprise-driven. There is a strong governance on the creation and regulation of documents, folders, and communities/discussion boards. As such, it is often time-consuming to go through the administrative procedures in order to set up a portal (or a portal community space for collaboration).

• Some organizations exert too many restrictions on the use of the portal such as specifying the maximum size of documents that can be uploaded. Certain portal users are permitted to upload only content that is in pre-defined folders. These are issues related to over-governance.

• Some portal interfaces are not aligned with the needs of the users. For example, mobile workers generally require lite-access to their enterprise/project portal via handheld devices.

• Because of personal habit, convenience, or speed of access, many users resort to old sources (e.g., Intranet) to retrieve the information they seek without going through the portal. After a portal has been deployed, many organizations fail to eliminate (i.e., close-off) the previous access-points hence compromising the single gateway concept/value of having a portal.

• Many employees find enterprise portal capabilities far inferior to the Internet/Web portal that they are now so familiar with (Weiss, Capozzi, & Prusak, 2004).

• Sometimes there is a lack of focus on portal content as insufficient funds are being committed for data migration, content maintenance and features upgrade (Murphy, Higgs, & Quirk, 2002).

• The features, tools, and content provided in the portal do not always align with the business processes or with the KM strategy.

• Not paying sufficient attention to the creation and maintenance of a taxonomy and meta-data, users experience difficulties in locating the needed information via search and navigational means.

• A poor or non-existent change management program means that users are ill prepared for the launch of the portal. This means that they do not appreciate the full potential of the portal.

APPROACHES TO COLLECTING USER REQUIREMENTS

To address the previous problems, the authors have developed a framework and a system to systematically find out what an organization requires of a collaboration tool or portal. The proposed framework adopts a two-tier approach to elicit the user requirements regarding the importance and priority of several well-known and commonly used functions (Collins, 2003) of a portal. These are

• information and communication;

• collaboration and communities;

• content management;

• business intelligence; and

• learning.

The aim of the first part of the proposed framework is to identify the primary and secondary purposes of the portal. This is done by collecting responses via surveys and interviews involving a series of very different sets of questions from various stakeholders including decision-makers, professional staff, and end users. Once the primary and secondary purposes of the portal have been identified, additional and in-depth requirements will be further elicited (via various methods including anecdote circles (Callahan, 2004), narratives (Snowden, 2002) and/or sense-making (Dervin, 1999)). Focus and control groups will then be established to gauge the effectiveness of the framework when it is applied.

FRAMEWORK FORMULATION

Enterprise portals are designed for work processes, activities, and user communities so as to improve the access, workflow, and sharing of content within and across the organization. Recent evolution and consolidation in the portal marketplace have to lead to a handful of portal vendors offering portal products with, as far as enterprise applications are concerned, varying degrees of product strength. Regarding the deployment of an enterprise portal, Collins (2003) stated that the basic functions of the corporate portal should include content management, collaboration and communities, business intelligence, and learning. In practice, the Delphi Group found that nearly 75% of customers believe portals should be deployed with search, content management, and collaboration functions (Plumtree, 2003). According to a study by IDC on enterprise portal adoption trends (eINFORM, 2003), more than 55% of the respondents indicated that portal software is used internally as a productivity tool for employees, rather than as a tool for partners or customers. The major interests of companies when purchasing software to support portal initiatives are Web-based reporting, Web development tools, Web content management, e-mail, document management, data warehousing, and so forth. The previous reinforces information and communication, collaboration and communities, and content management as some of the key drivers for adopting a portal.

In addition to the previous requirements, Raol, Koong, Liu, and Yu (2003) also pointed out that business intelligence is one of the key drivers for using a portal. Also, Neumann and Schupp (2003) stated that e-learning makes an important contribution to the accessibility, transparency, and maintenance of knowledge management in a corporation. In fact, more and more e-learning material and activities are delivered via a portal interface nowadays.

In summary, we propose a framework to collect the user requirements of the portal that may include these five major components: information and communication, collaboration and communities, content management, e-learning, and business intelligence. The branches under each of these categories have been summarized in the following mind maps (Figure 1). Each branch has a set of specific questions to ask. The results are collected, counted, and weighed in different branches. Sample questions are listed in the next section.

QUESTIONNAIRE DESIGN

Kim, Kim, Park, and Sugumaran (2004) propose a multi-view approach based on the structuring principles of Davis (1990) for complex software requirements. The multi-view approach is a hybrid method that combines the strengths of scenario-based analysis, goal-based analysis, case-driven analysis, and on coupling the goal with the scenario. All the views have one or more activities imbedded in them, which improve the elicitation and analysis processes.

Figure 1. Different branches of portal functions

Compared with Davis (1990), we have adopted a more functional view and have incorporated Ambler’s (2005) emphasis on the collaboration or involvement of the key stakeholders’ interactively. The survey is the first step to elicit high-level user requirements. The questions measure the relative importance of the functions in contributing to the respondent’s requirements for individual and collaborative knowledge work. Each question is measured on a four point Likert-type scale: “strongly disagree,” “disagree,” “agree,” and “strongly agree” plus a “not applicable” option.

In our questionnaire design, we have adopted Snowden’s (2002) approach to deal with complexity and the use of narratives. The key to his approach is not to ask a direct question as human beings may not tell the truth; they may even selectively emphasize and de-emphasize their answers to provide the story they want to tell. Therefore, we have phrased the questions indirectly in order to avoid mentioning obvious terms like “content management” and “business intelligence.” This is done to deliberately dissociate the function names from the vendors’ software market hype, as well as to avoid assuming that the survey respondents have any preoccupation of IT-based KM systems.

Therefore, in deriving the questions, we have adopted the following guiding principles:

1. To ensure discriminative ability, no question focuses on a feature that is common across all the categories (e.g., search).

2. A question should be related to one or more of the common knowledge processes that occurs in an organization. Such processes may include, for example, knowledge creation, codification, storage and retrieval, sharing, distribution, and measurement.

3. A question will be asked if and only if it is strongly associated with one or more characteristic in the targeted categories.

4. The set of questions should not be excessive; we expect the questionnaires to be completed within fifteen minutes online.

The derived set of questions aims to elicit high-level requirements rather than mapping user requirements to the vendor’s product offerings. The following is a set of sample questions for the first tier. It aims to identify different stakeholders’ primary drivers for adopting a portal. Discussion on each of the major categories of drivers are as follows:

Information and Communication

Within the enterprise, there are many communications among different parties. These include corporate announcements, departmental communications, and inter-departmental communications. Sometimes, people are reluctant to use the portal as a platform to communicate and may have the problem of information overload and junk e-mails. This is due to the poor design of the communication channels (e.g., bulletin board, newsletter, e-mail, and FAQ) and poor classification of user groups for the dissemination of information. As a result, staff spends a lot of time reading through e-mails, announcements, or documents they have received. More importantly, some information or documents may be irrelevant to their current work. Besides, some e-mail communications come with the request for existing documents or business transaction forms. Organizations are now turning to a collaboration tool or portal as it provides a common platform for centralizing all such communications. A portal makes it possible to refer to documents or Web pages via embedded links, instead of having to ask for them to be sent as e-mail attachments.

Table 1. Sample questions for the first tier questionnaire

Therefore, we propose to collect the information and communication requirements for handling corporate announcements, departmental communications, inter-departmental communications, e-forms, and for setting up a centralized information/document repository. Users will know where to locate the latest master copy and be alerted to the presence of new or amended information. We have designed the questions to identify what kind of information will be exchanged (i.e., documents or forms) in their business processes and workflow, what channels staffs are expected to use for communication or information exchange, how often staff will communicate with each other and how the document and e-form can be stored, posted, disseminated, and retrieved.

Collaboration and Communities

Nowadays, many enterprises need to cooperate and work together. This is due to the fact that often a single organization does not have all the expertise it needs. To successfully implement a collaborative enterprise or extended enterprise, it is important to understand the needs of the collaboration work and to know how the communities in the enterprise contribute to the collaborative activities (Lee, Cheung, Tsui, & Kwok, 2006). Staff at different levels have their own knowledge domains and can contribute to different parts of the tasks in different projects. Successful collaborative work depends on, among other things, the knowledge domain of the team, their past experience, their experience sharing in their currentjobs, the compatibility ofthe technical platforms, and on ways to work collaboratively (Katzy, Evaristo, & Zigurs, 2000).

We propose to collect the requirements of an enterprise’s collaborative work, best practices, and navigation links in their collaboration and community activities. Collaboration may include organizing a meeting, finding a contact, hosting/attending a meeting, jointly making a decision, and follow-up work. We design the questions to identify what kind of collaboration work is taking place among the participants; what collaboration tools are appropriate for them, which group(s) of staff they communicate with frequently; what are the best practices for their collaboration work, and how staff can access and navigate to find the information and services in the collaboration space.

Content Management

To better manage the corporate content that appears in various applications (e.g., Internet Web sites, intranet pages, various repositories, and databases), the process of content creation, updating, and posting need to be identified and embedded in the everyday business processes. It is crucial that information needs be properly classified into different categories to facilitate search and retrieval. Different users may have different interpretations of the same set of information. On many occasions, the low accuracy of information retrieval is due to the poor design of the information taxonomy. Content management is concerned with, among other things, the tagging of meta-data with documents and Web pages, the establishment and ongoing maintenance of the information taxonomy, the associated roles and responsibilities of staff involved, and the lifecycle process of content creation, publishing and archiving.

Many organizations turn to a collaboration tool or portal with the previous as their primary goal. We have designed questions that help to identify the processes of content indexing, updating, posting, and retrieval.

Business Intelligence

Applying business intelligence (BI) to an organization’s operational data can help that organization to plan, analyze, and predict their business. However, staff at different levels of an organization often need to view/analyze different types of data. For example, a business development manager may want to track the sales orders and stock supply that he or she is responsible for. In contrast, an executive may want to view, aggregate, and predict the sales trends and volume for the entire region along one or more product lines. There are many products on the market that serve as analytical and reporting tools for different levels of staff in an organization to view and manipulate the data. These tools operate on back-end databases and often rely on the use of data-marts and/or warehouses for data aggregation and presentation as well as provide support for explorative queries (e.g., “what-if” analysis). Several of these tools now come with a portal interface allowing individual users to customize the user interface for their own source(s) of data and presentation format.

Organizations that adopt this approach to deploy a portal/collaboration tool are generally attracted to the concept of a “dashboard” or BI portal. In our questionnaire design, we have specifically focused on questions that ascertain the need for and priority for data aggregation, presentation, and reporting.

E-Learning

Mounting pressure on cost reduction and on the need to provide education to a dispersed workforce have lead to many global organizations adopting some form of online or e-learning system for their staff’s professional development. E-learning not only frees the learner from the location and time restrictions but the learning content can also be delivered in relatively short periods of time (e.g., 10-15 minutes each session) and interleaved with practice (e.g., role play, simulations, and games). The use of a portal interface further amplifies the power of e-learning as a portal supports personalization by a user (learner) and provides access to multiple applications (hence supporting the learning and practice cycle). Understanding the learners’ competence, their expectations, preferred delivery channel(s), and communication mode(s) are critical to success in deploying an e-learning system.

In our questionnaire design, we attempt to find out whether online learning is crucial for the participating organization and if so, whether a portal interface can add further value to the learning environment and outcome.

CURRENT DEVELOPMENT

Ambler (2005) stated that “to apply the right technique for each situation they encounter, effective developers keep multiple requirements elicitation techniques in their intellectual toolkit.” He discovered that stakeholders can make a significant contribution throughout the project’s lifecycle. Collaboration with the stakeholders is critical and it is recognized that the elicitation of requirements is an ongoing activity, whereas the approach should be flexible; one size does not fit all. Out of the many ways to elicit system requirements, one good method is to keep stakeholders actively involved with modeling.

Ambler (2005) has further listed out nine different requirement elicitation techniques, namely, joint application design (JAD), observation, electronic interviews, legacy code analysis, reading, active stakeholder participation, on-site customer participation, focus groups, face-to-face interviews. However, the first five methods are traditional techniques with restricted interaction and some weaknesses. The latter four elicitation techniques involve more collaboration and interaction. People tend to give voice to more private issues, and information can be elicited more quickly from a single person during face-to-face interviews. In focus groups, significant amounts of information can be gathered quickly. For the on-site customer technique, decisions are made in a timely manner because information is provided to the team in a timely manner. People with domain knowledge define the requirements in active stakeholder participation technique, information provided, and decisions made are in a timely manner.

We should adopt a combination of the above techniques, in conjunction with the narratives/anecdotes and sense-making approaches, to collect secondary portal requirements. We believe the stakeholders should be involved (from start to completion) in the surveys and/or workshops conducted throughout the elicitation phase.

We are also expanding the existing category to cover business process management (BPM) and an elaborated set of questions will be published later.

ADOPTION OF THE TWO-TIER REQUIREMENTS IN INDUSTRY

Up to now, the following organizations/departments are completing or have completed the (online) survey (see Table 2).

More precisely, we intend to couple the gathering of second-tier requirements with a range of methods (e.g., sense-making, anecdote circles, interviews and further in-depth surveys). Comparing and contrasting the data and observations gained from these approaches serves as a good basis for further research. Results comparing the effectiveness of our approach with alternative methods after the above trials will be the subject of future publications.

Table 2.

CONCLUSION

In summary, the proposed framework is designed to identify the right stakeholders and to collect the right user requirements. Therefore, the first tier questionnaire will identify the primary drivers for adopting a portal. The second tier of questionnaires is to be delivered via a combination of survey, workshops, and interviews with the key stakeholders that are sponsors, decision markers and users of the portal. We believe this method can overcome the problems inherent in the traditional methods of collecting requirements for an enterprise collaboration tool. With this new framework, the organization can have a bottom-up and systematic way to collect the user requirements and ensure the alignment of the requirements with their business processes, needs, and goals.