The perfect portal implementation: Eight steps to heaven

Based on six years’ experience of portal-technology deployment at organisations around the world; Enterprise Information introduces an eight-step approach for successful portal implementation.

By Mike Ferguson

Six years on from the emergence of enterprise portal technology, the word portal has become one of the most abused terms in the industry. Everyone with a web interface is now claiming they have a portal. Not so – they are not a concept, they are real software products. A portal provides internal and external users with a single, integrated, personalised (role-based) and secure web-based interface to business processes, information, applications and collaborative tools. Figure one is an example of a portal containing portlets – parts of the screen dedicated to providing the user with access to many different back-end systems. These go under many different marketing names, including portlets, gadgets, iViews, modules and pagelets.

One of the most frequently asked questions at portal seminars and workshops is what is the difference between enterprise portal technology and an intranet? A major difference between the two is personalisation. With portal technology, every user gets a different or personalised view unlike an intranet, where all users see the same pages. Portal implementation is therefore the successor to an intranet; the next generation that aligns content more precisely with the role of each and every user. These personalised views are sometimes called role-based portals, for example a sales manager’s portal, a procurement manager’s portal, a financial administrator’s portal, etc. Personalisation means that a user has authorised access to several portal pages, which each contain a set of portlets that provide access to the information, applications and collaboration tools that the user needs to do their job. If the user changes role then they may no longer have access to some portal pages but will be able to view others that are relevant to their new position in the organisation. Within their security profile, users can switch between portal pages via tabs or menus. However, portal products are much more than a personalised, web-based user interface. Portal products support:

Single sign-on security;
Personalisation services;
Taxonomy development and navigation services;
Information publishing;
Automated information discovery and categorisation services;
Search notification and delivery services;
Collaboration tools and workflow services;
Content management and storage;
Integration with applications and business processes;
A development kit for customising the portal user interface, adding new web devices and building back-end portlets.

But these products are not a panacea. Their main role is to offer user interface integration. This is a very important point because many people get confused as to what a portal can do for them. Portals are not the answer to data integration, application and business-process integration or people integration. Additional software, which is identified in figure two, is needed for these tasks and can be easily integrated with portal technology. Today’s vendors are now supplying content-management and collaboration tools with the portal, as well as beginning to offer interfaces from portal software to these other software components. This implies that companies are looking for an enterprise-integration technology ‘stack’, in which the portal is just one piece. Cleary, they want to start this enterprise integration journey by implementing portal software, collaboration and content/document management first. Also, many organisations implementing portal software are re-evaluating their content and document-management strategies and how they use collaboration tools.

One of the attractions to portal technology is that it is cheap and usually quick to implement. For instance, administrators can fairly rapidly create role or task-based portal templates, consisting of portlets assembled into parameterised portal pages that are wired together and saved in a template. Authorised end users can then pick up these templates as a ‘quick start’ and rapidly create role-based portals for people in their business area. It is this rapid deployment that often delivers fast return on investment (ROI).

Step one: The business case and portal planning
More often than not, companies struggle with how to justify investment in portal technology to the business. One way to tackle this is to learn from companies with successful portal implementations such as Pratt & Whitney, Ford Motor Company and Herman Miller, to name a few. If you look at many of the winning case studies presented at the Annual Portal Excellence Awards, they all have one thing in common regarding the business case. This is that they focussed on how to use portal technology to help improve a specific key performance indicator (KPI), to achieve better business performance. The focus of these companies was to first, understand the strategic objectives and targets in their business strategy and then look at how portal technology could help the company reach those targets. In the example case studies shown in the table below, the IT departments justified portal technology to the business by stating how the portal, combined with appropriate business content (applications, information, and collaboration tools), would provide maximum improvement in a specific KPI. Therefore, the portal was not ‘sold’ to the business as a stand-alone solution. On the contrary, portal technology was justified along with a subset of applications and other information that would be able to deliver something to the business and/or external users that was currently not possible.

To help the business case on its way you should also try to enlist a business champion (sponsor) as early as possible. If your business case is focused on KPI improvement, then the obvious candidate for the role of sponsor is the executive that owns the KPI and holds responsibility for making that improvement happen.

It is likely that he or she will manage a business unit with good visibility and a strong business need for access to integrated business content that will show a quick ROI. If IT is seen to put forward a business case to someone that tries to improve on the KPIs they own, business backing is likely to materialise quickly.

Assuming this happens, planning needs to start rapidly. It should involve:

Setting up a portal-development team;
Establishing a repeatable development and deployment methodology for iterative portal deployment. On each iteration, this methodology should target a combination of information, applications and collaboration tools at a specific user community and different roles within it. One way of doing this is to set the intended scope for the portal around core business-process tasks. Alternatively, scope could be limited to a specific business functional area. The main objective of the methodology is to iteratively deploy the right content to the right user communities to help improve the business case KPI in their area. It should then delegate administrative responsibility to a content manager in that area before moving on to the next iteration;
Defining portal-governance guidelines to establish policy, procedures and standards;
Defining an implementation plan consisting of core implementation plans and milestones;
Basing portal deployment on a delegation strategy so as to distribute content management and administration responsibilities across the organisation to nominated power users.

The development team should include people with content and business knowledge, a corporate librarian to help with taxonomy design, business process and application-integration experts, a web-security administrator, a portal administrator, application developers for portlet development, and an enterprise architect. In addition, content managers should be created around the business areas throughout the process.

Portal governance is also vital for long-term success. Policies and procedures should be developed to establish guidelines, rules and regulations to manage portal implementations. This includes policies on:

Security;
Common look and feel (for example, templates to be used in publishing content, portal customisation, branding etc);
Content authoring, approval and publishing, as well as content archiving;
Common business vocabularies to be used in taxonomy design;
Taxonomy integration across departments and business units;
Sub-portal integration with enterprise portals;
Web-service integration and portlet-development standards, for example shared code libraries;
Administration and ownership, and usage reporting;
User training.

Step two: Understand user functionality and content requirements

Currently most business users struggle with multiple user interfaces to systems, logging on and off every application. Typically, applications are not integrated with other information that the user needs to be more productive. In many cases, a user has to make use of multiple applications, websites, documents and other sources of information to complete a particular task. In addition, mobile workers such as sales-force or field-service employees often do not have access to applications, while business partners or customers have no self-service capabilities. All of this is symptomatic of a company without portal technology. The challenge in this step is to understand what combination of content/documents, business intelligence, collaboration tools, applications and business-process tasks that each user community needs to have access to via the portal. The device also needs to be taken into account – some mobile users will need access via a mobile phone or a PDA. Different users have different requirements, which must be fully understood and accounted for to successfully deploy portal products.

To do this requires undertaking a content usage study for a nominated user community. This will help you to understand how user communities throughout the organisation use business information. It should also identify the content that you want the portal to manage. Importantly, this needs to be done while keeping an eye on business benefit, so that what is delivered in a role-based portal will help specific users contribute to improving the KPI identified in the business case. The content usage study should identify relationships between different content from disparate systems and thoroughly document how identified business communities use this content. More specifically, it tries to identify which roles users perform: the processes and tasks performed by people in each role; what content they use to perform the tasks; who uses the content; what devices they use to access it; who they share it with (internally or externally); and, how they collaborate with others. In this case, the term ‘content’ is used in the broadest sense of the word, to mean a combination of application functionality, BI, unstructured information, collaboration tools etc, which each role requires in a specific community of users. That community could include internal and external users or a combination of both.

Clearly this content-usage study is not intended to be carried out across the enterprise. It should be done iteratively. One way in which people do this is to follow a core business process to help them focus on specific user communities.

Using figure 3 as an example (an airline business) there is clearly a content-usage study to be done for agents, passengers, cargo customers and handlers, airport staff and suppliers.

Each iteration of the portal development and deployment would involve identifying communities and performing a content usage study in the area selected for deployment, for example cargo handling. Once we have this information, we know the business needs and have the data required for personalisation (used in the very last element of our methodology). At this point we are ready to perform step three, which will be the focus of the second part of this series in next month’s issue.

Mike Ferguson is managing director at Intelligent Business Strategies Limited.

Develop the portal business case and plan for portal implementation;
Understand user functionality and content requirements;
Define a portal architecture and select, install and integrate portal products;
Develop the portal taxonomy and categorisation scheme;
Design and customise the portal user interface;
Develop the security and single sign-on architecture;
Develop, implement and integrate information, collaboration and applications with the portal;
Personalise and prototype to create multiple role-based portals, train users, and deploy portal technology in a phased manner.