Success Factors for the Implementation of Enterprise Portals

INTRODUCTION

The implementation of enterprise portals is still ranked top on the wish list of many CEOs, expecting that the portal becomes the core system for offering a flexible infrastructure that integrates and extends business applications “beyond the enterprise” (Hazra, 2002). By 2009, the market for application integration, middleware, and portals is expected to grow to $7.1 billion, with a 5-year compound annual growth rate of 2.7% (Correia, Biscotti, Dharmasthira, & Wurster, 2005).

The success of enterprise portals is not astonishing, since the portal concepts promise to provide secure, customizable, personalizable, integrated access to dynamic content from a variety of sources, in a variety of source formats, wherever it is needed (Amberg, Holzner, & Remus, 2003; Collins, 2001; Davydov, 2001; Hazra, 2002; Kastel, 2003; Smith, 2004; Sullivan, 2004), enabling core e-business strategies by running supportive portals like knowledge portals, employee portals, ERP portals, collaborative portals, process portals, and partner portals.

However, after the first wave of euphoria, the high expectations of companies became more and more realistic, taking into account that portal projects are complex, time-and cost-consuming, with a high risk of failure. In complex portal projects, costs and benefits to build up and operate an enterprise portal are weighed up in a systematic manner, including make-or-buy decisions with regard to packaged portal platforms vs. open source developments, individually developed vs. purchased portal components (so called portlets), and benefits vs. costs to run, maintain, and improve the portal (Hazra, 2002).

Altogether, the growing demand for portal solutions is leading to an increasing attention in regard to the management of critical success factors (CSF). In contrast to many studies and surveys covering aspects about the portal market and technological features of packaged portal platforms, there is still little known about CSF and best practices when implementing enterprise portals. Considering these critical factors, portal implementation projects can be directed and managed more effectively.

The goal of this article is to present the most important factors that are critical for the success of the implementation of an enterprise portal. In order to better understand these factors, we first provide background knowledge on basic tasks, actors, and relationships in typical portal implementation projects. We then present a comprehensive list of CSF, together with a categorisation framework, classifying these factors into tactical vs. strategic, technical vs. organizational, static vs. dynamic, and stage- vs. nonstage-specific CSF.

BACKGROUND: THE PORTAL VALUE CHAIN

At present, the market seems to be in a strong consolidation phase, in which many small vendors are put out of the market or bought up by the big vendors of portal products, that is, IBM, SAP, Plumtree, or Oracle. We assume that, in the long-run, the market might split up into vendors that provide portal frameworks, vendors that are specialized in building portal components (portlet suppliers), and service providers who will integrate the components to a complete portal solution for the customer (portal integrator). The whole portal industry might shift continually towards a multilayered supply chain—comparable to the automotive or the mechanical engineering industry (see Figure 1).

During the configuration of portals, portlets of different portlet suppliers can be combined and integrated into the portal solution. Portlet package suppliers integrate portlets to larger, Web-based, industry-specific components (so called portlet packages) that can be delivered either to portal integrators or directly to end customers. This can be portlet packages especially developed for electronic commerce, knowledge management, or for collaboration. Portal integrators are responsible for the integration of complex portlets and portlet packages at the customer’s side; therefore, designing and installing portal frameworks, customizing and integrating suitable portlets and portlet packages, and supporting the corresponding project management with coordinating different tasks between portlet suppliers, portal vendors, as well as portal providers and users.

CRITICAL SUCCESS FACTORS

In order to analyse the CSF, we followed a multimethod design of a two-stage approach, with the first stage analysing the state of the art of portal engineering by reviewing relevant literature and interviewing portal integrators in Germany (Remus, 2005), and a follow-up stage with a focus on “critical success factors.” In order to identify and analyse CSF, we chose portal integrators as the target group (in contrast to client companies implementing portals), because portal integrators have the necessary expertise to give in-depth answers to our mostly explorative questions, as they have already been involved in several portal projects implementing packaged portal software. In addition, we reviewed literature on scientific papers and case examples, and finally compiled a list of 21 relevant CSF (applying the coding procedures proposed by Glaser & Strauss, 1967). We also refined the CSF of portal engineering by comparing these with CSF of other IS implementation projects, (i.e., ERP projects). The following list briefly describes each CSF, together with its relationship to portal engineering, in alphabetical order:

Figure 1. The portal value chain

• Business Process Reengineering (BPR): In order to achieve the greatest benefits provided by an enterprise portal, processes and activities have to be aligned with the new system. In many cases, the underlying business processes have to be redesigned before the portal solution is deployed and customized. The question here is if activities in business processes have to be changed before, during, or after the portal implementation. This CSF has strong relationships to the CSF process and application integration.

• Change Management: Introducing enterprise portals can cause resistance, confusion, redundancies, and errors. Often, portals provide a completely new work environment based on new user interfaces structuring content, services, and application in a very different manner. In addition, they often provide new functions and features that, at first, can overload the user. As with other large-scale IT projects (e.g., ERP), companies often underestimate the efforts in change management (Somers & Nelson, 2001).

• Clear Goals and Objectives: Similar to other large IT projects, clear goals and objectives are seen as critical success factors (Esteves & Pastor, 2000; Nah Fui-Hoon, Lau Lee-Shang, & Kuang, 2001; Somers & Nelson, 2001). Objectives that are specific to the scope of the corporate portal project, the user community that is affected, and the timeline that needs to be met have to be formulated (Collins, 2001).

• Dedicated Resources: As with other software implementation projects, resource requirements need to be determined early in the project. Not rarely, it is difficult to secure resource commitments in advance (Reel, 1999), especially because portal projects tend to affect other related ongoing IT projects, for example, ERP implementation, KM initiatives, or SCM projects.

• Defining the Portal Architecture: Different perspectives are considered. The portal’s information architecture defines, for example, the navigation, the portlet structure, the role concept, and the personalization (Sullivan, 2004). With regard to the organisation, the adaptation to the organisation’s architecture is the hardest part, which ties up a lot of time and resources. One important task is to align the portal architecture with the general IS architecture, as interfaces to other systems, for example, ERP, CRM, SCM, have to be defined.

• Flexible Project Structure: Software implementation projects are carried out in an ever-changing environment. In order to handle unforeseen problems, the project structure has to be flexible. This is especially critical with regard to portal engineering with its multiple actors, the large number of portlets, and different views and users involved.

• Organizational Culture: Portals are a new way of working and communicating. The organization needs to recognize the importance of cultural factors, affecting how employees work together (Collins, 2001). The success and acceptance of many portals, that is, knowledge portals, are heavily dependent on the user involvement. The willingness to share knowledge is playing an important role in knowledge portals, as portal users are seen as an active part in the evolution of the portal.

• Portal Design: The design of the user interface is derived from business activities and processes, typically described by use cases. It should be intuitive and designed according to general design and navigation guidelines, but also implementing the specific requirements gathered during the analysis phase. Often, a storyboard is defined that contains several screenshots demonstrating how the self-service applications and corporate portal software features are integrated into the user interface, along with a script that describes in detail the user interaction of the portal (Collins, 2001).

• Portal Engineering Roadmap: The implementation of portals is combining concepts from the field of Web-based development together with concepts derived from the implementation of large packaged software solutions, that is, ERP implementations. Sophisticated methods, instruments, and work procedures from both fields have to be integrated into a comprehensive portal engineering approach, often supported by a component-based development approach and service-oriented architecture (Hazra, 2002). This approach can be supported by a roadmap that defines the basic steps towards the implementation of a corporate portal.

• Portal Strategy: A portal can only be successful if the corresponding portal strategy, which outlines the development, introduction, and evolution of the portal, is aligned with the e-business and overall corporate strategy (Davydov, 2001). According to its strategic e-business focus (B2B, B2E, B2C), different types of portals have to be implemented, for example, enterprise partner portals, knowledge portals, electronic commerce portals. A business case collects all relevant information with regard to the implementation of the portal strategy, among other things identifying risks, potentials, and CSF (Collins, 2001).

• Process and Application Integration: In order to integrate processes, the underlying application and information architecture has to be integrated and made available through the portal. Several portal-related technologies enable process integration, for example, “drag and relate,” as concepts to support interaction between portlets, and to provide workflow management mechanisms to enable ad hoc and flexible workflows. An important task is the definition of a portal integration architecture, which combines integration technologies such as portlets, EAI, and Web services. These technologies support the integration on different levels, that is, human-to-machine integration, interorganizational, and machine-to-machine integration (Puschmann & Alt, 2005).

• Project Management: Project management for portal projects, which is similar to other IT projects, spans the life of the project from initiating the project to closing it. The project should have clear, mutually agreed and understood project and business objectives that correspond to the project deliverables. Typical success factors are the application of balanced planning and time management rules, the application of appropriate standards and templates, the existence of a supportive infrastructure, and team building measures, ensuring synergy effects from teamwork (Juli, 2003).

• Project Monitoring and Controlling: To ensure the project completion according to the plan, close monitoring and controlling of time and costs should be done (Kendra & Taplin, 2004). In addition, the implementation project scope and plan has to be reviewed (Esteves & Pastor, 2000).

• Prototyping: In contrast to common sequential process models for software development, (rapid) prototyping is a cyclic process consisting of four stages: conception, realisation, test, and refinement. The cycle is carried out until the prototype has reached the desired maturity. The stepwise alignment to the final portal solution minimizes the developmental risks. Furthermore, team members can see the progress of the project, and so-called quick wins may improve the motivation within the project team, as well as the cooperation with the client.

• Requirements Analysis: Analysing requirements is always complex as it involves the joint effort of portal integrators, consultants, and clients to analyse the requirements of the portal from many different perspectives: IT economics, business processes, applications, potential user roles, and profiles. Often an initial business case outlines the main features of an enterprise portal (Collins, 2001).

• Selection of the Appropriate Portal Package: Similar to ERP-packaged software, the choice of the portal package involves important decisions regarding budgets, timeframes, goals, and deliverables (Somers & Nelson, 2001). In addition, issues concerning the selection of portlets and portal packages delivered by third-party vendors have to be considered.

• Strong Communication Inwards and Outwards: In analogy to the implementation of ERP systems, interdepartmental communication, as well as the communication with customers and business partners in each implementation stage, can be seen as a key component (e.g., in the analysis of CSF for ERP systems by Somers & Nelson, 2001, this factor ranks on number six). In many IT projects ,poor communication between team members and other organisational members was found to be a problem (Ang, Sum, & Chung, 1995; Grover, Kettinger, & Teng, 1995).

• Team Competencies and Skills: The success of portal projects is related to the knowledge, skills, abilities, and experiences of the project manager, as well as the selection of the right team members, who should not only be technologically competent, but also understand the company and its business requirements (Somers & Nelson, 2001). This is especially true in the field of portal engineering, where different people from various fields work together, that is, portlet developers, EAI specialists, portal integrators, enduser, business domain experts, business consultants, and so forth.

• Top Management Support: Corporate portals are like ERP systems; highly integrated information systems. Their design, implementation, and operation require the complete cooperation of line and staff members from all segments of the business (Zhang, Lee, Zhang, & Baneijee, 2003). Furthermore, in a corporate strategy team, an executive sponsor, who needs to be involved in all aspects of the corporate portal solution, should be identified (Collins, 2001). This sponsor may play the integrational role between the development team and the top management.

• User Acceptance: The success of the implemented portal is heavily dependent on the acceptance of the user, not only because enterprise portals provide a central access point for multiple enterprise application, services, and content, but also because its long-term success is heavily dependent on the usage of the portal.

• User Training and Education: Since portals provide a completely new user interface, together with changed or new processes, it is crucial to train potential users on how the portal works and how the new functionality relates to the business processes. Often, in complex portal projects, consultants are involved. In this context, it is important to ensure that knowledge is transferred from the consultants to internal employees.

Classification of CSF

In order to further analyse the CSF, we classified the identified CSF into the following dimensions (see Table 1):

• Organizational vs. Technical Factors: The technological perspective (see, e.g., Esteves & Pastor, 2000) refers to technical aspects related to the particular portal package, whereas the organisational perspective is related with concerns like organisational structure, culture, and business processes. Here, we can see a good balance between organisational and technological factors; however, with a tendency towards organizational CSF.

• Tactical vs. Strategic Factors: With regard to the time frame (see, e.g., Esteves & Pastor, 2000) of the portal implementation, we further distinguish between the strategic (long-term goals related to core competencies) and the tactical perspective (short-term goals related to business activities). It is interesting to see that in portal projects, the consideration of short-term technological factors is an important issue.

• Static vs. Dynamic Factors: Static factors are showing the portal readiness, demonstrating the capacity to start and successfully carry out a portal project. Dynamic factors, in contrast, are related to activities in the implementation process, and are therefore describing factors that can be managed actively. We can identify a strong focus on dynamic factors that can be managed during the portal project. Static factors demonstrating the portal readiness are of moderate importance and only important from the organisational point of view; there are no static technological factors to particularly focus on.

Table 1. Categorization of CSF

• Stage-Specific vs. Nonstage-Specific Factors: This classification refers to the implementation process. Stage-specific CSF are more critical within certain stages, whereas nonstage-specific factors are important throughout the whole implementation process. With regard to the stages of implementation, we can identify a well-balanced set of factors. However, it is interesting to see that, with one exception (portal engineering roadmap), all technical factors are stage specific.

How can this framework be utilized by researchers and practitioners? Both can use the framework to further analyse the CSF with regard to different perspectives. Researchers can detail their CSF research, focussing on one or two distinct dimensions, for example, strategic, organizational CSF. Practitioners can use the framework to identify those CSF that can be managed more actively throughout their portal projects, for example, focussing on specific tactical, dynamic CSF.

CONCLUSION AND OUTLOOK

Based on preliminary studies that collected qualitative data about the main characteristics ofportal projects, we identified and classified the most important factors that are critical for the success of implementing enterprise portals. However, more research has to be done in order to further investigate the relevance of CSF, in general, and in particular across the stages of implementation (Remus, 2006).

Our findings can be seen as the starting point for proposing and developing instruments that can improve the engineering and management of portals. This is particularly important since, at present, neither integrated tools to select portal components, nor tools to support the whole portal value chain are provided by portal vendors or service providers. Hence, when planning, customizing, and implementing new portals, organizations have to start from scratch.

From a technical perspective, we suggest focussing on the dynamic, portal-specific CSF, which canbe actively managed by the use of software-supported tools and methods. In order to support the tasks of the portlet supplier, standards to develop portlets have to be developed and pushed forward (e.g., JSR 168, standards for remote portlets (WSRP)). In particular, SMEs need corresponding portlet standards, that is, redbooks or manuals, providing particular procedure models and guidelines for the development of portlets. With regard to the portal user, we suggest to focus on easy-to-use tools and end-user development approaches, where the user is much more integrated into the software development than in common methods. End-user focused prototyping is a first step in this direction. In particular, portal integrators in charge of consulting clients in portal implementation projects urgently need an integrated bundle of suitable instruments to support the entire development process. These instruments should focus on the requirements analysis and the preselection, the assessment, and the integration of portlets in a portal platform. Specific tools, for example, tools to calculate the TCO or ROI, tools supporting the search and integration of portlets, and modeling tools (Hazra, 2000) have to be developed. Furthermore, in order to guide the requirements analysis and the subsequent customization process, the portal integrator can be supported by industry-specific reference models and best practices (Sullivan, 2004). Here, once more, standardization will lead to industry best practices, reference models, and prebuilt portals.

KEY TERMS

Enterprise Portal: An application system that provides secure, customizable, personalizable, integrated access to a variety of different and dynamic content, applications, and services. It provides basic functionality with regard to the management, the structuring, and the visualization of content, collaboration, and administration.

Portal Engineering: Characterized by the systematic use of engineering-like methods and tools, for example, roadmaps, reference models, and so forth. in all stages of the implementation process. Typical tasks within the development process comprise the development of portlets, the customization and integration of portlets in a portal framework, and the roll out of the portal solution.

Portal Integrator: Responsible for the integration of complex portlets and portlet packages at the customer’s side; therefore, designing and installing the portal frameworks, customizing and integrating suitable portlets and portlet packages, and supporting the corresponding project management coordinating different tasks between portlet suppliers, portal vendors, and portal users.

Portal Strategy: As described in the business case, outlines the development, introduction, and evolution of the portal. The strategy should be aligned with the E-business and overall corporate strategy. Different types of portals for example, enterprise partner portals, knowledge portals, electronic commerce portals, support different e-business strategies (B2B, B2E, B2C).

Portal Value Chain: Can be described as a multilayered supply chain, described by its main actors and its relationships involved in developing portal solutions. Software vendors are split up into vendors specialized in integrating components within prebuilt portal frameworks, vendors of portal components (portlets), and vendors who concentrate on the development of subsystems.

Portlet: Can be viewed from different perspectives: In the end, a portlet is nothing more than a window displaying the preferred content, whereas the portal administrator views portlets as content container resources. From a technical perspective of a portal developer, a portlet is an individual application component (servlet) hosted and running in a portal server.

Portlet Package: Portlets can be integrated to larger, Web-based, industry-specific components (so called portlet packages) that can be delivered either to portal integrators or directly to end customers. This can be portlet packages especially developed for electronic commerce, knowledge management, or for collaboration.