Portal Building 1411661591, 9781411661592

Citation preview

Portal Building Implementing an Enterprise Portal

Dean Barber

Contents Acknowledgements

i

Introduction

iii

Research

1

1

Enterprise Portals Defined

3

2

Why Implement a Portal?

21

3

Portal Vendors & Their Solutions

29

4

Current Organizational “Snapshots”

35

5

What Others Are Doing

45

6

Portal Requirements Creation

49

7

RFIs & RFQs

59

8

The Product Selection Process

67

Planning

79

9

Change Management - People

81

10

Executive Sponsorship

89

11

Forming the Team

95

12

Budgets

101

13

The Project Plan

107

14

Project Charters & Secondary Documents

119

15

Approving the Plan

125

Building

131

16

Development Issues

133

17

Project Charters

147

18

Setting up the Infrastructure

153

19

Consultants

161

20

Bringing in Other Teams

167

21

Governance Structures

173

22

Communication Plans

181

23

User Training

193

24

Metrics & Measurements

201

25

Demos, Demos, Demos

207

Enriching

215

26

Looking to the Future

217

27

Processes

223

28

Governance Structures

229

29

Feedback & Metrics

237

30

Internalizing & Institutionalizing

243

Acknowledgements The information contained within this book has been developed from all of the Portal implementation projects that I have been involved with. As such, I would like to take the opportunity to thank all of the people that I have had the pleasure of working with on these Portal projects. The information that was shared has not only helped me professionally but personally as well. I would also like to thank Vance for putting the idea of writing this book into my head. Without that initial encouragement, this book would not have been started. And finally, a special thanks to Shelley for her patience and understanding while I was “locked” away working on the book.

i

Introduction The term Enterprise Portal has been appearing with increased regularity in a variety of business and information technology literature over the past number of years. There has been a number of books, articles, white papers, etc. written about the benefits that a company can receive by implementing an Enterprise Portal. After reading the majority of these books, the reader is thinking, “Ok, great. You’ve got me convinced that my company can achieve these benefits by implementing an Enterprise Portal. Now what?” Very few books have been written to answer this question. (And those that have been are usually focused on a more technical audience.) I have written this book with the goal of educating a business-centric audience on what an Enterprise Portal is and how to implement one in their organization (although technical people can also benefit as well.) The points / suggestions that I bring up in this book are based on my experiences in implementing a number of Portals and from observations on how others did it as well. Because of this, some of the points in this book may not follow “Generally Accepted Project Management Principles / Practices.” Whenever I bring up such a point, I will explain my reasoning for the deviation and why it is required in the “real world”. The implementation of an Enterprise Portal is more of an art than a science. This is true due to the fact that each organization is different with respect to priorities, fiscal issues, culture, etc. Also, an Enterprise Portal is very user / person centric. Its total focus is on allowing the end-user to become more self-sufficient and more efficient in their work and personal life. Also, implementing an Enterprise Portal requires a great deal of effort by individuals to ensure that the business processes of an organization are ready for a Portal. To this end, implementing an Enterprise Portal in an organization is a highly customized process that cannot be churned out in a mass-production fashion. That being said, this book will highlight some of the core processes that are similar throughout companies; how they are implemented is where the customization part comes in.

iii

iv

Introduction

Enterprise Portals have the ability to touch everyone within an organization, including a company’s customers and suppliers, and all of a company’s processes. Because of this, no two companies will implement the same Portal, and their implementations will also be different due to the culture and style of the employees and the people on the implementation team. However, the core processes of an Enterprise Portal are similar across companies; how they get implemented (if at all) will be different. To this end, this book contains suggestions of the main points of a Portal implementation. The reader is left to decide which parts of the book are appropriate to them. (Help on making this decision is also provided.) As you will tell from reading this book, this book is different than most business books. To begin with, instead of focusing on what the book contains, I will concentrate on what this book doesn’t contain. That way, you can immediately tell if this book is right for you. - This book does not contain any “Top 10” lists. As I mentioned earlier, each company should view an Enterprise Portal according to their own pain points / requirements. It is hoped that after reading this book, and conducting an analysis of their own requirements, the reader will be able to create their own “Top 10” list that will be more relevant to them than a generic one that applies to all users. - This book should not be followed page-by-page when implementing a Portal. Some of the topics that are found in the later half of the book will need to be considered at the beginning of a Portal implementation project. (I have structured the sections in a rough chronological order for ease of reading.) - This book will not list all of the Enterprise Portal solutions on the market and rank them. (If you’re looking for this book to tell you what Portal solution is the best, you won’t find it.) What this book will provide you with is a series of questions (and no, there will not be a list of the top 10 questions), that once answered, will allow the reader to make their own rankings. - One of the benefits from implementing an Enterprise Portal is that it allows for a more complete “self-service” mentality to flourish within a company. In line with this, this book has been written as a “self-service” application as well.

Introduction

v

This book has been divided into 4 sections that roughly follow the implementation of an Enterprise Portal. (In fact, I use these 4 categories when I develop and explain Portal implementation project plans.) The 4 sections are: Research, Planning, Building, and Enriching. The Research section contains chapters that focus on what the reader needs to know in order to properly select the appropriate Portal solution for their company. This section will contain a description of what an Enterprise Portal is, what its main components are, and what it can do. It will also describe what information needs to be collected about the company itself that will assist in the determination of the proper Enterprise Portal solution. The Planning section is focused on the topics that are required in order to get ready for the actual work of implementing a Portal. After the company has selected their Portal solution, everyone is usually eager to begin work and put the software solution to work. Care must be taken to properly plan out the project, especially one as large and complex as a typical Enterprise Portal implementation. The Building section of the book describes the points that should be considered when the dust begins to fly and work begins on the Enterprise Portal itself. This section will contain a few chapters on the technical aspects of building a Portal, but it will mainly focus on the business processes that are usually over looked until the last moment. The final section, entitled Enriching, describes the processes associated with the continuing evolution and enhancements to the Portal. Whether you decide to phase your Portal in, or bring it in with a big bang, a Portal needs to continue to mature and expand its functionality in order to remain of value to its users. By structuring the book into sections that correspond to the major phases of the actual implementation, the user is able to focus on the information that is most appropriate to them at the time of reading. With this is mind, if one reads the book from start to finish they will

vi

Introduction

notice that certain points are repeated in a number of different sections. It is not my intention to write this book to provide the reader with all of the answers to their questions concerning the implementation of an Enterprise Portal. (This would be very difficult since I don’t know what your questions are.) But I did write this book to provide you with the information on how to formulate the questions and where to look to get the answers to these questions. Hopefully, after reading this book, you will be able to find the answers to the questions that will result in a successful Enterprise Portal implementation that will contribute to improving your organization’s success in its marketplace.

Research

Research Similar to most implementation projects, this book is divided into a series of major milestones / deliverables, one for each section. This first section, entitled Research, deals with all of the issues that need to be discussed during the early stages of implementing an Enterprise Portal. In order for the people involved in this project to make qualified decisions, they need the proper information to base these decisions on. This information can only be collected by doing research. This section will deal with the two types of research required for a project of this scope; external research and internal research. External research deals with exploring what the current capabilities of Enterprise Portals are. (This section also contains a few chapters on defining Enterprise Portals for those who are unclear exactly what a Portal is.) The respective Portal vendors and consulting company offerings should also be examined for potential assistance during the building phase of the project. And finally, some time should be taken to examine what other companies are doing with their Enterprise Portals; especially what your competition is doing. Internal research refers to examining your own organization to discover what you really need. What are your organization’s pain points? What does your current infrastructure look like? Do you have any vendor agreements in place? What is the company culture? Have you already begun implementing an employee self-service model? These are just a few of the questions that need to be asked from an internal perspective in this stage of the project. This section ends with a number of chapters devoted to how to take all of the information that was collected and distill it down so that a recommendation of the proper Enterprise Portal solution for your organization can be made. I will discuss how to create (or re-use) a defensible process that can be used to make a proper recommendation, (with supporting documentation), to the project sponsor and executives so that a decision can be made.

1

2

Portal Building

The milestone for this section of the book, and therefore this part of the project, would be a defensible recommendation to the executives on which Enterprise Portal solution is best for your organization. From this recommendation, a decision can be made on what Portal solution to purchase, which allows the team to then move to the next phase of the project: Planning.

1 Enterprise Portals Defined Webster’s dictionary defines the word Portal as “a gate or doorway, especially a great or magnificent one; any entrance”. Computer based Portals first appeared as applications that tried to integrate a variety of information sources into a single user interface. The goal was to free the user from having to access a number of different information sources to find the information that they needed. Modern groupware applications (like corporate email applications) became “pseudo-Portals” since the majority of the important information a user needed in a day was distributed in their email. For this reason people began hoarding their emails on the belief that the information might one day be needed. As this hoarding continued, it became more and more difficult to find the relevant information in a timely manner. The fact that people use their emails as a personal document management system also taxes the email infrastructure causing application failures and increasing expenditures to ensure that the infrastructure can keep up with the demand. It soon became clear that a separate application was needed to handle this information distribution. When the Internet became popular, these Portal products moved to the web, taking advantage of the Internet browser’s ability to display information no matter what computer the browser is running on. By focusing on the Internet browser as the access point to their Portal application, software vendors promised to allow a greater number of people to access them and to allow users to access “their Portal” from anyplace that could access the internet. As business users began to see the benefits of early Portals, they began to try to incorporate not only information sources into the Portal but business applications as well.

3

4

Portal Building

Enter the Enterprise Portal The goal / vision of an Enterprise Portal is to provide “one-stop shopping” for users for everything they need to do their daily job. The emphasis here is on providing a personalized view or access to all of the information sources and applications that each user needs. The concept of a Portal has been with the business world for some time; however it has not been until rather recently that computers and their associated programming languages and standards have matured to the point to enable the creation of Portals in the business world. By taking a look back at the early beginnings of computers, we can see how the concept of Portals has evolved along with the computers themselves. When personal computers began to become popular in the business environment, they used an operating system called Disk Operating System, (commonly referred to as DOS). This operating system was difficult to use and only allowed one application to be run at a time. Although the computer allowed for greater efficiencies over manual processing of information, users soon reached the limits of improved efficiencies since they could only access information from one application at a time. For instance, if a user was writing a report they may have to access a spreadsheet application for some information; either print the required information out or write it down and then close the application. They would then need to open a word processing application and manually enter the spreadsheet data into the document. Seeing the limitations of the DOS operating system a company called Microsoft marketed a new operating system called Microsoft Windows. Not only was this operating system easier to use than the previous system but it also allowed for more than one application to be accessed at a single time. It even allowed for information in one application to be shared with another application, (and added the words “cut & paste” to everyday business talk). This allowed for specialized applications to be developed that focused on one aspect of the business. This operating system became so popular that the majority of business applications are written to run on it. However, business users soon began to feel the same way as their pre-Windows

Enterprise Portals Defined

5

colleagues, only this time they are encountering problems with too many applications providing too much information in their daily work. The term “information overload” became a common occurrence in the work environment. Software companies then began to focus on creating separate applications that tried to bring together all of the information sources a user needed on a regular basis. The most popular of these early Portals were Internet based and were usually associated with an Internet search engine. These early Portals provided a predetermined set of information sources to the end user. (The idea was that users could quickly search for information if they knew what they were looking for, or they could “browse” for information if they only knew the topic they were looking for.) As Portal technology began to advance, they included the ability to allow the end user to select which information sources that they want displayed in their “own” Portal. At this point, Portal vendors began stressing this capability by labeling their Portal as “MyPortal”. Soon afterwards, Portal software vendors began producing applications that allowed similar types of Portals to be run inside of an organization. The next phase of Portal development began when Portal vendors included extra functionality in their products to try and distinguish themselves from their competition. Pieces of functionality that were incorporated into their products included; search, reporting, business intelligence, charting, etc. Portal vendors also realized that Portal users need access to more than just information repositories; they also need to access the applications to put this information to use. As such, Portal products began to integrate with applications as well as information sources. It was at this point where the term Enterprise Portals began to appear since the products were allowing large organizations to efficiently access information and act on it. The most recent evolution of Portals has brought Portal technology to a state where they are now vital tools that can be utilized by an organization to increase its competitiveness. Portal product vendors have increased their product’s ability to integrate with more applications and information sources, and the functionality enhancements are now focusing on allowing Portal users to easily

6

Portal Building

collaborate with one another. Due to the ever increasing amounts of integration work required to access the variety of information sources and applications, Portal products began to evolve from being considered as an application to being considered as a piece of infrastructure. To summarize this Portal evolution, I have broken the Portal product lifespan into a series of phases as outlined below; Phase #1 Phase #2 Phase #3 Phase #4

Portal products only provide information to the user. Portal products allow user to select the information sources to be viewed in their Portal. Portal products allow the user to act on the information supplied in the Portal by providing access to applications. Portal products provide the user the ability to collaborate with other Portal users to create/share/validate information.

As the Portal products continue to evolve and change, their focus always remained centered on providing the user with access to information and to allow them to act on it. Current Enterprise Portal products contain a great deal of functionality, most of which is not core to the Portal product itself. This functionality is promoted by the Portal vendors as the main way for them to differentiate themselves from their competition. But in fact an Enterprise Portal, when stripped away from all of its “extra” functionality can be considered as having only two main types of functionality; Integration and Presentation. The integration functionality of the Enterprise Portal has its main purpose of allowing it to easily and securely access information from a variety of different information repositories. It also provides mechanisms to allow applications to be brought into the Portal so that users can access the application’s functionality without leaving the Portal.

Enterprise Portals Defined

7

The other main functionality in an Enterprise Portal is concerned with displaying the information and application functionality to the end user. The way this is accomplished is by utilizing small Portal programs to create mini windows on the screen, each one opening onto a separate piece of information or functionality. One way to picture this is to think of a desktop computer’s screen covered by a number of open web browsers, each one opening a different webpage. These small Portal programs are called by a variety of different names such as gadgets and iviews, but their most popular name is portlets. (I will use the term portlet throughout the rest of this book.) The remainder of this chapter will focus on the remaining components that can be associated with a Portal product. The pieces of functionality have been grouped into two categories for easier identification, and a brief description is provided for each one. I have called the categories Core Portal functionality and Additional Portal functionality. The functionality described in the Core Portal grouping are present in all Portal offerings, however the functionality in the additional Portal grouping are present in some Portal products; depending on the Portal vendor. These additional pieces of functionality are what Portal vendors use to differentiate their products. The inclusion of the additional functionality is also what is used to create specialized Portal products. Core Portal Functionality All Portal products include at least two pieces of functionality; Presentation, and Integration. The third piece of functionality, Security is becoming common place in most Portal products and can be considered as core functionality. Without the combination of these pieces of functionality a Portal vendor’s product cannot perform the core duties of a Portal. Application Aggregation One of the key ways in which a Portal product differentiates itself from just any computer-based application is its ability to display content / applications from a variety of different sources on the same “web page”. This is done by providing the Portal product with the

8

Portal Building

ability to serve up a number of small mini Portal applications (portlets) on a single page. Each one of these portlets can be configured to access a specific (or multiple) data source or application. By assembling a number of these portlets, the Portal application creates each Portal page. Each Portal vendor has their own way of implementing portlets. Due to the lack of maturity in the Enterprise Portal market, there is currently no standard way of implementing portlets. Presentation Not only do Enterprise Portals provide the capability to present “views” into multiple data sources and applications via portlets, but they also provide a mechanism to personalize the Portal “pages” for each of its users. This is most often referred to as creating a rolebased Enterprise Portal. (Having a Portal create unique Portal pages that provide the information sources and applications that are required for an individual’s role within an organization.) For instance, the Portal pages that a human resources employee sees in their Portal would be different from that displayed for a member of the marketing department. These unique Portal pages are most often created using four techniques, personalization techniques, customization techniques, heuristics, or some combination of the three. Most Portals provide the first two types of personalization, with the third type, heuristics, being relatively new to Portals and only a limited number of Portal vendors providing it. (Not providing this type of personalization should not be seen as a deficiency of a Portal product as not all organizations will require this type of personalization capability in their Portal.) The terms personalization and customization are usually used interchangeably but there is a difference between the two, and they serve two separate functions. These two types of personalization will be described first. Personalization refers to the ability of the Portal to store pieces of information (or access from a separate repository) about a user and

Enterprise Portals Defined

9

then use that information to build Portal pages specifically tailored to them. For instance, the Portal can store information about a user that denotes that they are a manager working in the finance department. When that user logs into the Portal, the Portal will display portlets that have been determined to be of interest to managers and someone from within the finance department. Portal customization refers to the ability of a Portal product to allow the end user to modify their Portal pages themselves. This could involve selecting the portlets that they would like to see on their pages and even modifying the layout of how the portlets are presented on the page. For instance the finance manger described above may feel that a portlet linked to manager’s reporting tool is more important to him/her than a portlet linked to a Finance news application. Portal customization would allow the user to place the reporting tool portlet at the top of the page and have the Finance news portlet near the bottom of the page. Using heuristic techniques for Portal personalization is relatively new to Enterprise Portal products but has been popular on large retail web-sites for some time. Heuristics is concerned with tracking a user’s behavior on a particular site and then by comparing the behavior to other users, it tries to infer what the user would like to see next. The most common application of heuristics personalization can be found on the Amazon.com website. This website tracks what products its users purchase and when a user is considering purchasing a product the system is able to inform the user that the other people who purchased this product also purchased these other products. The requirement for this type of personalization is not as common as the other two types but as Enterprise Portals become extended towards an organization’s customers and suppliers, as well as employees, it will begin to become more important. These personalization techniques can also be used in conjunction to create what appears to be a number of different Portals all from a single Portal. Some Portal products have the ability to change the look & feel of a Portal depending on certain personalization values. This would allow the Sales department to create a Portal that looks different from the IT department’s Portal. This is referred to as the

10

Portal Building

ability to created Virtual Portals and can save an organization money by not having to purchase and install a number of different Portal products, but by leveraging one single Portal install. Many Portal vendors tend to stress their products’ personalization capabilities to customers by stating that it will help the Portal product increase its ROI by providing faster access to information, a more comfortable workspace and tighter security. However care must be taken to not place too much attention on customization. In fact, most Portal users state that once they set up their Portal pages to their liking, they do not use the customization functionality very often. (Also, if the organization is able to take full advantage of the Portal’s personalization functionality, there should be very little need for a user to fine tune the Portal using the customization functionality.) Security Like most other computer based products, Portal products have some degree of security embedded in them. The majority of Portal products handle security at two levels, the user level and the group level. Most Portal products only provide limited security features and rely on additional products for their complete security and user management functionality. Care must be taken to ensure that all of the features that are being described by the Portal vendor are included in the Portal product and do not require purchasing additional components. The user level security handles the access controls that each individual user has when accessing the Portal. Since handling security at the user level can quickly become an administration nightmare, (for instance when the population of Portal users gets over fifty), group security has been included in most Portals. Group security allows for users with similar security privileges to be grouped together to lessen the administration burden. By applying security to the group, all users within the group would receive the same security access. (Note: some Portal products rely on group security privileges for their Portal products personalization functionality. While this is acceptable in small scale Portals, it can potentially become an administration problem in Portals with a larger number of users.)

Enterprise Portals Defined

11

Portal vendors are trying to reduce the administration burden of Portal users and allow their Portal applications to use the organization’s existing user directory. This way as users are added to the firm’s directory in order to access their network, for email for instance, they can also be automatically added to the Portal application. (The administration of the Portal users becomes incorporated into the directory’s administration processes.) Additional Portal Functionality In addition to the core Portal functionality, Portal vendors are adding more functionality in order to differentiate their products. These Portal vendors are continually adding new functionality in order to include specialized functionality that would appeal to more organizations. Security & User Management The most popular and most advertised access feature in Portals deals with single sign-on. This functionality allows the user to log in once to the Portal and not have to log into any other applications. The Portal, or separate security component, then handles the authentication (login) to the other backend applications. This single sign-on functionality is usually part of a security component of the Portal that is in most cases separate from the actual Portal. The actual technical implementation of the single sign-on functionality can be accomplished a number of different ways. (As I am attempting to keep this book business oriented, I will not discuss the technical implementations of single sign-on here.) What the business person should know is that the single sign-on functionality of the Portal product that you chose should have more than one method of implementing single sign-on. This is needed since it is difficult to predict how the individual backend applications handle user authentication. One detail that is most often overlooked in the single sign-on discussion is the business risk associated with having only one user id and password to access all of an organization’s applications. With single sign-on implemented, an outsider only needs to compromise one id and password and they would have access to a number of

12

Portal Building

different applications. Because of this, the Portal team may need to get business owners, application owners, and corporate security personnel to sign off on applications to include in single sign-on functionality. What is becoming more popular is to have a mix of user authentication mechanisms; some applications with single signon and some without. Having an Enterprise Portal handle security, and by having the Portal serve as the single access point to an organization’s applications, allows for the Portal security component to include what is called Security Policy Management. In effect, this functionality allows for “security rules” to be created and managed from a single location that controls access to all of an organization’s applications. This is rather difficult to achieve, since all applications must use this centralized security functionality. This means that all legacy applications may need to be modified in order to utilize this central repository of policies. What most Portal teams do is that they implement centralized security functionality for all new applications. For existing applications a cost benefit analysis is done to determine if modifying the application is justified. Having a centralized security component for an Enterprise Portal also allows for having the added benefit of centralized user identity functionality. User identity allows for the central administration of user authentication and user authorization. Some people use these terms interchangeably but they mean very different things. User authentication deals with confirming the identity of the individual user. Authorization deals with determining which users get to access which applications. User identity allows for a centralized place to securely store all of the information related to each user. It provides a centralized place in which to ensure that these data values are kept up-to-date and that the process to ensure data accuracy is functioning properly. The storage of this user information is usually conducted in a separate database, called an LDAP. LDAP stands for lightweight directory access protocol and is a set of standards for directories to follow. If a directory is LDAP compliant it is said to follow the LDAP standards. Most organizations already collect information

Enterprise Portals Defined

13

about their employees and have this stored in an existing database. For this reason most Enterprise Portal products can be connected to existing directories. Make sure that if your organization has an existing user directory, (and you are planning on using it for your Enterprise Portal), the Portal product you select can support it. The final security feature that will be described here is referred to as a Reverse Proxy. The Reverse Proxy acts as a gate keeper, keeping the location of all applications and content sources hidden from the user. To explain this concept an analogy of a doorman / bouncer located at the entrance of a club works well. It is the doorman’s responsibility to protect the contents of the club from outsiders’ attention. For instance, someone from the outside might want to collect a piece of information (a package) from the inside of the club. The doorman’s job is to keep the person outside of the club and to go and get the package for the person and bring it out to them. This way, the person does not get to see what is inside the club, or even from where in the club that the package came from. Taking this explanation back to a Portal description; the Reverse Proxy keeps the Portal users outside of the organizations internal network, in what is called a De-militarized Zone (DMZ), and hides the location of the applications and content repositories from them. By hiding the location, it makes it more difficult for would-be hackers to break into your organization’s back-end systems. This allows the Portal infrastructure to be placed in the security of an organization’s network, and having just the Reverse Proxy functionality located outside of the organization’s network. Depending on how the security features of the Portal are handled, this feature may not be available in every Portal product. Content Management One of the key differences between an Enterprise Portal and a typical website is that website’s store their content internally while true Portals don’t store any content at all. Portals rely on other content management systems to control their content. However, not all organizations have processes in place to ensure that their content is accurate and up to date. In these organizations, the implementation of an Enterprise Portal will highlight this deficiency very quickly. If processes are not put into place quickly (hopefully before the Portal

14

Portal Building

is put into production), Portal usage may diminish since content is very visible and needs to be relevant to Portal users. The creation of content management processes cannot be fully covered in this book; it would require at least a separate book on its own. I will try to touch on some of the high level issues that should be incorporated into a content management system that will be utilized by an Enterprise Portal. The most important aspect of a content management system is to ensure that the content remains up to date and relevant. Most people use popular office suites to create most of their content (Microsoft Office, Corel WordPerfect Suite, etc), therefore content management systems should be tightly integrated with these systems. Storing this content should be done in organized repositories, not just on file shares, and especially not on individual hard drives. The main reason for this is to allow for the inclusion of meta-data (or data that describes data). This meta-data can allow for descriptive terms to be included with the document to allow for easier categorization and searching. Centralized storage is also preferred since it allows for regular backups and it also allows for the content to be shared among other users and applications. In order to ensure that the content that is displayed on the Portal is appropriate, relevant, and current, the processes behind this are usually automated. The creation of this automation is usually referred to as workflow. Workflow is included in content management systems, or available separately in some systems, and should be utilized. The difficulty in fully utilizing workflow is that it either requires new processes to be created or existing process to be modified, which can be a very time consuming process. If the processes and workflow are not created properly in the first place, it could result in content being improperly displayed or even not being displayed at all. This could also have very serious ramifications to your organization if the wrong content was displayed to an employee, or even worse, a client. This is usually prevented by putting approvals into the workflow processes to act as checks before the content is published.

Enterprise Portals Defined

15

Collaboration Tools Although collaboration tools are not part of the core Portal functionality, most Portal vendors are including these pieces of functionality as part of their Portal products. As more Portal vendors include these pieces of functionality in their products they may start to be referred to as part of the core Portal functionality. Collaboration tools can be classified into 2 categories; asynchronous and synchronous. Asynchronous collaboration techniques are not considered real-time communication. Examples of these collaboration techniques include email, discussion databases, and even regular mail. Synchronous collaboration techniques are considered as real-time collaboration. Examples of these collaboration techniques include Instant Messaging, On-line Awareness, and Virtual Meeting Rooms. The most popular form of on-line collaboration currently is instant messaging. This functionality allows for two or more individuals to conduct a text based conversation in real time. Some product vendors can even include the functionality to translate the text messages in real-time. This allows one person to type in English and have it displayed in French to the other person. Instant messaging began in the public domain with vendors like Yahoo, AOL, Microsoft, but recently these vendors, and others are concentrating on developing this functionality for business users. Organizations should primarily focus their investigations on the vendors who specialize in the corporate instant messaging environment due to security and performance issues. Another collaboration feature that is closely associated with Instant Messaging is called Online Awareness. Online Awareness provides the ability to show who is currently logged onto the Portal. By combining this functionality with Instant Messaging, it allows one to determine who has logged onto the Portal and currently is available for an instant message chat. While most Instant Messaging applications provide this functionality within their own application, its real power becomes more relevant when the online awareness can be extended into other applications, like email, ERP, etc. Part of this

16

Portal Building

functionality also provides the ability for a user to select their own online status; online, busy, away do not disturb, etc. This provides a mechanism to prevent a person from being bombarded with messages when they are focused on other things. Some of the more advanced Online Awareness products can even tell if a person is logged on via a wireless device. When looking for an instant messaging product, it is highly advisable to ensure that it includes online awareness and that this awareness can be incorporated into other products, especially those not from the instant messaging vendor. Virtual meeting functionality is becoming more and more common in global companies. The main benefit for implementing virtual meetings is that it can reduce travel expense and the lost time associated with traveling. Virtual meeting products provide a mechanism that allows for meetings to be conducted over the Internet. They allow for a number of people to log in to a secured site and to view files like a presentation, spreadsheet, or document. Some applications even provide white boarding capability, which allows for meeting participants to “mark up” documents as if they were writing on a real whiteboard. Another feature of some products allow for one user to actually take control of the meeting organizer’s computer. This is most appropriate for training seminars and help desk situations. Most of these products also include some audio and video functionality as well. This allows all meeting participants to hear and see the meeting presenter through the application. As most organizations usually use the phone for the audio portions of the conferences, (as it is usually cheaper and frees up bandwidth), you must decide if these features are of benefit to your organization. Other features that could be included with these types of products include; polling, asking questions, chating, and recording the meeting. Like always, before making a decision, make sure that the product you agree to pay for includes only the functionality that you feel can benefit the organization. Team rooms are secure web-enabled places that allow its users to collaborate and share documents. These places are usually created to focus around a specific project, and can vary with functionality depending on vendors. Some vendors of team room products have

Enterprise Portals Defined

17

placed so much functionality into their products that they have started to resemble mini-Portals. Care must be taken, if your organization implements this functionality to not to confuse the user; “do I use the Portal or do I use the team room.” The greatest benefits of team rooms are that they are temporary in nature and can be created by the end user (no IT help is required), and that they can be set up so that the user can be from within their organization or from outside it. One example can be that a salesperson can create a team room to work on a proposal with one of his clients. Some of the more advanced team room products have project management functionality, calendaring, and even email to notify its members of upcoming tasks, milestones, or content updates. Having the team room product integrate with your organization’s email and calendar software is also advisable. Search One of the main reasons that most people implement a Portal is that they expect it to help them find information quicker. However, since the Portal does not actually store any content, it should not need a search engine, but most Portal vendors include a search engine in their product in order search an organization’s content. There are basically two types of search engines that are included with Portals; spiders and aggregated search engines. The first type runs an automated program, called a spider, which goes out to all of your organization’s data sources, analyzes the content and creates an index of all of the content with pointers back to the original document. When a search is conducted, the search engine actually only searches the index and displays the results with the pointers back to the original document. The advantage of this type of search is that it is very fast, especially when there are a large number of content sources. The disadvantages are that the search index requires its own database and can take up a lot of disk space, depending on the number of documents on your organization, and that the search index is only as accurate the last time it was created, so if the spiders are set to run nightly, any content that was created during the day would not be searchable until the next day.

18

Portal Building

The second type of search engine does not require its own search index but relies on the search capabilities of the individual content repositories. When a search is conducted, the search engine sends out a search request to the search engines that are part of each content repository and instructs them to conduct their own searches. It then retrieves all of the search results and combines them into a single result set that is displayed to the user. The advantages of this type of search are that it does not require space for its index, and that it provides more accurate and up-to-date search results. The disadvantages are that it is slower than the index search and that it requires more configuration time to set up, especially if the content repository does not have its own native search engine. One of the most difficult choices when implementing an organization wide search engine has to do with document access. One school of thought is that if a person does not have access to see a document, the document should not show up in the search result list. However from a knowledge management perspective, this might not be the best situation. Knowledge management would want the person to at least see the title of the document in the search results list so at least they would know that the document exists, even though they can not access it. Bringing a document repository into the search engine requires some technical effort. The exact amount of effort required is dependent on the search product chosen. Since most Portal teams have limited resources, some prioritization of which document repositories to be included in the search engine and when are important decisions. This decision should be influenced by the vision of the Portal and the priorities of the initial Portal releases. The prioritization of the data repositories should also help ensure that the initial Portal metrics, and ROI are achieved. Taxonomy Another way to find information within an organization is by browsing a taxonomy. A taxonomy is a classification schema that is applied to an organization’s content. The dewy decimal system used by your local library is one example of a taxonomy. But where the dewy decimal system uses numbers to classify content, most

Enterprise Portals Defined

19

business taxonomies use descriptive words. Taxonomies are useful when you do not know exactly what you are looking for, or are looking for information that may be related to a topic. In large organizations, each department may have a different method of classifying their content. For this reason, most organizations require a taxonomy solution that can handle a number of different taxonomies each applied to the same content base. Trying to create a single taxonomy that can be applied across an entire organization can be a daunting task. Creating a corporate taxonomy is a very process intensive operation. It involves much research and trial and error testing even for the most experienced at creating them. For this reason, a number of taxonomy products include functionality that will attempt to build the initial taxonomy for you. Care must be taken to ensure that this taxonomy is actually relevant for your organization, usually by testing and modifying the taxonomy a number of times. Also, ensuring that the taxonomy stays relevant to the organization can involve a great deal of resources and process creation. A business must carefully analyze the benefits of implementing a corporate taxonomy before they decide to include this functionality into their Portal project. While a corporate taxonomy will provide a great deal of benefits to an organization Portal, it is usually a project that should be handled separately due to its size and complexity. Feedback Enterprise Portals can be considered as continually evolving entities. They should always be changing to suit the needs and requirements of its users. For this to happen effectively, the Portal needs to provide for a mechanism to capture suggestions and comments from its users. Most Portal products do not include this type of functionality. This functionality is usually created by the organizations themselves and can be as complex or as simple as required. It is important to ensure that this feedback mechanism is able to route the user suggestions / comments to the appropriate Portal team members in a timely fashion.

20

Portal Building

Another way of ensuring that the Portal remains relevant to its user community is to track a number of usage statistics. By finding out which parts of the Portal are used the most / least can indicate areas of future enhancement. Also, if an organization has an existing intranet, before the Enterprise Portal is implemented, it is recommended that intranet usage be tracked and then compared to Portal usage. The specific pieces of information that should be tracked by the Portal team should be selected so that they help defend the Portal benefits that were mentioned in the business case recommending the Portal. These statistics can also help to create and track the ROI of the Enterprise Portal. There are a number of points to be aware of when it comes to looking at Portal products and their functionality. Firstly, each of these additional functionality pieces should not be tied too closely to the actual Portal product. This is desired so that you can decide on what pieces of functionality are most appropriate for you at this point in time. (More information on this subject is found in a later section of this book.) It also provides you with the freedom to swap out the pieces of functionality for a better one from another vendor. This ensures that your Portal will always remain current and state of the art. It also allows you to deploy the Portal that will best meet your organization’s requirements and resource needs. By having the Portal’s functionality in components, you can implement the pieces of the functionality as dictated by your resource constraints. By providing you with this list, my main goal is to inform you of what some of the possible Portal functionality is out there so that you can make a better decision of what Portal product closely maps to your organization’s requirements.

2 Why Implement a Portal? When your organization is considering implementing an Enterprise Portal, the first question the organization should be able to answer is, “Why do we need to implement a Portal in our organization?” The answer to this question tells a great deal if the Portal implementation will be successful or not. If the person answering the question needs to think about the answer, or gives an answer that sounds like he read it from a vendor’s marketing brochure, or, heaven forbid, the answer is “Our competition is building one so we need one too,” chances are the Portal project will not be a success. But if the person can discuss how their organization will benefit from a Portal implementation, then the implementation has a better chance of succeeding, because this person has done their homework and realizes that implementing a Portal requires focusing the effort on achieving solid and tangible benefits for the organization. There have been many whitepapers and reports written on the benefits of implementing an Enterprise Portal and this book does not intend to duplicate that information here. This section on Portal benefits has been included merely as a means to refresh the reader on some of the high-level benefits of a Portal. What does need to be stressed to the reader is that no one can tell you how a Portal can benefit your organization without first knowing what your pain points and challenges are. Therefore, the best person to really understand what benefits an Enterprise Portal can bring to your organization is someone from within the organization. So by understanding what a Portal can do for you, (as mentioned in the previous chapter), this chapter will give you some direction on how to determine your own potential Portal benefits. An Enterprise Portal can provide the framework that allows the firm to achieve many benefits. However the Portal itself can provide very

21

22

Portal Building

little direct benefits to the firm. One of the first questions that is usually asked is, “How do I calculate an ROI for our Enterprise Portal?” The simple answer to this question is; you don’t. An Enterprise Portal by itself will not provide you with an ROI, however, it will make possible a number of other initiatives that do have a calculate-able ROI, such as implementing employee selfservice, reducing printing costs for employee manuals, and providing the framework for implementing an e-learning initiative. Now, does this mean that the examples that have just been mentioned cannot provide value to an organization without a Portal? Absolutely not. Each of these initiatives can be successfully implemented on their own and without an Enterprise Portal. However, with a Portal, these initiatives, can be brought on quicker, with less resources, and will have a better chance of being successful if brought through a Portal, as well as benefiting from the Portal’s ability to provide context, which will be discussed later. This is where the difficulty arises in trying to assign a percentage of an initiative’s ROI or benefit to a Portal. For this reason, most organizations tend to focus on qualitative benefits of a Portal and downplay the quantitative benefits. This relying on the “softer benefits” or the qualitative benefits does not always sit well with the executives of some organizations. For this reason, I consider that there are two main reasons / justifications for implementing an Enterprise Portal. The first one is that it is an evolution of the organization’s existing intranets or employee self service initiatives. For these implementations, the existing initiatives have achieved some benefit to the organization, and the implementation of a Portal will either continue those benefits, or increase them. The second reason for implementing a Portal is what I am calling the “leap of faith” initiative. This occurs when the organization’s executives stand up and say that the organization will see benefits from a Portal once it is properly implemented, and therefore will not expect to see hard figures justifying the need for a Portal in the early stages of the project. Although a good number of Portal implementations have started out under the “leap of faith” category, once implemented, the executives will want to start seeing hard numbers on what it is contributing to the organization.

Why Implement a Portal?

23

So what are some of these “soft benefits” that can result from implementing a Portal? Since each organization experiences their own challenges and growing pains in different manners, it will be very difficult to define all of the qualitative benefits that your firm can possibly achieve from implementing an Enterprise Portal. I will describe some of the high level benefits that most organizations have achieved after implementing an Enterprise Portal. The first “soft benefit” that usually is mentioned, is that Enterprise Portals can make your employees more efficient. (I have problems with the wording of this example since it can imply that your employees are not already very efficient.) What this benefit is trying to illustrate is that the personalization capabilities of an Enterprise Portal can be used to filter information and applications so that employees can see a reduction in the time spent looking for information; as it can be pushed to them automatically. Also, by acting as the single access point to information and applications, if an employee does need to look for something, they should be able to find it faster since there is only one place to look. And when a federated search engine and enterprise taxonomy are included with the Portal, the time spent searching for information can be reduced even further. Another benefit is that it provides a single authoritative source of information. Currently most organizations are faced with the problem that similar information can be found in a number of different places, and depending on the currency of the information, each instance of the information can be slightly different. By using the Portal as the single authoritative source for information, users can feel confident that the information on the Portal is accurate and timely. Also, since the Portal is the source for information to an organization, it can also be used to broadcast messages and notifications. By using the personalization capabilities of the Portal these messages can be targeted to specific user groups so that users will not receive messages that do not directly affect them. For this matter, users tend to pay close attention to their messages after being filtered via the Portal. This leads to better informed employees, who are more knowledgeable about what is going on in the organization.

24

Portal Building

Another benefit results from the Portal acting as the single access point for all of the organization’s content and functionality. By carefully determining where the individual pieces of content and functionality will be located on the Portal (sometimes referred to as the “Information Architecture” of the Portal), the Portal can provide additional context to the content that it would not have had if it was located in an isolated location. For instance, an organization may have a subscription to an external provider for news headlines. By incorporating this same functionality into a Portal, the Portal can be used so that news about a specific client / partner / customer can be accessed and combined with additional information about the company from within the organization to form a single “company viewpoint”. (Some vendors have used the term “dashboard” to represent this “pulling of information together into a single place”.) Another benefit, and something that you actually can get an ROI from, is that the Portal acts as a focal point for other initiatives. In the past, most Portals have been brought into an organization as a way for their human resources department to implement employee self service; (on-line access to HR data), or as strictly an IT initiative. Knowledge management teams also see a Portal as a way to help them get their message across. Since the Portal creates a single point where everyone in the organization goes, it creates a captive audience for knowledge management techniques to be brought into an organization. However, after a Portal is implemented, and others within the organization begin to see its benefits, it can serve to assist in providing benefits to other areas of the organization. These different initiatives do have a measurable ROI attached to them. Even though some of these initiatives can be implemented without a Portal, they would be much more expensive and would take longer to implement, meaning that they would become more expensive to develop. So, once implemented, an Enterprise Portal provides a framework that allows other initiatives to achieve higher ROI or to achieve their ROI much faster. Some of the benefits of properly implementing an Enterprise Portal are concerned with how the organization deals with its employees, clients, partners, suppliers, etc. This can be assisted with a Portal by examining the way that information and functionality are laid out on

Why Implement a Portal?

25

the Portal itself. This has been termed “Information Architecture” and can simply be defined as how information and content are grouped and displayed. Successful Portals use their information architecture to influence the organization to become more client, or employee centric. In the past, web-initiatives have been described as B2E (business to employee), B2C (business to client), and B2B (business to business). These labels describe initiatives that focus on how the business or the organization interacts with others, with the emphasis on the business or organization. To illustrate this point, take a look at most company web-sites or intranets. They are usually laid out from an organization perspective, and most times follow the organization chart of the company. Information is categorized by the different departments of the organization. If someone is looking for a specific piece of information, they would first need to know what department owns that content, go to that department’s section on the website, and then search for the specific piece of information. However, what I am advocating is that successful Portals can help achieve an ability to switch this thinking around and place the emphasis on the individual user and not the organization. By utilizing the personalization functionality of an Enterprise Portal, users can be presented with information that they specifically need. Users coming into a Portal are there to do specific tasks, they are not there to merely browse information and learn more about the organization in general. For this reason, the information and applications that they need should be laid out in a manner that is more suited for what they are trying to accomplish. As I have mentioned previously, implementing a Portal deals to a great extent about change management and changing an organization’s processes. (Without these changes in process, a Portal implementation becomes a very expensive web-site development project.) Because of this, once a department starts to analyze their content and functionality from an end user’s perspective, it can start a “snowball” effect on their other process which can begin to become more client focused. This in effect allows one to start thinking of their initiatives as E2B, or C2B. (Emphasis on the employee or the client, and no longer on the business.)

26

Portal Building

This “client focused” way of viewing information and content also leads to the breaking down of the internal “silos” of information and processes commonly found in organizations today. Users of Portals are focused on completing tasks, which commonly require information or processes from a number of different departments throughout an organization. For instance, an employee may have just gotten married and has changed their last name. Changing their last name, to an individual, may seem like a simple task, but they may need to contact a number of different departments throughout the organization to get this new name created in all of the various information stores. Human Resources needs to be notified to change their systems, IT needs to be notified to change the person’s email, Finance needs to be notified to change their payroll system, etc. This is even prevalent from a client perspective as well. A client may be looking at a professional solutions company to help solve its business problem. To the client its one business problem, but to the organization, they may need to bring together experts from a number of its different practice areas. This should be invisible to the client; they should not have to deal with their problem on separate matters depending on how the organization is laid out. In fact, by allowing for information to be presented to a Portal user from across the various departments of an organization, the users become more efficient, and it allows the organization to be seen as more client focused. Enterprise Portals, in effect, can hide the organization structure from it users. Not only can Portals hide the organization structure from its users, but you can also take this line of thinking down another level to the applications themselves. Earlier in this book, I explained that Portals are merely the access point to the applications of an organization. This in effect creates an interface layer at the Portal level which can hide the actual applications below. This allows functionality to be displayed to the users without them knowing which particular application they are using. This has a number of benefits to the organization. For one, an organization can change a particular backend application, and as long as it provides the same functionality, the user may never know (or care) that the application has changed because the interface at the Portal level stays the same. This can reduce training costs for upgrading applications, and allows

Why Implement a Portal?

27

the IT department to better serve its clients by providing applications that are better suited to the organization’s business needs. Another benefit of this capability is that it allows for the creation of “new” functionality that was not possible before. For example, in a legal services firm each area of specialization may keep their own client engagement lists. For an individual to know the types of work being done by the entire firm they may need to access a number of different applications, if they know of all of them, and repeat their search in each one of them. What a Portal can do is create an interface that allows the user to act on a specific request, “Display all clients with firm engagements”. The Portal can then go to each of these separate applications, pull out the information and present it in a single result set. From an individual’s perspective, they don’t need to know where the information came from, or from how many different places. In the past having these different applications combined would have taken a great deal of resources, and people processes to convince the departments to give up control of the information for the “better good” of the organization. While these issues still remain, they are reduced somewhat since the Portal allows the individual departments to maintain ownership and control of the information, yet still allow users to access it from a single point. This leads to the point that an Enterprise Portal allows the various applications found throughout an organization to be integrated together into a single access point. (Don’t get me wrong, this is not easy to do, but once accomplished, this provides a great deal of qualitative and quantitative benefits to the firm.) From a user’s perspective it would be best if a firm had only one giant application in the back end that did everything for the organization. This would allow users to work with data no matter where in the organization that data was created or what its original use was. Now we all know that this is not the case and that organizations contain applications and information storage comprised of a number of different products from a number of different vendors. In order to integrate all of the functionality and information from across these applications, organizations have relied on the users to become the integration layer. Users would need to access an application, retrieve a piece of information, then access another application and bring in the

28

Portal Building

information just retrieved and apply it to this application’s functionality, etc, etc. What a Portal allows an organization to do is to take the integration onus away from the users, and bring it into the Portal. The Portal in effect creates the illusion that the organization has only a single application in the background. This allows information to be accessed quickly and applied to a number of different functionalities depending on what is needed at that particular time. It should be made very clear that these benefits that I have described in this chapter will not be realized from the moment that your organization implements a Portal. The implementation of a Portal follows an iterative development process. This means that Portals usually start out with a small subset of functionality that is continually added to and expanded upon over time. The result is that the benefits from a Portal will also follow an iterative nature. The benefits will be small / specific at first, but as the Portal grows, so will its benefits. With this in mind, it is important that the Portal team carefully selects the functionality and content for the first few Portal releases to ensure that they provide the right benefits to the organization. This will help ensure the continued support for the project. If not, the organization may remove their support for the project due to a lack of clear and immediate benefits. Each organization is different with respect to the amount of benefits and the timelines to achieve them, but this does need to be considered when planning the initial stages of a Portal deployment. In conclusion, I hope this chapter has illustrated some of the benefits that can be achieved by implementing an Enterprise Portal. However, I would like to take this time (and space) to mention that the goal of an Enterprise Portal project is usually not to implement the technology component of it, but to achieve the project’s benefits. With this in mind, the benefits of the project should be clearly stated from the beginning and should remain the focus of the entire project. Who knows, it may even be possible to achieve the benefits without implementing an Enterprise Portal application, (but don’t hold your breath on that one).

3 Portal Vendors & Their Solutions Enterprise Portals are software solutions that provide a framework to solve complex business problems. The complexity of these solutions does not revolve around the software solutions themselves, but around the business processes and cultural changes required for a successful Enterprise Portal implementation. For this reason, Portal vendors have many different tactics to convince organizations of their need for a Portal, and more specifically, a need for their Portal solution. The first of these tactics involves how Portal vendors define what an Enterprise Portal is. Each vendor tries to distinguish their products and themselves from others in the industry. One of the ways they accomplish this is to define Portals and the Portal marketplace in a way that positively reflects their product. The negative impact of each Portal vendor having their own definition of a Portal is that it confuses their potential customers. Also, this makes it very difficult for customers to compare Portal products and vendors to each other. What is needed is a standardized definition of what makes up a Portal, (see the first chapter in this book for my contribution to this issue). Because of this lack of industry standardization, most of the due diligence falls on the customers to ensure that they do their research in order to ensure they select the most appropriate Portal product for their organization. What organizations need to do is to ensure that they are well aware of the business requirements needed for their Portal. From these business requirements the organization can select the Portal product and vendor that contains the functionality that best matches the needs, and expected future needs, of their organization. When implementing Portal solutions into large organizations, most of the benefit from a Portal comes from the integration of the various

29

30

Portal Building

backend applications into the Portal. For this reason, no two Portal installations will be exactly alike. The Portal solution vendor should have a strong service and support organization to provide their customers with support and assistance when bringing unique applications into the Portal. Portal vendors have their own methodologies when it comes to selling their Portal software. Some vendors focus on helping the customer calculate ROI for the Portal product, expecting this to help the organization secure the executive support and funding needed to begin the project. However, as I mentioned in the previous chapter, it is very difficult to calculate ROI on a Portal project, most ROI is calculated on the projects that will use the Portal as a delivery mechanism. For this reason, selling a Portal strictly on ROI is very misleading. Other vendors sell their Portal products by pushing increased self-service, increased collaboration, increased customer focus, increased employee productivity, etc. Again, these are all separate initiatives that can be helped by being implemented through a Portal. These initiative do not need a Portal to be successful, however a Portal allows them to be implemented sooner and with less costs. Portal vendors should switch tactics and start selling their Portal products by helping their customers choose the right Portal product for them, even if it is not theirs. They may lose the sale but they will increase their chances of gaining more future business by becoming more familiar with the customer’s business problems, and the customer may begin to think of the vendor as a valuable business resource. The Portal vendor can start by ensuring that the customer is aware of the difficulties of implementing a Portal solution and provide them some solutions to help the customer avoid some of the pitfalls. As I am writing this book, not many Enterprise Portal solutions have been fully implemented throughout large organizations, so this may be difficult for some Portal vendors. The Portal vendor can create templates and methodologies that help customers define their business requirements to ensure that they choose the right product. (This also can provide Portal vendors with valuable information on what their customers really need in their

Portal Vendors & Their Solutions

31

Portal solutions which can be fed back to the product development team.) Most Portal vendors have their own consulting practices that are targeted to implementing their products. These consultants follow a methodology that has been developed either from their experiences implementing their products or by following industry best practices. The first question that an organization should answer is if they need any external help at all. If they are a large enough organization, they may be able to handle the Portal implementation themselves. If they do need external help, they need to determine to what degree this external help should consist of. I have always advocated that due to the extensive business and change management processes that need to be addressed with implementing a Portal, the organization itself should take the lead on the project and only have external resources provide assistance with the technical aspects of the software implementation. If help is needed on the business side of the project, it may be beneficial for the organization to look for consulting companies that are not software or technology based, but are focused on business and process changes. We’ve talked about Portal vendor “experts” and we’ve also talked about consultants. The other group we should talk about is industry research specialists. These people spend the majority of their time studying the market and the players in it. They then use this information to predict where they think the market will go in the future. They also collect information on what companies are doing with respect to the industry they are studying. These groups of experts should be used for collecting information on the Portal market in general. They can provide information on where they think the market will be going in the near future, and they can also provide some information on what other companies (preferably in the same market space as you) are doing with Portals. They should not be used to provide recommendations on what Portal vendor your organization should select or what consultant company you should use to provide implementation assistance. They can be used to provide validation on the methodology you use to select your Portal vendor. They can also be used to act as a sounding board after you have made your decision to select a Portal vendor. This information

32

Portal Building

can be useful for selling the Portal to the executives of your organization. One thing to look out for though, is that some of the industry research companies can be linked to specific Portal vendors. Some representatives of these research companies will even present at conferences sponsored by Portal vendors. Care must be taken when you are listening to their expertise as they have their own agenda to follow, whether it’s to get you to sign up for a membership, or to sell their services. Care must especially be taken when listening to them if they are presenting at a vendor sponsored conference, as they may not be completely un-biased during their discussions. There are two ways that an organization can and should use consultants, or vendor experts. The first method is to help the organization research the Portal market. The consultants can be used to explain what their product does (what are its capabilities) and also what their take on the Portal market is, (especially where they see the market, and their product going in the future). This is part of the consultant’s role and this information is usually given free of charge. In fact, care must be taken to ensure that the members of the organization realize that the information collected in this phase will be biased towards whoever is providing the information (they are trying to make a sale). For this reason, it is advisable that an organization should collect the information and not make any commitments / decisions while still with the consultants / experts. The organization should wait until they have collected and analyzed the information from a number of different vendors / industry experts. This will allow them to have a wide variety of information so that the “sales pitch” parts of the information can be dis-regarded. If the organization’s Portal team is large enough, it is better if one member of the Portal team concentrates on a particular vendor. It then becomes their responsibility to gather all of the information they can about the Portal vendor and their product. After all of the team members have collected the information, they can become that vendor’s advocate to the rest of the team. The last group that will be discussed in this chapter are those that can help your organization implement a Portal. These members can

Portal Vendors & Their Solutions

33

come from the actual Portal vendor themselves, or from an external IT consulting company. Some Portal vendors have associated themselves with certain consulting companies. This association allows the Portal vendor to focus on developing products and the consulting companies on implementing them. At this stage in the project, you should be looking at collecting information that centers around what their capabilities are and what they can provide to your organization. At this stage you have not yet defined what your organization can do for yourselves and what you may need assistance with. The consultants may be reluctant to provide much information to you up-front, however if they know that there is a good chance of getting an engagement out of it, they will open up. One of the key information pieces to be collected is what methodology they are planning on following. Each consulting company follows a certain methodology for their engagements. What you need to do is to find out what this methodology is and if it is something that your organization can follow. They should also have experience in business process re-engineering / process design. If the consulting organization is stressing only the technical aspects of the Portal project, they are not looking at the whole Portal implementation process. A Portal implementation project can be conducted by a number of different consulting companies, one for the technical parts, and another for the business / process side of things. Although this complicates the implementation from a management perspective, it does allow you to select the experts for each phase of the project.

34

Portal Building

4 Current Organizational “Snapshots” Once you have collected and prioritized your organization’s pressing business issues, you then need to consider the existing business and IT situation of your organization. Many organizations skip this step when bringing in a Portal, which can cause a number of problems. As an Enterprise Portal implementation project should focus on integrating backend systems as well as changing how the organization “works”, the project team needs to have an idea of what some of the challenges could be. Taking the time to “survey the existing landscape” has a number of benefits. The first benefit is that it gives the Portal team an initial understanding of the amount of different backend systems that are present in the organization. This is important considering that the Enterprise Portal will eventually attempt to integrate with these systems in the future. Also, during this examination, discussions with the IT and infrastructure teams can start. These early conversations can help establish trust between the Portal team and the IT / infrastructure teams. This trust and cooperation will be vital in later stages of the project. So what should be examined during this stage of the project? The most obvious things to begin to inventory are backend applications and the organization’s existing websites and internal intranets (if any). Finding the main “cross-organization applications and databases” should be fairly straight forward. These strategic applications (ERP, CRM, HR, etc) will have technical people assigned to them to make sure that they are available during working hours, so a good place to start to catalogue them is with the IT department, more specifically, the Help Desk team. Once these large applications are catalogued, the team should also inquire about any smaller/more focused applications and databases. These are applications, that only a single group/department, like the marketing or finance department, use. This information can be collected from the IT department but it can also be collected from the different

35

36

Portal Building

departments themselves. (This information can be collected during the business requirements section by asking the individuals what applications they interact with most on a daily basis.) When you have identified the various applications and databases there is some related information that you should be collecting as well. Below, I have included a number of questions that you can ask either the IT department of the actual application owner. I have also included the reasoning for why these questions are important so that you can have some understanding in case the team needs to reword the questions so that they are appropriate to the organizational structure/culture. • What is the name or title of the application/database? This is important so that everyone can refer to the application / database by the same name. • Briefly describe what the application/database is used for. This question is used so that the team will know what it is supposed to do, so that they will have some understanding of what the users will be expecting from a usability perspective. • Who uses the application? Are there “power-users”? This will start the team to categorize the applications into who will be using them. It also starts to determine if there are different types of users who will be accessing them. • How important is this application/database to your department? To the entire organization? This question helps the group to prioritize the application, not only from the department’s perspective but also form the organization as a whole. • What are some of the business processes surrounding this application/database? This question allows the group to start examining if there are any business processes associated with the application and if they will need to be modified once the application is accessed via the Portal. • Do other departments use this application/database? All or just part?

Current Organizational “Snapshots”

• •

37

This question informs the team about the extended set of users for the application, and what are the parts of functionality that they use. Where is the application located? The location of the application is important from a connectivity and integration point of view. What is the condition of the data contained within the database/application? The Portal has the ability to highlight the application and the data contained within it. Therefore it should be very important to the users, and the application owner to ensure that the data is as accurate as possible.

As you can see, there is a lot more information to be collected than just the name of the application/database. Although this may seem like a lot of work at this early stage of the project it will pay off in the long run as not only will the team have an idea of the diversity of the organization’s applications but it will also provide exposure to the Portal project to the other areas of the firm and to allow them to see that the team values their input and knowledge. (Care should be taken when discussing the Portal project with these various stakeholder groups to ensure that the same and correct message is getting out and to ensure that expectations are managed correctly.) After applications and databases have been analyzed, the team should turn its attention to the organization’s public websites and internal websites / intranets. Most organizations have an external web presence by using a website. Other organizations even have websites that are centered on their employees to provide them with information regarding their department or from a firm-wide nature. Some organizations label these sites as websites and sometimes they are referred to as intranets. These should be catalogued as well. The information collected here is similar to the information collected with the applications and databases but with a few extras. Similar to the applications and database section, I’ve included a number of questions and the reasoning behind them. • The content and functionality for each intranet should be collected. (What is its purpose/objective? What can people do with it?)

38

•

•

•

•

•

Portal Building This is important to ensure that there is no duplication of information and functionality. Also, it allows for the group to prioritize the functionality contained within the intranets. Who are the people in the organization that the site is targeted to? Are there specific groups that the functionality of the intranets are targeted to? This is needed to ensure that the proper Portal users receive the correct functionality. Is there any feedback or metrics regarding how successful the site is? If there are specific reasons why the site is very successful (or not) they should be taken into consideration to ensure the continued success (or to improve it). Are there any lessons learned from when the site was deployed? Did the site’s team come across any particular pieces of information that the Portal team should be aware of when they bring this particular set of functionality into the Portal. Are there any issues or problems with the site? What are the problems that were encountered during the rollout of the site? This is important so that the Portal team can plan to solve these issues before they occur while being integrated into the Portal. What would they like to see changed on the site? During the migration of the site into the Portal there is an opportunity to make changes to the site.

An organization’s existing intranets can serve as a number of “quick wins” for the early releases of the Enterprise Portal. This is made possible by the fact that the content and functionality included in the site is already web-enable. It just may need some re-organization to bring it into the Portal. A big focus on this data collection phase should be placed on the business processes of the organization. All of the major processes should be looked at, regardless of whether they are automated or not. (For instance, how does the company communicate to its employees, or how does it communicates to its clients/customers.) This is important for a number of reasons. Not only does it provide ideas on

Current Organizational “Snapshots”

39

other functionality to include in the Portal project but it also serves to illustrate the need for the creation of business processes around the Portal project as well. Care must be taken to not get the Portal team involved in the business improvement/creation process for other departments. Even if a business process exists, there is a tendency for the organization to get the Portal team to start automating other business processes as well. This should be avoided as it takes the focus of the team away from the Portal. The Portal team should remain focused on creating/adopting business processes that directly tie into the Portal. During the investigation of your organization’s applications and databases some discussion should be centered around the corporate infrastructure standards (if any) that are in place. It may be that your organization has made a strategic decision to direct all technology software solutions to a particular vendor (if appropriate). In some cases, organizations have negotiated special pricing with these vendors. Although this should not influence the Portal team now, as they are not looking at solutions only what is needed from a functionality perspective, it will become important in the future as the team starts to compare Portal products. The development/ technology standards that the company has committed to are also important. When a company commits to a particular set of standards it affects the skill sets of the various development teams as well as the technology support teams. Again, this is not important right now but will become useful when the Portal products are evaluated. One of the benefits that can come out of this process is that the process itself can high-light any potential “turf wars” that may come up during the application’s integration process. I define a “turf war” as happening when a person or group who is usually in charge of a large application, an Enterprise application, sees the Portal project as a threat to their application and tries to create a negative feeling towards the Portal in hopes of having the Portal project either delayed or even stopped. When the Portal team discusses integrating an application into the Portal, some people may think that this means that the Portal team will assume ownership of the application. What the Portal team needs to do is to ensure that the application owners are aware of the various ways that their application can be used

40

Portal Building

through the Portal. The Portal can even be sold as a way of increasing the exposure of their application. Above all, it must be made clear that the Portal will not take control or ownership of their application. Even if the Portal team clearly states this, and that the Portal is only the vehicle in which to access the application, some application owners may still become defensive to the Portal team. This can result in not cooperating with providing information, providing false information, or even bad-mouthing the Portal project to others in the organization. Also, there have even been cases of “turf-wars” arising out of the fact that the Portal project is a high-profile project, which may be take the “spotlight” away from of other projects. Care must be taken when handling these situations as too much or too little pressure can reinforce this negative attitude. What is needed is for the issue to be dealt with quickly, even if it means bringing in upper-level people in the organization to handle it. There may be some application owners that still would prefer to have the Portal project fail. These people may be individuals that do not fully understand the Portal, or they may be those that are among the few application owners that may be losing their application, intranet owners, web site managers, etc. In order to placate these individuals, it may be necessary to include them on the Portal team. The members from an existing intranet project could provide valuable insights into what worked and what didn’t work in the previous project. Hopefully, the majority of these cases can be solved by clearly explaining the Portal project and how their individual application will fit into it This is where strong executive support is important as they may be called upon to have this discussion. It may be necessary for the executive sponsors of the Portal project to become involved in this issue. This should be the last resort as all efforts should be made to try to come to a mutual agreement. Some of the data repositories that are identified in this stage may be utilized by the Portal once it is up and running as a content source. For instance, a Human Resources data repository may be used for populating information regarding all of the Portal users. This is why the project team should ask questions regarding the quality/accuracy

Current Organizational “Snapshots”

41

of the data contained within the repositories. Depending on the age of the data repository or even its use, the data contained within may not be accurate for use with the Portal project. In some instances, the data repository owner may state that they will use the Portal project as a reason or the driver to “clean up the data.” From a Portal project perspective this statement should be should be received with some degree of caution. The accuracy of the data should be driven by the owners of the data, and even though a business user of the data is driving the improvement of the accuracy, the Portal team should insist on seeing a project plan for the clean-up and inform the data owners that a service level agreement will be put in place between the Portal team and the data owners that will contain accuracy definitions and thresholds to be followed. (More on Service Level Agreements (SLAs) to be covered later in this book.) There is also the whole issue of ensuring that the proper processes and checks are in place to ensure that the data remains accurate once it has been “cleaned-up” that needs to be addressed by the data owners. In order to ensure the proper execution of the Portal project, the Portal itself will need a certain level of accuracy of information. In order to achieve this requirement a decision may need to be made to use existing repositories or for the Portal to manage the data itself. This is a very important decision as one of the goals of the Portal should be to reduce the amount of data duplication that exists in the organization, and by managing the data in the Portal they would in effect be duplicating the data. Not only should data accuracy issues be addressed, but the data that the Portal requires may need to come from a variety of different repositories. If the Portal needs additional data, how easy is it to incorporate this new information into the existing repositories? And what are the processes associated to collect and maintain the data? Data repositories should be examined from two different perspectives. From one perspective, they can provide content to the users of the Portal. Unlike a traditional website, the Portal itself should not store any content. So any content served up through the Portal will need to be stored somewhere else. This content repository should allow for easy maintenance of the data to ensure that it is as up to date as possible. From the other perspective, the

42

Portal Building

data repositories can provide data that the Portal itself can use. From this point of view, issues surrounding data accuracy and the completeness of the data are important. It is easy to identify the most important data repositories as these are the ones that are used most frequently. However, once these have been identified the other repositories may be more difficult to identify as they may not have been used in a long time or they may be a copy of another repository. Here one needs to identify which is the most up to date copy and use that one while at the same time removing all of the other copies. During the project team’s investigations with the various stakeholders in the organization, the team may come across some individuals that may not be as receptive to the idea of an Enterprise Portal as others. This should be expected and if handled correctly, the team can minimize the negative impacts it has on the project. This could also be related to what has commonly been termed “office politics”. I have seen on a number of occasions that individuals will change their allegiance to the Portal a number of times throughout the project’s lifecycle. When the project is just starting, there may be some individuals that are against the project as they see little chance in it succeeding. Then as the project starts to gain momentum and popularity, these same individuals will want to become part of the project team. This must be handled carefully, as this flip-flopping can hurt the Portal project. Enterprise Portal projects are usually seen as very high profile projects within an organization as they touch on almost all aspects of the organization. For this reason there may be some individuals that may try and get involved in the project for their own benefit. Some of these individuals may even try to take control of the project team. If this happens, this issue must be resolved quickly as the “political” aspects of this discussions could take the focus off of the project for too long of time. This is usually handled by the existing Portal project manager recognizing this earlier and either dealing with it themselves or if need be, they should bring in the executive sponsors to help resolve the issue. The important part of this discussion is that it should be handled early and quickly.

Current Organizational “Snapshots”

43

Because the Enterprise Portal project can touch on all aspects of the Enterprise and can be seen as a business improvement/efficiency project, there may be other smaller projects going on throughout the Enterprise that the Portal team does not know about. These smaller projects are usually departmentally focused and are driven by small focused teams. In order for an organization to get the full benefit from a Portal, the project must remain focused. There must be a single team that concentrates on Portal issues for the whole organization. The Portal team should be on the look-out for these smaller teams and to hook into them for help in gathering business requirements for that particular department. Once the Enterprise Portal project is explained to these departmental project teams, they are usually quite willing to participate in the larger Enterprise Portal project. They can see the benefits as cost sharing, Enterprise-wide viewpoint, and centralized project management. However the biggest reason is that the departmental teams are usually comprised of individuals who have other specialties and job responsibilities. Once they realize that they will still control their business requirements and have input into the entire process, they are usually quite happy to leave the Portal development in the heads of the centralized Portal team. The Portal team can, and should use these departmental teams as a way to get detailed business requirements from the departments. Also, these teams can be used to help promote the Portal project to the rest of the organization. However, if they see the Portal team as coming in and taking over their work, they may start to create negative feelings about the project to the rest of the organization. These project teams can be either internal looking or even external looking. Especially on the external side, there are more benefits with having a centralized team handling the client facing parts. This single team can interface with either the customer teams or the departments that interact with them. Another factor to consider during this phase is that Portals should not be treated as strictly IT projects. The majority of the effort in implementing a Portal project is business related; process changes, culture changes, etc. Most organizations do not realize this and do not consider this when they decide to implement an Enterprise Portal. But by knowing that the Portal project is business focused, you can get the right team members together, but more importantly

44

Portal Building

the organization is better positioned to determine when is the right time to implement the Portal in the organization. There may be a number of other projects going on in the organization; such as upgrading the ERP system, a company merger or expansion; that could be taking the focus of the organization’s employees. All of these projects should be noted and their impact to the organization and the individual should be noted. This list can then be used to determine the proper time to bring the Portal into the organization. Some of the factors to consider in this analysis are; the ability of the end user to handle new things and change, availability of team members with the right skill sets, financial strength of the firm to support the Portal implementation, and even a gauge of the organizations willingness to change their culture to really embrace the Portal.

5 What Others Are Doing Now that the team has finished collecting all of the information about the organization, it’s time to look outside of the organization to see what other companies are doing. This should be done once the team has taken all of the information that they’ve collected and started to form the vision for the firm’s Enterprise Portal. This vision doesn’t have to be complete, but it needs to be formed enough to allow the team to determine the direction that they want the Portal to focus on. By examining what others are doing, it allows the team to level-set their own vision against others. It also allows them to get ideas regarding what others are doing and to utilize them if appropriate. The first thing to consider is to stay at a high level and to just see where others are focusing their Portal efforts. Up until now, the majority of organizations have focused their Portal efforts in either a B2E, B2C, or B2B space. However, what is starting to happen lately is that organizations are realizing that in order to fully realize the benefits of a Portal, they must start thinking of a new way of looking at Portals. Companies are focusing in on becoming more client or customer focused and they are bringing this into their Portal implementations. This means that they are no longer just bringing in a B2E Portal which focuses in on employee self-service, but they are creating Portal spaces that allow their employees to increase their client focus and relationship building. These types of Portals cannot truly be called B2E Portals. I have called them “inward facing client focused” Portals for the lack of a better label. What is important for the team is to look at other companies and to see what they are focusing their efforts on and what kind of benefits they are expecting (or are already receiving). From this analysis, the team can look at the benefits that they are expecting to get and compare them with other companies. For this type of research, they

45

46

Portal Building

can either look to the web, but this can mostly be collected with the help of Portal vendors. The vendors are usually willing to show you their success stories, and as more Portal implementations are occurring, they should have more stories to tell. What the team must be careful about is that vendors will only want to tell you about the success stories. The implementations that were difficult or failed are not likely to be talked about. Also, try to get stories from a number of vendors, which will hopefully reduce some of the “marketing bias”. Another way to get information on what others are doing is to attend Portal conferences. While the conferences themselves can be used as a sales platform for some vendors, the real benefit from them is in the time between the sessions when you can mingle and talk with the other conference attendees. This should be done without any of the vendor representatives around as they have a tendency of steering the conversation; what the team is looking for is rough information regarding what other companies are doing or what they are planning on doing. While the focus should remain at a high-level, the team should not be afraid to collect some more detailed information where possible. This lower level of information should be focused on the individual pieces of functionality that the other companies are incorporating into their Portals. (At the portlet level.) This can be a relatively easy task from a vendor perspective as most Portal vendors are very eager to show off the portlets that are available for their product. Why this is educational, it merely shows you the “out of the box” functionality of their Portal product. Since every company is a little bit different, chances are the project team will require something that is unique to their Portal implementation. For this, it is helpful to know how others are pushing the limits with respect to customizing their Portal implementations. This information can be hard to get as the team will need to find out what companies are doing this, but once they find them they are usually happy to show off what they’ve done as they will be proud of what they are doing. Consulting companies can be sources for this type of information as they will most likely be providing the assistance for the customization. The important part to remember is that at this stage the team is not really concerned with

What Others Are Doing

47

“how” they did it, they should stay focused on “what” they did. Finding out how will come at a later stage when the team is more prepared to utilize the answers. Some time should also be spent on trying to find out what your organization’s competitors are doing with respect to Portals. Do they have a Portal and what are they doing with it are questions the team should be considering. This doesn’t mean that the team should abandon their plans and merely follow what their competitors are doing. The team has spent valuable time collecting information on the business issues that the organization needs to solve, but it does create a goal, or a threshold, that the project team should be considering. If none of your competitors currently have a Portal, do not become too complacent, as they may be in the process of implementing one, and are not advertising the fact. Also, the fact that the project team is checking out your competition could also be an indicator that your competition is checking your organization out as well. This information is usually the most difficult to get as companies tend to be protective of their Portal efforts when they are still in the development stages. However, if the Portal project is structured correctly, once the Portal project is launched, your organization shouldn’t be too concerned with who knows about it. In fact, the more people who know about it the better, including the competition. The reason for this type of thinking is that by the time your competitors find out what your organization is doing, the project team should already be involved in the next phase of the project, so your competitors will always be one step behind. And if your customers know what you are doing and it is a benefit to them, they can start demanding this same level of service from the entire market, and if your competitors can’t provide this same level of service, your organization may experience an increasing market share. Finding this information out can be difficult and the project team should not spend too much effort on it, especially considering the issues of industry espionage and other risks. Although it is nice to have, it is not necessary. When looking at what other companies are doing, do not focus just on looking at companies in similar industries/markets. Look at companies from a variety of different industries as well as different

48

Portal Building

types of companies. Look at smaller ones, more geographically diverse ones, and even more centralized ones. Even though these companies themselves may seem very different to your organization, they may be experiencing the same business issues, and their different backgrounds may provide a different perspective on how they solve these problems. By focusing the project team’s attention on the solutions that the companies implemented and why, they may be able to find some unique solutions or even some ideas that can be brought over and applied to your organization. (Hopefully as the Portal market matures and Portal implementations become more numerous, there will be more public sharing on what has been done. Hopefully this book can be part of that process.)

6 Portal Requirements Creation In order to make a decision on what Enterprise Portal product is the most appropriate for your company the project team needs to have a good understanding of what they want the Portal solution to accomplish. This is done by creating a set of business requirements for the Portal. Portal business requirements are usually created by the individual departments and user groups within an organization, but at this stage, the Portal team will be creating these business requirements. These business requirements should reflect the overall requirements for the firm as a whole and should not only include the immediate needs of the firm but should also try to predict the future needs (at least at a high level) as well. What the team will be creating here is a document that lists the key functionality that the organization requires from a Portal product, as well as information on the vendor and the technical aspects of the product itself. One of the main things to consider when creating this document is that there is no common Portal terminology across Portal vendors. Some vendors may refer to the ability to add functionality to your Portal as customization while some vendors may call it subscriptions. In order to avoid this potential confusion, make sure to clearly explain what the team is looking for and try to avoid using vendor specific terms and labels. The most important part of this exercise is for the Portal team to ensure that these high-level business requirements are truly representative of the firm’s needs. We have already mentioned about interviewing various Portal stakeholders in the organization to determine their business needs. These business needs can be converted to business requirements by creating solutions for the problems and then creating business requirements around the solution. We have also discussed that the team should examine what others are doing with their Portal implementations. The Portal team

49

50

Portal Building

should be taking this information and creating business requirements from the most applicable points that relate to their organization. After the team has created a list of the organization’s Portal business requirements, these requirements need to be validated. This validation should be performed in two stages. The first part of the validation should be to present the list of Portal business requirements to a number of internal people. These people should be familiar enough with the Portal project and the organization as a whole so that they can quickly provide their feedback to the team. The most likely candidates for this validation are the Portal project managers, the Portal steering committee, and a select few people that were interviewed earlier. Not only can these individuals provide feedback on whether the list includes the most appropriate requirements, but they can also provide a prioritization of the requirements. Prioritizing the business requirements is important as it gives an indication to the Portal team what are the most important requirements that absolutely must be in the Portal product and what requirements are “nice to have”. This prioritization should not be done by the Portal team as it could be seen as a bias towards a particular Portal product solution. Once the business requirements list has been validated and prioritized by a wider group, the Portal team can pull all of this information together to create a single, prioritized list of Portal solution requirements for the firm. This list of requirements is uniquely tailored to your organization, and will not be identical to lists from any other firms, although there could be similar themes across company lists. Once the internal validation and prioritization is completed it is beneficial to have some outside advice on the list. This is where Market Research Firms should be used. These firms should not be used to select which Portal vendor is right for your organization, and they should also not be used to tell the project team what Portal requirements are the most important for your firm. They can be used to provide some information on what other companies are considering important when they select their Portal products. These general sets of selection criteria can then be compared against your

Portal Requirements Creation

51

company’s Portal requirements. However don’t be too concerned if what your organization requires is different from what the Market Research Firms are telling the project team. As long as your organization’s Portal requirements are based on sound business solutions to pressing business problems, the requirements are valid. Another point to take into consideration when developing Portal requirements is the difference between Strategic and Tactical positioning of the Portal. In short, Tactical positioning of the Portal is thinking of the Portal to solve the immediate needs of the firm. Strategic thinking involves positioning the Portal for the long-term success of the firm. Enterprise Portal projects are usually considered as strategic solutions, whereas a departmental Portal or intranet can be considered as a tactical solution. From an Enterprise Portal perspective it is more valuable to consider the Portal project as a strategic solution for the firm. This thinking should also help guide the creation of the Portal requirements and also the prioritization of them. The Portal team should make the rest of the team members aware of this positioning which should also be used as one of the key starting points for the creation of the Portal communication strategy. The saying that I always try to keep in mind for the Portal projects that I work on is “Think big, start small, and scale fast.” I ran across this quote some time ago and it seemed to fit so well with Enterprise Portal projects that I use it as a guide. With this saying in mind, you should always be thinking about the ultimate vision of the Portal, even though you know you will be implementing something noticeably different in the initial stages of the project. This means that when the project team is creating the Portal requirements they should make sure to include some requirements that they think the organization will be looking for in the future. However, even though they should record these requirements, they should not place too much emphasis or priority on them. This is because Portal technologies are still changing and by the time your organization is ready for the requirement, the technology that supports it may be different. But by providing requirements that the organization needs in the future, they are collecting information from

52

Portal Building

the vendor on its commitment to the product and the firm’s longevity. When creating the Portal requirements make sure that the team stays focused on the team’s ultimate goal; to find a solution that will solve the firm’s business needs. However, some members of your organization may try to steer the focus of the Portal requirements towards a different agenda. Some individuals may have a bias towards a certain Portal product or vendor and they may try to steer the requirements to favour their preferences. Some others within the organization may also have negative feelings about the Portal project and will want to see the project fail. These people will try to place requirements on the project team that cannot be met by any Portal product. What is important with this issue is that the Portal team ensures that for each Portal requirement there is a specific business problem that it is trying to solve. When groups actually start making the list of their Portal requirements, they usually spend the majority of the time creating technical requirements for the Portal. However, they should also spend some time to ensure that all of the business-focused issues are covered as well. These issues are usually concerned with end user training (product usability), administration requirements and functionality. These business focused issues can be handled by creating a number of technical questions that address these issues. But there are also a number of Portal requirements that should be included that do not deal with the vendor’s product; they deal specifically with the vendor. An example of this type of requirement that should be addressed here deals with the vendor’s support for the product, (is this something that the vendor is committing to for the long term?). Another item to discuss is around the vendor’s viability; (is the vendor stable enough to be around for a few years?) The third main topic deals with the vendor’s support policies. These are all questions that should be discussed when creating the requirements for your Enterprise Portal. Another section that the team might also want to include in their list would deal with existing relationships that they/the organization, may have with a vendor. If you are already doing business with a particular software vendor that also has a Portal product, you may have knowledge of their customer

Portal Requirements Creation

53

service and support policies. They also might have some knowledge of your business and technical challenges that would be of benefit during the Portal implementation. If this section is included in the document, it should not be given too much emphasis, if it was, it could possibly exclude a vendor even though they may have great customer service and support policies just on the basis that you don’t currently deal with them. Another set of business related issues to deal with are related to Enterprise architecture conformance. Most large organizations have created a set of guidelines (and some have even set up teams), to ensure that all applications purchased by the firm conform to a number of principles. The goal of all of this is to ensure that all of the firm’s application can interact well together. Not only does this ensure that new applications will not cause too many difficulties with respect to integration, it also ensures that the older existing apps will remain useful into the future. If this is applicable to your organization, the Portal team needs to ensure that these points are addressed within the requirements document. Care must also be taken to ensure that the requirements that the team has documented have some degree of “future proofing” in them. Asking technical questions that pertain to the vendor’s commitment to following open standards in their products is a good starting point. I also advocate that Enterprise Portals should have a “plug & play” strategy when it comes to individual pieces of Portal functionality. That way, in the future, if a piece of Portal functionality, like a search engine for example, that is offered by another vendor is better than the one you currently have, the existing one can be swapped out, without requiring a great deal of integration re-work. Most vendors will try to focus their Portal products as a set of products that “work best together”, but considering that your organization might have existing components that they would like to reuse in the Portal, this idea of a “plug & play” Portal not only future proofs your investment but it will also allow you to save money by reusing existing applications. Requirements that should focus on this issue are related to how closely the Portal product’s individual pieces of functionality are integrated to each other. Also, does the vendor support any third party products to help achieve some of the Portal’s

54

Portal Building

functionality. (This can also be linked with the issue of following open standards as the standards will allow for easier integration with other products.) After the document is complete the team should have a series of questions that can be grouped into a number of different categories. Below is a list of categories that should be considered when creating the requirements document. Not all of these categories will be applicable to every organization; this is only to act as a guide to allow the team to think about the types of things to consider. Business Related • Data Access • Content Aggregation and Publishing • Search, Index and Taxonomy • Personalization • Workflow • General Features Technical Issues • Server Platform Support • Portal Architecture • Performance • Installation and Documentation • Standards Support • Browser Support • Portlet Builders • Legacy Application Support • Hardware Resource Requirements • Scalability / Reliability • Security • Metrics / Reporting Vendor Issues • Financial Viability • Organizational Viability • Market Viability • Technology Leadership • Service and Support • Product Direction and Vision

Portal Requirements Creation

55

• Training Requirements Cost Issues • License Costs • Hardware Costs • On-going Maintenance Costs • Training Costs • Support Costs • Professional Service Costs. Another Portal requirement that most users expect to have in their Enterprise Portal deals with the ability to change what is displayed to the user depending on who they are or what they are intending to do. This personalization of the Portal is accomplished a number of different ways depending on the Portal vendor. The questions that should be asked about personalization refer to how the actual personalization is being done. Some Portal products rely on creating “user profiles” that dictate what the individual user will access. This is appropriate for smaller Portals or for Enterprises that have very distinct and clear user roles defined. The method that I advocate is to base the personalization on user attributes instead of profiles. In large organizations an individual could be classified as fitting into a number of different profiles. Also, using attributes provides more flexibility to the Portal team. New attributes can be added as new business requirements come in, and existing attributes can be changed or modified after examining their usage. Portal attributes can also be shared over a number of different pieces of functionality. For example creating an attribute that stores the geographic region where someone works might first be used for providing tailored company news, but it can also be used to display relevant sales financial results (or client information) pertaining the individual’s region as well. Closely associated with personalization is customization. This is defined as the ability for the end user to select additional pieces of functionality themselves that can be displayed on the Portal. Most people think that this is a highly desirable functionality, but studies, and my own observations have shown that most end users do not rank this very high themselves. Once a person first starts using a Portal, they may customize it to a certain degree, but once done, it

56

Portal Building

might not change for a long time. Also, if the Portal team is able to properly utilize personalization attributes, there should be very little need for this added customization. That said, the team should still consider including this functionality into the list of Portal requirements. The final Portal requirement that I will discuss here has to do with where the actual Portal solution will be located physically. If your organization is global in nature the team will need to consider where to put the Portal solution (this is referred to as hosting). Some larger organizations also plan on hosting their Portal solution in a number of different locations. The reasons behind this centre around performance, availability, and disaster recovery issues. All of these decisions need to be considered with respect to vendor support in the areas where the team is thinking about hosting the Portal, as well as issues like support in the native language, support in the local business time, and even the skill sets of the local technical population. Another requirement to consider is whether or not the Portal solution will be hosted internally, or by a third party. This will have a big impact as some solutions may not be available to third party solution providers, or that the amount of configuration that is needed to set up and maintain the Portal product makes third party hosting seem undesirable. After all of the Portal requirements have been recorded into a single document, this document must be circulated to the entire Portal team and the project’s executive sponsors for their sign-off. This document can even be circulated to some of the people that provided input into its development as well. This is to ensure that everyone is aware and is supportive of the requirements, as this document is what the decision to select a Portal solution will be based on. All further discussions and decisions regarding the Portal solution selection process will be guided by this document. For this reason, the team may want to spend some time with the business stakeholders to go over the document in some detail to ensure that there are no questions about the Portal requirements. (This can also serve as a way for the Portal team to ensure that they have not forgotten any requirements.) When discussing this document with

Portal Requirements Creation

57

the business stakeholders, they will want to know justifications for some of the Portal requirements. (“Why is this included in the document? or Why is this important?) This is a positive sign when these questions are asked as it shows that the business users are actually interested in the project and are giving it some thought, and it also provides for a way to prioritize some of the requirements. Once the business side of the project has had a chance to review and sign off on the document, the document should be circulated to the technical members of the project team for their review and approval. (This process is the same as the process used for the business review.) Once this part of the project is done, the Portal team and the project sponsors should sign off on the document, stating their approval and commitment.

58

Portal Building

7 RFIs & RFQs Once the project team has a set of approved Portal requirements, the next step is to officially determine which vendors can satisfy these requirements. I mentioned the word “officially” because up until now the team would have had discussions with a number of Portal vendors on a casual basis. Now the team needs to release a company document which in most cases would be called a Request for Proposal (RFP) or a Request for Information (RFI). Depending on your organization, the team will have to issue one or the other, or in some cases, both. Most companies have well established procedures that must be followed when issuing RFI’s or RFP’s. These procedures are in place to ensure that the process for selecting a vendor is transparent and fair. It is up to the Portal team to ensure that they work with the department responsible for issuing these documents to ensure that these processes are followed. One of the biggest concerns when issuing these documents revolves around timing. Since the issuing of an RFI/RFQ is the signal that the company is about to commit some financial resources to third parties, a number of approvals will be needed. Also, when this process is occurring with respect to the organization’s fiscal year will impact the timelines associated with the process. This is usually applicable when this is occurring near the end of the fiscal year. If there has been money set aside for the project that may be taken away in the new fiscal year, the process may be rushed to ensure that the money can be used. However, if the money is expected to come out of next year’s fiscal budget, the process may be slowed down to ensure that this happens. The process surrounding the issuing of the documents, and receiving vendor feedback can be a lengthy one and this needs to be budgeted for in the project plan. (The team responsible for issuing these documents should be able to provide a rough estimate of how long this process usually takes.)

59

60

Portal Building

The creation of the RFI / RFQ should contain all of the requirements that were documented following the steps in the previous chapter. These requirements focus on the product as well as the vendor and their service and support levels. Since the business and IT stakeholders have all signed off on the business requirements, the RFI/RFQ document should also be approved as well. The team should try to make the document as complete and as clear as possible. Since the team’s decisions will be based on the responses to the questions contained within the document, try to ensure that the questions are not open for interpretation. Also, when asking questions in the RFI/RFQ avoid asking Yes/No questions. You want the vendor to provide as much information as possible to support their answer. (Although, asking some Yes/No questions is a way to determine the amount of effort that the vendor is putting into creating their responses. This could give the team some indication of their desire to have a successful response.) Once the document has been created and approved, the team must decide on the number of vendors to send the document out to. The main drivers for this issue are the team’ perceived knowledge of the Portal marketplace, any vendor preferences existing in the organization, and the project’s timelines. If the Portal team already has a good deal of knowledge about the Enterprise Portal marketplace, they may be able to reduce the amount of vendors that they send their documents out to, if they don’t they will want to increase the number of vendors that receive the document. The organization may already have some Enterprise Vendor Agreements in place. These existing agreements will most likely influence who the team sends out the document to; even if the team perceives that a vendor does not have a viable Portal product, they still may be required to send them a document for political measures. Also, analyzing each vendor response does take a great deal of time; if the project is under some tight time constraints, they may want to consider limiting the amount of vendors that they send their document out to. If the team does have the time, they might want to increase the number. One of the ways that can help to reduce the number of vendors that the team sends the documents out to is to use a market research

RFIs & RFQs

61

company. These companies can provide the team with information on who they see as the market leaders, and who they think will be leading the market in the future. If the team does go with this route, do not rely on the opinions of just one of these companies. I would recommend that the team ask a number of market research companies for their advice, or at the very least, use their own judgment when listening to these companies. The team has spent a great deal of time collecting information on what the capabilities of Portals are and what is required by their company and this is a good validation point against what is being told to the team by these market research firms. One of the best ways to use these types of information sources is to formulate a list of vendors to send the document out to. For each vendor that the team selects they should be able to provide reasons why they are on the list. (For some of the vendors that are not on the list the team may want to provide reasons for them as well, especially if they think that some of the members of the organization will question the decision.) After this list is created the team can then go to the market research firms and get them to confirm their list. If they can come up with the same reasons as the team did, they know that they are on the right track. They may even provide additional reasons as well. Even if the market research firms confirm the team’s decision, it will be time well spent. This provides the team with even more justification for their actions, and it shows to the rest of their organization that they are committed to doing the due diligence that is required to come to the best decision for the organization. After it is determined who will receive the documents, the organization’s procurement department will usually take over the process. They are the ones who will format the document and send it to the selected vendors. At this point, the project team should not be directly contacting any of the vendors. All vendor communication should be directed to the purchasing department to make sure that no vendors are receiving any special treatment. This process is usually very clearly defined to the vendors and to the project team by the purchasing department.

62

Portal Building

The process surrounding the vendors responding to the document will require a couple of weeks of time. During this time, the team may need to answer some questions that the vendors may have about the requirements. This “question” time should be clearly published in the original document to the vendors. These deadlines, and all other deadlines in this process should be followed very closely. The team should not let vendors decide what the deadlines should be. The onus should be on the vendors to meet the deadlines, and not have the team change them to meet their resources. In order to be fair, what is usually done is to have the purchasing department collect all of the questions from all of the vendors and have the project team answer these questions either by an email, or by a conference call. Even if a vendor did not ask any questions, they should be able to listen to the answers. Again, most organizations will have established procedures for this part of the process. Also, it should be made very clear to the vendors that this will be their only opportunity to respond to the requirements. Some vendors believe that if they submit a draft document by the deadline, they will be able to amend it later. It should be made clear that this is not the case and once the submission deadline has past, they will not have any other opportunity for response. During the time that the requirements document are in the hands of the vendors, the Portal team should use this time to create and finalize the scoring system that will be used to evaluate the vendor responses. This scoring sheet, along with the process needs to be finalized before any responses are received to ensure that there is no perception of bias to any vendor. The scoring sheet used by the Portal team should be created by the entire team and should be available to the Portal stakeholders and other interested parties. The main goal of this sheet is to allow anyone to use the score sheet to come up with similar answers that were developed by the Portal team. This score sheet should contain all of the Portal requirements that were sent to the vendors. The answer for each of the requirements should be graded using a numeric scale. Feel free to use whatever scale is most common in your organization, but if this is not the case, a simple 1 – 6 scale

RFIs & RFQs

63

works well. (Try to avoid using a 1-5 or 1- 10 scale as people tend to pick the middle value when they are not sure of an answer. By not having a choice of a middle value, the user is forced to make a decision.) What is important to note here is that for each Portal requirement the team needs to define what type of answer would be classified as a 1, or a 2 and so on. This definition of the answers can contain information on the level of detail contained in the response as well as if the vendor mentioned key terms that were expected by the team. I have always suggested that the team should reward vendors that provide detailed explanations of their responses so that the team can understand how to apply it to their specific case. (Rewarding a response by giving it a higher point score for the requirement.) Along with a definition of the answer rating scheme the team should also develop a rating system that can be applied to each requirement. (or to a group of requirements). Again, it is best to use a simple, numerical scheme (1-6), but if the organization has a preferred method, that can be used as well. This rating scheme should be reflective of the overall goals of the project and can even be linked to the overall goals/vision of the firm. If the team is applying a rating system to the general sections of the document, they may want to consider getting the Portal sponsors to set the rating or at least validate them. Once the rating system has been created, the Portal team should then set a rating for each requirement or heading as well as document the reasoning for the value. One of the benefits for using a weighting system, especially one that has weights at the individual and category level is that it takes the emphasis off of a single requirement. Another aspect of the scoring system that the team may want to implement is to put in place a minimum score value for each requirement. This value would define a minimum acceptable value for each question. If the team does decide to use this, they need to clearly define a minimum value for each requirement as well as the reasoning for it. Also, it must be made clear what will happen to the vendor responses if they do not achieve the minimum value. Is the whole response discarded or do they just get a low value for the response? Most companies that use a minimum value system in their

64

Portal Building

scoring do not disqualify vendor responses, but will use it as a way to justify their final decision. Once the scoring system and process has been finalized the examination of the vendor responses can be begin. The team can expect that some vendors that received the requirements documents will not respond, but they should be prepared to analyze the responses for all of the vendors that received one. (The team may even receive a response from a vendor that was not sent a document. If this is the case the team should not even look at the response.) Once the submission deadline has passed, the purchasing team that is handling this process for the Portal team will give the team all of the responses. (It is usually common practice to ask the vendors for a number of hard copies of their submission as well as an electronic copy. I have found that asking for 3 hard copies and a soft copy is usually sufficient. Since the purchasing department will usually keep one for their records, this leaves your team with 2 copies.) If the team receives a large number of vendor responses it may be best to do the evaluations in 2 stages. The first stage will focus on a high-level examination of all of the responses. At the end of this stage the team will select the top responses to go forward to the second stage. This second stage will involve a more detailed examination of each response. In the first stage of the response examination each team member should have a chance to examine / read each of the vendor responses on their own. They should then proceed to score the responses. This evaluation and scoring should be done individually with little if not any influence from other team mates. This type of evaluation need not take time to allow for an extremely detailed review, but it should allow the individual to become familiar enough with the response in order to make an evaluation. After all of the individual team members have had a chance to score all of the responses they should pull all of the scores together. This meeting will allow the team to come up with a list of the top scoring vendor responses to take to the next step. For those vendor responses that do not proceed to the next step, the team should be able to document why and where the deficiencies were in their responses.

RFIs & RFQs

65

For the second stage in the process, the team needs to examine the responses in detail. Depending on the size of the Portal requirements document the team can get some indication of the size of the vendor responses. If the team is expecting some lengthy returns from the vendors it might be beneficial to divide the Portal team into a number of smaller groups that would advocate a specific vendor. These smaller groupers, (which can be a single individual), would be responsible for knowing a vendor’s response in detail. This process should be done in a group setting. For each Portal requirement the entire team needs to agree on the score and the reasoning. This final detailed analysis will not produce a recommended solution that can be given to the project sponsor but should be viewed as a mechanism that allows the team to create a score and rank all of the final responses. (The scores become the team’s justification.) For simplicity, the team will usually only provide the score to the top 3 or 5 vendors when passing the information onto the project sponsor. The goal of this phase of the project is to provide the right amount of information to the project sponsor so that they can make the final decision. After the team does their final scoring, they may want to schedule some time with the vendors to clear up any assumptions they may have made during the scoring process. This can be in the form of a vendor site visit or even just a phone call depending on the number and degree of the assumptions made. This is all focused on creating the best information (and most accurate) that the project sponsor can use to base their product selection decision on. This will also ensure that from a vendor perspective their information was received and interpreted correctly.

66

Portal Building

8 The Product Selection Process Once the team has provided the final vendor scoring to the project sponsor, very often the project sponsor will want the team to make a recommendation, (select a vendor). This occurs since the project team will know the most about the vendors and the needs of the firm. In most cases, if the project team has followed the proper methodology, the recommendation will be based on the final scoring that was done in the previous chapter. If there is a clear winner in the final scoring, the recommendation will be an easy one. But if the scoring is very close between the top 3 three vendors, the final decision may not be the top scoring vendor. Once the final scoring has been made, the project team may want to confirm their final vendor decision by utilizing their connections with some market research firms. Most market research firms will not tell you what vendor to chose, and they shouldn’t since they don’t have all of the information regarding the needs of your organization, but they can validate some of your assumptions or reasoning that you used to come up with the decision. If the project team has used a market research firm to help justify their decision making process, they may not feel the need to use them again for this part. However if they feel that the decision that they will make may be controversial, they may want to use a market research firm to help justify the decision. If this is the case, the project team may want to think about using a different market research firm than they used in the previous stage. This will greatly enhance the project team’s decision as they can have the backing of two separate market research firms. Once the team has made their final decision it should only be made to the project sponsor. The rest of the organization should be notified that the team has narrowed their decision down to 2-3 vendors. This has a number of benefits. Even if your organization has made a decision to go with a particular vendor, it will be

67

68

Portal Building

beneficial to your company to always wait to make the final decision. Even though the vendor may have the best product and service, their terms may not be what the company is willing to except. (By having the vendor know that there is another vendor still in the race, it may produce more favorable terms for the organization. For this reason, it is always best to delay announcing the chosen vendor. Not only is this beneficial from the company’s perspective towards clients, but there may be some members of your organization that are favoring, (and have close contacts with) competing vendors. These individuals, if unhappy with the vendor decision, may start to announce the decision to their vendor contacts as well as to other members of your organization before the team is able to produce an official announcement. This is also applicable to large organizations that may have a number of consultants and contractors working in their facilities. These people may hear of the Portal team’s decision and relay this information back to their own companies. Not only could this information get back to the Portal vendor companies, but these consulting companies may start to inquire about providing assistance to the team for the project’s implementation. The decision to choose which Portal solution your company should purchase is a very important decision. This decision will set the direction of the project that will be difficult and expensive to change in the future. The justification for the decision can be broken down into two types; the decision will be made on either tactical reasoning or strategic reasoning. Making the decision from a tactical perspective; focusing on solving the organization’s immediate and short term business issues. Solutions that will fit this type of reasoning are usually less expensive to purchase and are quicker to implement. Strategic decisions are usually focused on providing solutions that will solve the long term issues of the firm. These types of solutions are usually more expensive and take longer time frames to implement. From an enterprise Portal perspective, the proper stance to take is somewhere in the middle. (It won’t be exactly in the middle between these two extremes since each company has different issues and goals for their Portal implementation. Depending on what these goals are, will determine where your stance should be.) As I have mentioned earlier in this book, the motto that I

The Product Selection Process

69

have used for my Portal implementations has been “Think big, start small, scale fast.” So from a decision making perspective, you should be thinking both strategically and tactically. The product that you choose should fit with your long term vision of the project and should be evolving to fit your future needs. However it also needs to provide your organization with some immediate benefits in the short term. The important point to note here is that the Portal team should be the group that is driving this process and they are the ones “setting the agenda”. It is very easy to have projects such as this get sidelined by other people trying to add their agendas into the overall project. Make sure that the team stays focused on the original vision and goals of the project. If a suggestion is made to change the scope of the project the team can always go back to the project vision and goals, and if the suggestion does not clearly help achieve the goals, the change should be resisted. Also, this is a time where other functionality can be added to the product or project. Once the team has gotten this far, they may be feeling confident about their abilities and are willing to take on additional scope for the project. Other individuals in the firm may also have noticed the success of the team and may want to add additional scope to the project. This should be resisted. Implementing an enterprise Portal is a complex and timeconsuming project. Take a close look at the project and the product functionality that you are making a decision on. Decide if the team can handle the current scope with the current resource levels. If not, look at the functionality requests to see if some can either be delayed or even if they should be broken off into their own project. (Most Portal vendors mention that implementing a Portal also needs a corporate taxonomy in order to be successful. In my experience these are both large projects and should not be combined; although the two teams should work together closely on both projects.) Once a decision has been made; either picking a single vendor or picking the top 2 vendors, you may want to consider doing a proof of concept with the vendors. Most organizations, and vendors, prefer to do a head-to-head proof of concept, pitting their product against another, sometimes referred to as a “bake off”. I will usually caution against this approach. Firstly, by having two proof of concepts run

70

Portal Building

simultaneously it cuts down the amount of time that the team members can spend getting to know the details of the product. Also, proof of concepts are not free. Some vendors will advertise that they are free, but they will dictate its extent. But in order to truly examine the product in your organization’s setting requires some amount of chargeable effort. (Some vendors will deduct the cost of the proof of concept from the purchase price of their solution, if chosen.) From a strictly financial perspective, it is better to start off with one proof of concept. Choose the vendor that your team is leaning towards in their decision. If the proof of concept does not go well, you can then move on to the next vendor. This line of thinking allows the proof of concept to be the last step in the validation of their decision. Most organizations use the proof of concept to evaluate the product in more detail, and to see how well the product fits into their existing infrastructure. While this is a valid approach, I have also recommended that the proof of concept should also be used to evaluate the vendor and their development and support teams. One of the ways of looking at vendor’s development and support teams, is to have the proof of concept be done completely at your site. Some vendors will want to do a large portion of the development and configuration of their product at their own site and then bring it in just before it is ready to install. Not only does this not allow your team members to get a feel of the complexity of the set-up and development procedures, but it also does not give the team any indication of the depth of resources that the company has, and the amount of assistance that they are willing to provide to their customers. At the beginning of the proof of concept, the Portal team needs to come up with a list of criteria, or business problems, that need to be solved by the proof of concept. This list should contain the most important integration issues (like email, or the most popular applications/content repositories). The list should contain some very challenging integration/set-up issues. I will try to use the proof of concept to push the vendor so that you can not only see the capabilities of the product but also the capabilities of the people at the company. The team should be looking at the proof of concept to help them either solve some of their most difficult business issues, or

The Product Selection Process

71

at least try to determine ways to solve them. Once this list has been completed and given to the vendor, there will be some push back from the vendor. From their perspective they want to ensure that the proof of concept is a success so they will most likely push back on the really challenging issues, or at least try to steer the proof of concept towards the strong parts of their solution. Avoid having the vendor dictate the proof of concept, after all, this is to see if their product can do what you need. Also, let the vendor know that not only is their product being evaluated but also their people. This may allow them to suggest that if there is not enough time to include some of the more difficult solutions into the proof of concept solution, it may be acceptable to have a series of meetings during the proof of concept timeframe between their experts and the Portal team to discuss ways to solve the issues. This way, the team gets the solutions they are looking for, and the vendor can show off their experts that do not normally get introduced to the client. Another requirement that should be included in the proof of concept is to provide for some time after the concept is built to allow some users to use the solution and provide their feedback. This time period does not need to be very long, a couple of weeks at the most, but it should be long enough to allow for a number of different people to get a taste of the solution. It can also serve as a way to determine how stable the solution is. (Taking into consideration that this was built in a short period of time and not focused on producing a “production ready” solution.) Not only will the proof of concept require a time commitment from the vendor, but the Portal team should also be prepared to spend time with the members of the vendor team. The Portal team members should be present at all of the different stages of the proof of concept. It may be beneficial to have the Portal team members specialize on certain areas of the Portal. For instance, one can be a specialist in setting up the infrastructure, one can be a specialist on a specific component, etc. This allows the team members to focus in on their specific part of the proof of concept. It is wise to have at least one generalist present for the majority of the time. This person should not be expected to know the details of each part but should focus in on how all of the pieces fit and work together. Not only

72

Portal Building

should the Portal team be present with the vendor personnel but it is also advisable to include members from outside of the team that this project will impact. Members of the development, infrastructure, and support teams should also be included. Not only does this give them the opportunity to ask questions, but it also ensures them that you are including their opinions in the decision making process. The team may also want to consider bringing in some “users” to take a look at the completed solution to get their opinions on usability matters. Before the proof of concept actually starts, the team needs to define how the proof of concept will be evaluated. Most vendors will stress that if they are able to complete the requirements the proof of concept should be considered as a success. However, there is much more to the evaluation decision. It may be that the vendor was able to achieve all of the requirements, but they were done with custom coding that none of your organization’s personnel can understand. Not only does the vendor need to achieve all of the requirements but there should also be a number of other criteria to evaluate them against. Things like how open were the vendors to sharing their development information, were they able to provide the team members with useful background information to assist them in learning the application. How intuitive is the application to learn? How adaptable is the application to your environment? These are all questions that could be asked about the vendor’s product. The team should also be collecting information about the expertise of the vendor and how willing they were to share that knowledge with the team. The Portal team may want to create a scoring sheet for the individual requirements, as well as a comments sheet. The comments sheet should be given to all people that either interact with the proof of concept solution or the vendor’s personnel. This comments sheet should allow them to record their opinions on the solution and the people that they dealt with. Prompting questions or statements can be used to ensure that they provide information on relevant areas. The team can then use the comment sheets and the score card to come up with their final answer. Once the proof of concept is finished, and the results from the usability tests are in, the final decision of which Portal product and

The Product Selection Process

73

vendor can and should be made. There needs to be a clear and definite answer that can be announced to the rest of the organization. This needs to be done from a vendor’s point of view so they can begin to gear up for the implementation part of the project, and it also needs to be done from your organization’s point of view in order to provide closure to this phase of the project and to move onto the next phase. Once the Portal solution decision is made, the Portal team can now begin to provide more details about the Portal solution that will be implemented to the rest of the firm. Until now, the team could not talk in much detail due to the fact that they did not know which solution would be purchased and therefore did not know what capabilities would be initially brought to the organization. (Most Portal implementations concentrate on implementing the “out of the box” functionality in the initial phases due to the fact that these are the easiest and quickest pieces of functionality.) Not only can they begin to provide more details on the Portal product to the firm, but the decision to purchase a Portal solution also signifies a major commitment to the project by the firm. Up until this point in the project, no external commitment to the project has been made. (There may also have been no solid internal commitment either.) The project sponsors could have at any time pulled their support for the project and moved the resources onto another project. However, after the organization makes a commitment to a vendor to purchase a software solution, it signifies to the internal and external stakeholders their commitment to the project. Also, once an organization has made an outlay of money to purchase a software solution, it will usually expect to see results from its usage fairly soon. (Organizations do not like to have their software purchases sitting on the shelf once they have bought it.) This will result in an increase in pressure from the project sponsors and other related parties (including even the vendors), to quickly implement the Portal solution. The project team must resist the temptation to “fast track” the rest of the project. There is a great deal of work that is not related to implementing the technology solution that will need to be completed before the Portal can be launched. This time can be put to good use by having the technical team (including the

74

Portal Building

developers, the administrators, and the support teams) to become familiar with the product to ensure that once the launch date is here, they can be confident that the technical side of the project will run smoothly. A note of caution should also be raised at the end of this phase of the project that has to do with “office politics”. This could result from the team becoming a victim of its own success. Enterprise Portal projects are usually very high profile projects. If the project team does a good job with the first phase of the project there could be a temptation to take some of the project team members and put them on other projects that may not be doing as well. From an organization perspective, this merely involves switching some resources. (Moving a team member from the Portal project onto another team, and bringing a team member from the other team onto the Portal team.) While on paper (or from a high level project plan perspective) this would result in the improvement of another team while keeping the Portal team on track, this is not usually the case. Taking a key team member away from the project at this time could result in a delay in the project while the team member’s replacement gets up to speed on the project and their responsibilities. The project manager should resist the temptation to change the team’s structure at this point in the project. Once the project nears its completion, then the issue of re-organizing the team can be re-visited. Another issue that the project team should be aware of at this phase is that there may be some individuals within the organization that might use this timing to take a larger interest/stake in the project. As I mentioned before, these types of projects usually have a high profile within the organization. There may be some individuals that would like to have the project associated with them. These individuals may have been watching the project from a distance to see if it would pass the first phases. Now that the project team has past the first phase and done so successfully, they may begin to try and become more involved in the project. Having more support for the project is beneficial, however the team must be aware of those individuals who come onto the project at this stage and try to change the direction of the project. They may go as far as to try and get ownership of the entire project. This “political battle” will only hurt

The Product Selection Process

75

the project if allowed to continue for some time. The project sponsors must quickly recognize what is happening and rectify the situation. I have always recommended that the ownership and control of the project should remain with the individuals that brought the project to this phase, (unless there were difficulties or there are definite reasons for the change.) Not only will this keep the project running without causing any delays, but it will reinforce the idea of teamwork and the team will see that the project sponsors, and the organization’s executives, are firmly behind the team and support their decisions and direction.

Planning

Planning This section of the Portal implementation project (and this book) is the phase that most times gets glossed over and is not treated with the respect that it requires. After spending the team’s time and the organization’s money selecting and purchasing an Enterprise Portal solution, most teams will want to jump right in and start working with the Portal product. However without a clear and detailed project plan, this can very easily lead to mass confusion. This section devotes a number of chapters to creating the project plan. It will discuss the major components and issues that should be included in the plan, as well as some of the potential pitfalls to avoid. Since an Enterprise Portal is a technical solution to a business challenge, there will be some technical aspects to be included in the project plan. These will be described in this section, but only from the point of view of what a business person needs to know about them. Not only does the main project plan have a technical and a business component, but it also contains a number of smaller and more detailed plans, which will also be discussed. As was mentioned in the previous section, the implementation of an Enterprise Portal is an iterative project that should be continually added to and improved on a continual basis. It is very common for new functionality to be scheduled for every 60-to-90 days. This requires an established change management plan that can be followed regularly. Another topic that will be addressed in this section is how to put together the appropriate implementation team. Most organizations are aware that they require a strong technical team to pull all of the software components together and integrate the Portal into the organization’s infrastructure. However, little attention is usually paid to creating a part of the implementation team that is focused on business issues. This team’s objectives are to ensure that the business processes and personnel within an organization are ready for an Enterprise Portal.

79

80

Portal Building

Even though the topic of strong executive sponsorship was mentioned in the previous section, it is also important in the Planning phase of the project. In this section, this initial executive sponsorship is strengthened and expanded upon so that support for the project will continue to grow. As well, this section will discuss the possible benefits of having the role played by the executive sponsors change as the Portal matures. This section has a number of milestones. The most substantial of them is a completed and approved project plan that can be followed to meet the required dates of the project, especially the final delivery date. The other deliverables are a dedicated (and skilled) project team of both business and technical personnel, and strong and visible executive sponsorship. These milestones will be crucial for the next phase of the project, Building.

9 Change Management – People This chapter will deal with two types of change management from a people perspective. The first type of change management that will be discussed occurs during the implementation of the project; with respect to how the project will affect other projects and their managers. The second type of change management issues will deal with the end users and how the project will affect them. One of the first issues of change management that the project team will run across is what I am labeling “turf wars”. This happens when an application owner or a project manager feels threatened by the Portal project and starts to attempt to close the Portal project down, provide negative information about the project, or even try to take ownership and control of the project. The outcomes of these occurrences can all have negative impacts on the project, and even if the individual does not succeed, they would still have taken the attention of the project team away from the project and focused it on the individual’s attack on the project. This can easily be avoided or at least reduced by ensuring that all of the application owners and project managers have a clear and solid understanding of the project and its benefits to the organization. I have also found that providing information on how the various other applications and projects fit into the Portal project is helpful. Clearly showing that the Portal will not take away the need for the various applications, and it in fact places a higher dependency on them, will in most cases make others support the project. What makes a Portal very powerful is that when properly implemented, a Portal is much more than just a technical solution. A properly implemented Portal will also focus on the business processes associated with the applications and the functionality that are incorporated into it. In fact, I have always said that without considering the business processes associated with a Portal

81

82

Portal Building

implementation will result in the implementation of a standard website; and there are a number of cheaper technical solutions out there that will provide your organization with the ability to create a website. From a change management perspective, the business owners of applications and the organization in general should be aware of the focus on business requirements. Successfully implementing an Enterprise Portal provides for the project’s focus to be centered on business processes. This can involve either changing existing business process or even creating new ones. However, the focus should be on the end users and how to get them to start incorporating the Portal into their daily routines. This can be done by properly informing them of the capabilities of the Portal, educating them on how to use the functionality of the Portal, telling them what is coming in the next releases of the Portal, and even by shutting down the existing access points to the applications that are brought into the Portal. One of the more difficult ways of changing people’s attitudes and the way they work is to prevent them from doing things the way that they always have. By removing the old way of doing something, it forces the user to try the new way. When dealing with business processes, I refer to Portals as the “etcha-sketch” of process re-design. What I am referring to here is the ability that Portals can bring to light for the need for changing the current business process. Also, the Portal project will bring a number of resources to the project that can help bring about the changes more quickly. So in effect the Portal can start to “shake up” the business processes within the firm and cause new ones to be created or even fix the existing ones. This is appropriate especially when considering the other saying that I use: “Think big, start small, and scale fast”. The ability to quickly spot the need for process redesign and to quickly carry out those changes is very important in the implementation of an Enterprise Portal. By making changes to the organization’s processes, the team should be focusing on ensuring that the new processes reduce cycle or process times. This is usually accomplished by informing the managers and other executives of the benefits of modifying the

Change Management-People

83

accompanying business processes. An Enterprise Portal is more than just bringing content and applications into a single interface; its real power comes from modifying the business processes that are associated with the applications. For this matter, the Portal team should be careful to ensure that the managers and above are aware that business processes should be modified to incorporate the Portal and not just content and applications. This involves a great deal of business related experience in order to properly identify and analyze the appropriate business processes that should be moved. In fact, implementing an Enterprise Portal only deals with approximately 3040% information technology related issues, the remainder deals with business issues. (Issues like changing business processes.) When dealing with the people aspects of change management, the Portal team needs to be aware of the office politics that are usually associated with the changes. Assessing the culture, interrelationships of various critical factors; senior management support, common goals & objectives, transforming resistance to change, rules of engagement, training process and workflow are just some of the issues that need to be considered. The important thing to understand about change management is that it usually is not focused on building consensus with the organization, but is concerned with changing people’s attitudes and behaviors. When trying to plan the timeframes around these tasks, it is difficult to estimate the time required to have these behavior changes accepted by the users. Utilizing someone who has experience with the organization and by putting extra time into your project plan are a few ways of ensuring that your team is able to meet its deadlines. The beginning of this chapter focused on the people side of change management when implementing an Enterprise Portal in your organization. The remainder of this chapter will concentrate on dealing with the IT processes and how change management will/should effect them. I previously referred to an Enterprise Portal as the “etch-a-sketch” of process re-design. When implementing a Portal, it gives the organization the chance and the focus to begin to analyze and adjust their internal processes. This can allow the firm to adjust their processes to ensure that they allow the organization to focus on its business strategy and not on the processes themselves.

84

Portal Building

One thing about processes, and IT processes in general, is that they are a very grass roots focused entity. New processes are created when needed, or others are adjusted when required. This is usually done without thinking about the overall processes of the firm or even looking at the big picture. From a Portal’s perspective, it needs to be capable of delivering a solution for each group within the organization, and so it must be focused on keeping the processes focused on a firm-wide level. In the previous section of this chapter we examined change management as a way to help the organization’s people and their processes migrate from their existing state to a new state that is centered on a Portal and on having a client or user focus. In this section we will talk about using change management techniques to control and manage the various releases and functionality that will be continually developed and migrated to the Portal. In fact these are very similar things. They both start at a known state in which the user is comfortable in, they then go through a transition stage to reach a new and slightly unknown stage. What change management is concerned with is dealing with the transition stage so that when the final stage is reached some of the unknown and the risks associated with it are minimized and controlled. This is most important when creating processes that will deal with the technical side of change management; how are the changes to the Portal being tracked and controlled. There are a few standards and guidelines that have been established to help deal with change management from an information technology perspective. One set of guidelines that is becoming widely recognized is the ITIL guidelines. (ITIL stands for Information Technology Information Library.) These guidelines were originally developed by/for the British government and have since been used world-wide as a way of tracking and managing changes to information technology projects. (I do not want to be seen as favoring one method over another, but what I do want to stress is that your organization should seriously consider implementing a change management system to deal with the development effort associated with the Enterprise Portal.)

Change Management-People

85

When describing the reasons why an organization should implement a change management system for their IT development, it gives me a chance to say my favorite saying one more time. The focus of the Portal team should be about ensuring that the project is “Thinking big, starting small, and scaling fast”. This means that the Portal will follow an iterative development plan. The Portal will have limited functionality at the beginning, and with regular additions of functionality, will eventually include all of the functionality that is needed by its users in order to perform their job. In order to accomplish this, the Portal development team will continually be working on new functionality for the Portal. And because some functionality may take longer to implement than others, it can very easily become difficult for the Portal development team to keep track of which technology is to be included in which release. The fallback statement of “whatever we are working on now will be in the next release,” is no longer applicable as some pieces will take much longer to complete than others. Also, the development team needs to be able to keep track of the various versions of the Portal for back-up purposes and other recovery reasons. This is not to say that bringing in a code library that will version control your finished pieces of development effort will handle all of these issues. Like the previous discussion on change management, this discussion needs to focus in on the processes that need to be put in place to ensure that the results of the development effort produce Portal functionality of high quality and that the individual pieces of Portal functionality can be tracked and controlled. Once these processes have been created, getting the development team to follow them can be another challenge. For this reason, I have always tried to ensure that the development team participates in the creation of these processes. Most times, developers will welcome the implementation of change management techniques as they can clearly see the benefit to them and their work. However, care must be taken to ensure that the developers can still focus on what they do best, develop Portal functionality. They should not be forced to spend most of their time following processes and filling out forms. The processes and systems put in place should be as unobtrusive as possible and yet still accomplish the expected goals.

86

Portal Building

As well as focusing in on the development side of the Portal, change management techniques can also be applied to the Portal applications itself. One of the most common change management guidelines that should be established for the Portal solution itself has to deal with the version(s) of software that the organization should be using. The first guideline that should be developed should address the fact that the organization will have multiple Portal environments. There will usually be an environment where the production Portal lives, an environment where the developers build new Portal functionality, and sometimes even an environment that is used for final testing. By having multiple Portal environments in your organization there is a tendency that each of these environments could be running a different version of the same Portal software. This can cause problems when the developers are building functionality on one version of the software, it is being tested on another version of software, and it is being used by the organization’s population on yet another version of the Portal software. As you might guess, this can lead to errors that are very difficult to track down. The organization needs to ensure that all of the Portal environments are running the same version of the Portal software, and that when a Portal software update is needed/planned, a plan is put in place to upgrade all of the other environments as well. But this leads to the question of what version of the software should the organization be running? Most organizations have IT policies about when they should be upgrading to the latest release of software from the vendor. These policies and guidelines have been established to mitigate some very real business risks and should be followed. What the team should focus in on is creating a policy that will state that the organization will never be more than X number of releases behind the most current software release. (The X number is a value that needs to be determined by your organization and is influenced by a number of factors including: vendors support structures, your support team, and your development team’s skill sets.) One of the most important aspects of IT change management is to ensure that the project team has incorporated time into their project

Change Management-People

87

plan to ensure that they have a “stabilization period” for when they move the project code from the development environment to the staging environment, but most importantly it must be incorporated between the staging and production environments. Not only does this provide a chance for the administration and development teams to ensure that the code will not negatively affect the rest of the Portal infrastructure, but it can also act as a buffer time to ensure that the rest of the business processes (training, documentation, and communications) are also ready for the next phases of the project. This stabilization period can also be called a “lock down”, again the idea is to ensure that nothing is done to the code, or no users are accessing the code so that the administration team can ensure that there are no problems with the code when considering the entire Portal infrastructure. Another important aspect is that the project team needs to ensure that adequate user acceptance training and piloting are incorporated into the project plan. These tasks are usually planned for at the beginning of the project, but if the project starts to slip, these are the areas that are more than likely the first parts of the plan to be either reduced in time or even removed altogether. Although these parts of the project may not seem to provide direct and immediate benefits, especially if the entire project team ensures that their tasks are completed, but it does provide for longer term benefits. These benefits include ensuring that there are no errors in the code, allowing for fine tuning of the user experience, and ensuring that all of the individual components of the Portal fit together and interact the way that they were planned for. As mentioned earlier, the implementation and development of an Enterprise Portal will follow an iterative development. This means that new functionality will be added to the Portal at regularly scheduled intervals. From a change management perspective this needs to be taken into consideration to ensure that the development of the new functionality is planned to ensure that the functionality is added at the appropriate time. From a business perspective, the team needs to plan out each of the Portal releases to ensure that the new functionality is complementary to the Portal and also to ensure that the individual groups within the organization do not feel that the

88

Portal Building

Portal team is favoring a particular group by focusing the Portal’s functionality for their group. Also, by having the development team focus on providing specific pieces of functionality for the Portal, the Portal team needs to take a higher level perspective of the project. The team’s main concern should be to ensure that the functionality fits into the overall design of the Portal and to ensure that the functionality is able to integrate well with the other pieces of the Portal. Best practices can help set the processes for the team, however since Enterprise Portal projects are just beginning to become popular, best practices will become more prevalent as more and more projects complete their implementations.

10 Executive Sponsorship When dealing with a project that has the ability to touch every one of your organization’s business processes and people, having strong executive support and sponsorship becomes a necessity. As mentioned previously in this book, there are many occasions that others within your organization can try to either seize control of the project or try and block or even stop the project all together. This is when strong executive sponsorship is required to help prevent, and even remove some of these obstacles. Also, with great amount of change, comes a great amount of questions and uncertainty. At these times the people of the organization will be looking to the executives to answer their questions and to re-assure them that this change is necessary and will be a long term benefit for the organization. They will even be looking to the executives for answers to why this change is being done now and why to them. To answer these questions and to help re-assure the organization, the executives must all be visibly in favor of the project, and knowledgeable of the project to give clear and precise answers to any questions that they are asked. One of the first things that the project team should focus on is to try and get the executives to begin internalizing the Portal project. (I realize that this can be difficult at such an early phase of the project but it is possible by concentrating on the benefits the project can bring to the organization, especially with respect to changing an organization’s culture.) By internalizing the project, the team members and especially the executives of the organization, start to consider ways to incorporate the Portal into their everyday business routines. By bringing the Portal into the routines of the organization, it becomes a powerful tool for change, and not merely just another web-based application.

89

90

Portal Building

Another benefit of having the executives internalize the Portal project is that it starts to create an informal method of advertising and promotion for the project. This is achieved when the executives continue to examine the way things are being done and to question/discover how they may be done differently (or improved) through the use of an Enterprise Portal. Not only do these discussions start others to think of ways to incorporate the future Portal into their daily routines, but it also reinforces the belief that this is not another “fad” project that will fade away before it is implemented. Some of the people in the organization may have experienced other large scale projects that promised to change the organization only to have them get stuck in the planning and analysis stage for such a long period of time that when they are actually implemented, they are not able to achieve their benefits. (Another way that projects fail to achieve their goals could be caused by the project team only considering the technical side of the project and not focusing the required attention on the business side.) By having the executives of the company start to consider how to change the business processes, it serves as a reinforcement of the commitment of the organization to implement the project and to make the necessary process changes in order to get the maximum benefits from the project. The implementation of an Enterprise Portal project needs an executive that is committed to the project and is willing to visibly support it. (Actually the project should be having the support of the entire executive team and not just a single executive.) In order to properly implement an Enterprise Portal, the organization will need to make a number of changes to its business processes and in most cases even their “executive” processes. This takes strong and continued executive support. Without this support, the Portal project will not be able to achieve its benefits. (The only benefits it will achieve can be accomplished by other, much less expensive solutions.) If this is the case for your organization, the project team should stop the project and not continue. Recognizing the lack of executive support, especially if it happens after the project has begun can be difficult for the team as they will

Executive Sponsorship

91

be concentrating on the project itself. Also, even if they do recognize the lack of support, they may have invested so much time and effort into the project that they will try to complete the project anyways. This should be avoided. It is much better to stop the project, re-assess the level of support and commitment from the executives and determine the fate of the project. There will be no negative impact to the team if they stop the project for this reason, but there could be a negative impact if they proceed to implement the Portal and are then unable to meet the established success criteria. (One tactic is to change the success criteria to ensure that the project is a success, but if the team finds themselves doing this or even considering this, it is a good indication that they might want to consider stopping the project.) When discussing the Portal project with the organization’s executive team, it is very useful to discuss how the project can effect the organization from both a tactical and strategic point of view. The tactical way of looking at the project is concerned with creating a solution that will solve the immediate needs of the firm. This way, the project is expected to create immediate benefits to the firm. This sounds good however, since the project is focused on the immediate needs of the firm it is not able to deal with the long-term needs of the organization. Treating the project as a strategic solution will give up some of the short term benefits in order to focus on the long-term benefits. This allows the project to give up the need to produce immediate benefits in order to focus on creating sustained, long term benefits. The project team needs to know whether the executive team is leaning towards treating the project as either a strategic or tactical solution to the organization’s business challenges. This decision should be made early on in the project, as it will affect most of the team’s decisions; from choosing the Portal solution to determining which functionality gets added to the Portal first. Not only will this effect the team’s decisions but it will also have an impact on some of the associated projects, like the creation of the Portal’s communication and marketing strategies. The decision that the organization takes will be directly related to the reasons why your organization started the project in the first place. If the Portal project

92

Portal Building

came out of a need to provide clear communications to all of its employees, then thinking tactically should be considered, however if the Portal project was started to change the culture of the firm and to serve as the new backbone to support a number of new initiatives from across the organization, it would be better to shift the focus to the strategic side of things. Even if the organization is considering using the Portal as a tactical solution, I would strongly urge the team to consider keeping the notion of the Portal as a strategic solution in the back of their minds. This is so that in the future, the team can have the possibility to move the Portal from a tactical solution to a strategic one if the business requires it. One of the first things that the team must be aware of when dealing with the executive team is that they must be careful to ensure that the executive team is aware of the project, so that their expectations can be managed from the beginning, to ensure that they are realistic. This usually entails ensuring that all of the executives are aware of the iterative nature of the Portal project. When Portal solution vendors and / or consultants demonstrate their solution’s capabilities, it is usually done by demonstrating a very mature Portal. This is also similar to the executives getting a tour of an existing Portal that is currently in use in a different company. This can lead the executives to believe that their Portal will contain the same types of functionality and capabilities from the beginning. The Portal team must stress to them that the initial stages of the Portal will contain limited functionality, but it will be added to in a regular and controlled manner. This is important since the executive team will be responsible for “selling” the Portal concept to the entire organization and they need to be saying the same things as the Portal team. Also, it is important to ensure that the first phases of the Portal will meet the expectations of the executives as well as the organization. An old consulting saying works rather well in this situation, “It is far better to under promise and over deliver than it is to over promise and under deliver.” Care must be taken when the team is managing the expectations of the project to ensure that they are not giving the impression that this project will take many years to produce benefits for the organization. This can be accomplished by discussing the final vision for the Portal

Executive Sponsorship

93

and then providing the executive team with a plan on how the project will get to the final state. (I can use the saying “Think big, start small, and scale fast” here but I think by now that you should already be thinking that yourself.) Sometimes however, discussing the final vision of the project is not clear enough to the executives. If the project team is finding that describing the vision is not getting the point across, they should consider creating a “demo”. This demo can be in the form of a series of images or even some web pages that show some of the Portal’s future functionality. (These web pages can be done in such a way so that the functionality is “faked”, and as long as the presenter follows a pre-determined script, it will appear as if the Portal is fully functioning. This is also referred as “smoke and mirrors”.) One thing to keep in mind if the project team is creating a demo this early in the project is to be aware that some of the executives may think that the demo you are showing them will be the initial product. With this in mind they may be expecting all of the functionality that you demoed and the look and feel to be included in the actual Portal. The team must therefore take care to ensure that the functionality demoed is in fact possible, and that the graphical elements of the demo are in line with what actually may be in the final product. Even with taking this care, the team should make it clear to the executive team that the demo is for illustration purposes only and is meant to help explain the Portal project and to serve as a way to begin discussions concerning the project. Now that the executive team has become aware of how they can use the Portal in their daily routine, the Portal team should also spend some time describing to the executive team the benefits of a Portal when dealing with the organization’s customers/clients. The Portal team can provide some very high level examples of how the Portal can help the organization, but they should be focusing on providing the executives with the information and education so that they can come up with their own examples. This way the benefits are more real to the executives. By allowing the executive team to see the external side as well as the internal side it will strengthen their support of the entire project. Not only will they be able to see the Portal as a way to decrease internal costs and promote a change in

94

Portal Building

the organization’s culture from an internal perspective, but they will also see how it can generate revenue and increase client satisfaction as well. (An important aspect of an Enterprise Portal project is that not only can it help to decrease costs/increase revenue, which helps the short term goals of the project, but it can also help effect changes in the organization’s culture with respect to dealing with their internal employees, and their external clients/vendors. In fact, from a Portal perspective, everyone is a client of someone else, whether they are an employee of the organization or not.) Not only is it important for the project team to get the support of the executive team to help promote the Portal project, but they should also be committed to the project enough so that if there are any difficulties in the implementation phase (or any other phase) the executive team can be called upon to help straighten things out. This may be as simple as putting a name to an email or letter when required by a vendor or consulting company, or it may even require the executive team to stand up for the project in front of a budget committee, or even settle an ownership dispute. Since there is a great deal of change on the business side required in order to implement a project such as this, it is vital for the project team to realize that they have the support of the organization’s executives and that they will support them if needed. (All of this support does come with a price however. The Portal project team must be willingly to go the extra mile to ensure that the benefits that the executive team members are expecting and advocating to the rest of the organization, will actually happen. By proper planning and managing the expectations of the executives, this should be a very achievable goal for the project team.)

11 Forming The Team One of the aspects of a Portal implementation project that can most affect the outcome of the project has to deal with the creation of the project team itself. In most cases, the Portal implementation team will be made up of mostly technical personnel. However, since the implementation of an Enterprise Portal will involve mostly business processes and changes, the team should also contain a number of members that have a strong business background. Another aspect is that the team members should be familiar with the culture and processes of the organization. This will help the team recognize and deal with potential problems, as well as recognize potential areas in which the Portal can provide benefits. In some cases, organizations will hire external consultants or contractors to develop their Enterprise Portals. If the organization does not have the proper skills or experiences to accomplish the project, then the organization should look to outside sources. However, the team should be led by an internal person, and not by a consultant / contractor. This person should be familiar with the organization and knowledgeable about the cultural and hierarchy structures of the organization. If the organization is considering using external, or even internal resources, they should first look at the skill sets that will be required, and then match them to various team positions. (These individual positions will be dictated by the number of other focuses of the project that will need to be handled at the same time.) Once the positions have been determined, they can then be associated with individuals. From my perspective, an organization can use outside skill sets to augment the team by bringing in personnel to help bring experience about project management, and even experience with Portals (it is preferable to use people with generic Portal skills and not skills that are focused on a particular Portal product.)

95

96

Portal Building

One of the possible negative impacts of using a larger number of external resources in your Portal project is that the consultants might have a preconceived notion of what they believe your organization wants, or what they are comfortable building, which may not necessarily be what your organization needs. (This is especially relevant if you use a number of external resources from a single team.) Development teams may try to steer the development requirements of the Portal project into areas that they are more familiar with (or even to functionality that they have completed before). This should be resisted by the Portal project team. The project team, including the external team, must realize that the project team is there to serve the customer (the organization) and the customer should not be forced to change their requirements to meet the needs of the project team. This is not to say that the Portal team should not listen to the suggestions of the external team members, they may have gained valuable experience in their previous engagements that can be applied to this implementation. The challenge for the Portal project team is to make the decision of when to include the external team members’ suggestions and when not to. The main determination factor that can be used to help the project team in this regard is to always keep the goals and the vision of the project in mind. If the suggested change can help achieve those goals, it should be considered. This is also applicable to not only the development team, but to management consultants that will attempt to inform your team what functionality the Portal needs to include in order to be successful. This is usually mentioned as part of the description of their previous projects; however without proper information concerning the business needs of your organization, they are not in the position to make these comments. They can only say what they have done before, which may or may not be applicable to your organization. This leads to something that I refer to as “setting the agenda”. It should be made clear to all of the team (and even extended team) members, what the focus of the project and their contribution to the project will be. This is most easily done be creating a detailed set of roles and responsibilities for each team member at the beginning of the project. Not only can this help the team members by clearly

Forming The Team

97

defining what is expected of them, but it also helps in times when there is a conflict of who should be doing what. Documented roles & responsibilities can serve as something that can be referred to in the future to help clear up disputes. Without clear roles and responsibilities, the possibility of confusion around deliverables and assigning resources to deliverables can cause delays and even conflict in the project. One of the major responsibilities of the project team is to manage expectations of the project from the different user groups that make up the firm. The Portal team members should all be providing the same information so that the organization continually gets clear and consistent messages. One way to achieve this, is to separate out responsibilities so that a single person is responsible for a specific group of tasks; like development issues, infrastructure issues, content issues, and communication issues. (This is also helped by having a detailed and clear communications strategy and plan, which will be discussed in a later chapter.) Because of the iterative nature of the Portal, the initial releases will not include all of the functionality and content that the user community may be expecting. Without proper expectation management, the end users may have negative feelings about the Portal as they will not realize that the functionality that they are expecting will be included in future releases of the Portal. Most users are used to having the majority, if not all, of the functionality of an application included in the first release of an application. The Portal being almost the opposite of this thinking (limited functionality at first) may not be understood by the user groups. Proper management of customer expectations can go a long way in ensuring the success of the initial Portal releases, and the continued success of the future Portal releases. Another area of concern that can affect the outcome of the project centers around how the Portal project team is led. Since the Portal implementation deals with a great deal of process, people, and cultural changes, the Portal team should be “led” and not “managed”. The actual management of the project should be done at a lower level; the sub-teams need to have their individual tasks managed in

98

Portal Building

order to ensure that they are completed on time. However the Portal team needs to lead others when it comes to promoting the change and getting buy in from the project as a whole. There is an old saying; “lead others, manage yourself” that I believe holds true with respect to the Portal project. Each team member should be focusing in on managing themselves to ensure that their assigned tasks are accomplished on time, however they should be leading others to ensure that they stay motivated for the duration of the project. One aspect that should be kept in the mind of the project team is that Enterprise Portal implementations are usually very high profile projects and that they tend to attract a great deal of attention to themselves. This can lead to a number of political problems when members of other teams try to get either themselves or members from their own team onto the Portal project. This can be a negative thing if the only reason that they are trying to get themselves onto the team is to ensure that they can be associated with the success of the project, instead of being on the team because they have the appropriate and needed skills. The team needs to be kept small and with the required skill sets, and there should not be any other members on the team that cannot contribute to the project. It would be most beneficial if the team members can be completely dedicated to the project. (This is becoming very difficult in the current business environment as organizations try to get by with a reduced staffing level.) However, due to the importance of the Portal project on the organization, the organization should be making a commitment to the project by dedicating at least the top level of the project team. This can also be influenced by the possibility of creating some “turf wars” with other application owners within the firm. These application owners may want to take over the leadership of the project or even try to influence the team leadership. This can happen not only at the beginning of the project, but can happen throughout the entire life of the project. The most prevalent times that this can occur are usually at the major milestones of the project. At these times, announcements will be made to the firm advertising the successes and even the setbacks of the project. These are the times that the people who are looking to exert their influence over the project will start to surface. This can also happen during the

Forming The Team

99

education and acceptance stage of the project. The Portal team can do their job so well that ownership battles can result. Not only does the Portal team need to educate the user community, but they also need to educate, through expectation management, the other application owners to ensure that these battles are either reduced or avoided all together.

100

Portal Building

12 Budgets From the organization’s perspective, the biggest question surrounding an implementation of an Enterprise Portal usually revolves around money. How much is the project going to cost the firm and who is going to pay for it are questions that are asked immediately after the explanation of the project. This chapter will not only discuss the creation of the budget(s) for the project but will also discuss the financial issues that will arise from associated initiatives. The most costly portion of an Enterprise Portal implementation is not the purchasing of the software for the technical solution, but is the expense associated with implementing the solution and ensuring that the business processes are changed to fully utilize the Portal. The main reason for this misconception is that the purchase of the software solution is usually done in one lump sum while the implementation is done over a period of time, and therefore the costs are spread out. There are two main reasons why the change management portion of the implementation cost is usually the most expensive part of the Portal project. The first of these is due to the fact that Portal implementations are not small projects with respect to time durations. It takes a great deal of time to ensure that the business requirements are collected and that the proper tool is selected for the organization, but this cost is also appropriate in a wide variety of projects. What makes Portal projects unique is that they involve changing the business processes and procedures, and most involve changes to the organization’s culture. These types of changes cannot be made overnight and involve a great deal of coaching, education and persuasion in order to be successful. The second main reason deals with acquiring the expertise needed to implement the project. Implementing an Enterprise Portal is a very complex project that

101

102

Portal Building

requires the ability to manage a larger number of smaller projects, both technical and business related, as well as managing the expectations of the organization’s executive and general user community. One of the main differences between a Portal project and a typical software implementation is that the team needs to put in place processes to ensure that the implementation is never finished, as the Portal is meant to be a continuous iterative development. Another factor is that Enterprise Portals are relatively new solutions (as at the time of writing) and therefore not many individuals have the skill sets and experiences required to implement a Portal project. These two factors usually mean that an organization must rely heavily on external consultants to fill a large number of positions on the implementation team. As of the writing of this book, the demand for these skill sets is increasing at a greater rate than the people who are acquiring them. This means that the price for these individuals is very high. With a project such as an Enterprise Portal, implementations that have the capability of touching on a high percentage of the organization, most companies are not willing to fill the project with inexperienced team members. From a budgeting perspective the organization’s executives need to be prepared to create and support 2 separate budgets. The first budget will be focused on the actual implementation of the project while the second budget will focus on the Portal project after it is implemented. The implementation budget will need to consider the costs associated with the technical side of the project, like the purchasing and installation of the hardware and software. The development of the Portal and its functionality will usually need to be the responsibility of the Portal team in the initial stages. This means that its costs need to be covered as well. As the Portal evolves, the costs of implementing the Portal functionality will be moved to the business units. The Portal team usually covers the cost at the beginning of the project in order to demonstrate the benefits of the Portal to the organization. After these benefits have been demonstrated to the business units, it becomes much easier for the business units to assume the responsibility and the costs of their required functionality. This will be explained in more detail later in

Budgets

103

this chapter. Costs for the creation of the Portal hardware and software usually include costs for 3 separate environments, one for the production environment, one for the testing and staging environment, and the final one is for the development environment. Business related expenses are associated with items like collecting business requirements for the various departments, creating the various Portal business processes, educating and training the end users, and the project management techniques. Like the implementation budget, the ongoing Portal budget will need a technical aspect as well as a business side. The technical side of the budget will need to focus on the support of the hardware and software of the Portal. The support costs include the administration of the Portal as well as the training and use of the help desk personnel. The expenses related to the development of the Portal functionality will be reduced. The Portal team should have some of its members provide assistance to the business group’s application developers to ensure that their work can interface with the Portal. This expertise will need to be budgeted as an ongoing expense. The business side of the ongoing Portal budget will be focused around providing salaries for the individuals who will be continuing the evolution of the Portal. These individuals will be creating/refining the Portal standards and procedures, as well as continually going to the various departments within the organization to collect their business requirements. Another set of duties that should also be budgeted for but are usually either forgotten or not included due to budgetary constraints have to deal with handling Portal feedback and collecting metrics. Since the continued success of the Portal relies heavily on the input of its users, collecting, analyzing, and acting on its feedback is a very important job. Users must be made aware that their feedback is valuable and will be actioned if they are to continue to submit feedback to the team. This can only happen if there are processes put in place and when there are individuals who are assigned to the feedback process. Also, analyzing and reporting on the metrics of the Portal is an important role of the Portal team. Combining the information from the feedback with the metrics allows for a clear picture of the future of the Portal. Metrics can also be used to

104

Portal Building

provide feedback to the organization’s executive on Portal usage as well as giving an indication of the state of the organization’s infrastructure and how well the Portal is utilizing it. One of the items that was touched on earlier deals with the development of the individual pieces of functionality that will be accessible via the Portal and who will pay for the creation of this functionality. In the early stages of the Portal project (before it is released), the Portal team will usually need to fund part or all of this development. This is usually done to show the benefit of the Portal project to the firm, and since most business owners may not fully understand these benefits without being shown a Portal, they may be unwilling to fund the development of Portal functionality in the early stages. The Portal team needs to carefully select which functionality they will implement in the early stages to ensure that they are able to provide functionality that will benefit the largest number of users and that will also serve as an illustration to show what is possible in the future. Once the Portal is actually launched in your organization, the Portal team should start to switch the responsibility for the development (and funding) of the Portal functionality to the business owners. In fact, if a new application needs to be developed, or an existing application needs to be modified, this should be treated as a separate mini-project with its own budget, requirements, and project management techniques. What the Portal project team must be careful of is to ensure that they do not do too much of the development work themselves at the start of the project, as the business units may become accustomed to this which will make it harder to get them to take responsibility of the development and costs of the project in the future. (This discussion assumes that the costs for the development of the Portal functionality will eventually be borne by the individual business units that are making the requests, however your organization may elect to fund the Portal development differently. In some Portal implementations, the organization has elected to fund the development of Portal functionality that will benefit the organization as a whole, while requiring the individual business units to fund their individual functionality requests. What method is implemented for your

Budgets

105

organization will effect the required budgeting process for the Portal team.) It was mentioned earlier that some organizations (as of the writing of this book, it is most organizations), will rely on external consultants for providing assistance during the implementation stage of their Enterprise Portal project. External consultants are not inexpensive and this can greatly effect the Portal team’s budget during the implementation stage. Once the Portal has been released to the organization, the reliance on external consultants should be reduced and the team should be able to support and evolve the Portal using the internal staff of the organization. Because external consultants are expensive, the Portal team should ensure that they maximize the consultant’s time to ensure that they are dealing with the tasks that the Portal team cannot do themselves. For instance, one of the first tasks a consultant will perform during a Portal implementation project is to go around to various members of the organization to collect business requirements for the Portal. Not only does this provide the consultant with requirements for the Portal, but it also allows them to become familiar with your organization. However the Portal team should already be familiar with their organization. They should be able to quickly get the consultant up to speed on the organization and even do most of the business requirements collection, leaving the consultant to focus on the higher value tasks. Another aspect of dealing with consultants who assist in the implementation stage of the Portal deals with the iterative nature of the Portal. Since the Portal will be continually adding functionality and expanding, the Portal team should be taking steps to ensure that they are learning the required skills from the consultants, so that they are capable of handling the next releases of the Portal without (or with limited) external consultants assistance. There are usually two main methods to achieve this, and a combination of both methods tends to work best. The first method is to ensure that a member of the Portal team is always with the consultant so that they may learn by watching what is being done and how it is being done. This type of shadowing or mentoring is usually encouraged by the consultants in their initial meetings, and the Portal team should ensure that they take full advantage of the opportunities. The second aspect revolves

106

Portal Building

around the deliverables received from the consultants. Most times, the deliverables are in the form of a written report and presentation. From the Portal team’s perspective, the most important part of a consultant’s work is how they arrived at their written report. The Portal team should stress to the consultant that they would be expecting the consultant to provide templates and methodologies as well as a written report. These templates and methodologies, combined with the mentoring aspects of the consulting engagement should provide the Portal team with enough experience and knowledge to allow them to continue the evolution of the Portal with very little if not no external consulting experience.

13 The Project Plan The first section of this book has described the steps leading up to the selection of a technical Portal solution for your organization. From the beginning, all of the steps that the team has followed will have been documented in a project plan. Not only will this plan guide the team to the project selection goal, but it will also be used for the duration of the entire project, right up until the Portal is implemented, and beyond. This makes the project plan the most important document for the entire project. Different organizations have different standards and use different tools for tracking projects with project plans. Some organizations that have established project management departments and procedures will want the team to follow very specific guidelines for developing and approving their project plans. Other organizations may simply use a spreadsheet for their plans. What is important is that the project team uses a plan and that this plan is made available for other teams to follow as well. A project plan is basically a listing of all of the tasks that are required to be accomplished in order to implement the solution. For each task, a completion date and a person’s name that is responsible for it will be documented. This is the basic information that all project plans should contain. Each organization may require additional supplementary information as well. The project plan for an Enterprise Portal project can be very complicated and extensive depending on the experience of the team members and the information requirements of the project’s sponsors. If the implementation team is very experienced and is knowledgeable about the organization, the project plan can consist of a series of high level tasks or milestones. This level of project plan will provide the project sponsors with the dates that they can expect to see certain parts of the project completed by. The plan can be even more

107

108

Portal Building

detailed depending on the team and project sponsor requirements. One of the key items to realize is that this project, and its associated project plan, is not just focused on the technology issues, and therefore should spend a considerable amount of time focusing on the business process changes. One thing to mention about the business side of the project plan, is that it is very difficult to estimate the time required to change people’s attitudes and work processes. For this reason, the timelines included in the project plan should be a little on the strong side. For some larger project teams, it may be beneficial to create a number of smaller sub-plans that are focused on a specific area of the project implementation. These smaller, yet focused plans can then be given to the teams that are responsible for implementing that part of the project. All of these smaller plans can then be rolled up into a larger summary plan that can be used by the entire team. The purpose of the project plan is to communicate the goals of the project and to provide a way to communicate the key deliverables and their dates to all related parties. These dates can be used to plan when the next phase of the project will be completed but they can also be used by the team members to forecast when their next parts of the project should be ready. Not only can the project plan be used for tracking the dates of when the tasks should be completed, but it can also be used as a way to ensure that all of the associated tasks have been taken care of. There are so many smaller issues that relate to the implementation of an Enterprise Portal that it is quite easy to overlook some. If all of the tasks are recorded, it is very easy to track them and ensure that they are all completed. The remainder of this chapter will focus on the main sections of the project plan that the project team should consider including in their project plan. Again, this chapter should not be considered as the definitive answer as to what to include in a project plan, but it should be used as a guideline to give some indication of the types of things to include. The purpose of this chapter is to not instruct the team on how to develop a proper project plan. (Entire books have been devoted to

The Project Plan

109

this subject.) What I do want to include in this chapter are some of the milestones that the team should be looking for in a project plan that is focused on implementing an Enterprise Portal. These milestones will be briefly described below and should be included in the team’s project plans. How the team achieves these milestones, and the steps that they follow to achieve them, will be up to the Portal team to develop. As each organization and team will have their own preferred way of implementing projects, it should be up to the team to determine the best and most efficient way to complete this project as well. As the steps involved in selecting the Portal application software have already been discussed earlier, I will not include them in the following paragraphs, however since the project plan should be developed at the very beginning of the project, it should include these steps. The discussion has also been laid out close to the chronological order in which they should happen. Again, this is only a guide and the team should feel to change the order in which these things happen to suit the organization. Portal Team Creation The team that is selected to implement the Enterprise Portal should be comprised of members with a wide range of skill sets. They should have experience dealing with large scale projects, and they should also be familiar with the inner workings of the organization. If the organization is considering bringing in someone external with experience in implementing Enterprise Portals, I would recommend that they should not be placed in charge of the team by themselves. The team should be led, or co-led, by someone who has been with the organization for some time. This should give the individual some knowledge of how the organization works, what the pain points of the organization are, and what some of the potential obstacles to the project could be. Again, the important thing to realize with this type of project is that the change management, and business process parts of the project are the most important, and so are the related skill sets/experiences that are required to deal with these challenges. High level Portal Strategy The Portal team should document the high level goals of the Portal project. Issues that should be covered are why implement a Portal

110

Portal Building

and what are the benefits of the Portal project? This strategy should also explain how some of the objectives of the Portal project will be accomplish from a very high level. The Portal strategy should be focused on providing the project stakeholders with supporting information so that they can answer any questions that may be directed at them. The Portal strategy can also be used as content for communicating information about the Portal project to other user groups within the organization. Portal Release Strategy Implementing an Enterprise Portal within the organization should follow an iterative development plan. This will allow new functionality and content to be continually added to the Portal at regular intervals. The Portal team will need to create some policies and guidelines that can ensure that this continual addition of new functionality is handled in a controlled manner. This strategy should cover how the team will select what each Portal release will contain, not only from a functionality and content perspective, but also from a user group perspective. This is important so that the team and the rest of the organization will be aware of what each release will contain and will be able to focus on the current release functionality. Communication & Change Management Plan Because of the anticipated changes to business process and even the culture of the organization, emphasis should be placed on having a clear change management plan. This plan should be created by someone with change management experience. This is one area where organizations rely on consulting experience as most organizations do not have this type of expertise in-house. Also, because of all of these changes, the Portal needs to have a clear and detailed communication plan. This communication plan should cover all of the various aspects of the implementation, and it should also be targeted towards the various user groups that will be affected by the Portal. This will allow the project team members to create specific messages to these individual groups. Most organizations will have established marketing or communications departments. Members from these groups should be enlisted to help create this plan and strategy.

The Project Plan

111

Choosing Portal Representatives Once the Portal team has decided which groups will be focused on for bringing their functionality onto the Portal for the current release, they will need to start regular communications with that group in order to collect their business requirements and to inform them of the Portal processes that are applicable to them. This communication with the various groups is best done when the Portal team can use a single individual as a single point of contact. This person should be chosen by the group and should have the proper authority and insight into the group to ensure that the entire group’s needs are communicated to the Portal team. Most importantly however is that this individual needs to have the time set aside to ensure that they can spend enough time on the tasks that deal with Portal issues. Determining the Portal Layout The Portal team also needs to determine how the Portal will appear to its users. The design, or “look & feel” of the Portal needs to be defined before any development effort can be done. The design of the Portal should reflect the needs of the organization and can be assisted by using an outside design firm if the organization does not have the expertise. (An outside design firm can also be used if the Portal team is under time constraints.) Another part of the design that needs to be determined is the layout of the content and functionality of the Portal. This is sometimes referred to as the Information Architecture of the Portal. This will provide guidelines so that when new functionality and content are added to the Portal, there will be some direction as to where to put the functionality or content. While a number of organizations use outside expertise to help them create their information architecture, these consultants should be following the direction of a Portal team member. This is because the information architecture goals should be designed to help solve some of the Portal business goals, and a Portal team member should know these goals the best, especially over an outside consultant.

112

Portal Building

Business Requirements Documented At the end of this milestone the project team will have collected and have approved all of the business requirements for the release of the Portal. There are two different types of business requirements that the team should be collecting; departmental business requirements, and Portal core business requirements. The departmental business requirements are focused on bringing the specific functionality and applications that the various organizational groups and the Portal team determined they would focus on earlier. Within this type of requirements, the departments should look at functionality that their team needs to do their job, as well as the functionality that their team can provide the rest of the organization. The other type of business requirements can be labeled as Portal Core. These requirements are developed by the Portal team with the emphasis on functionality that will be used by all of the Portal users, for instance an Enterprise Search engine, email, and the organization’s phone book. All of these business requirements should be approved and prioritized by the various departments. Setting up the Portal Environments The technical environments that will be used by the development and production teams need to installed and configured. This part of the project will be the one that varies the most between organizations. This is because each organization will have their own standards for creating their computer environments, (some organizations might even outsource this task as well). Also, the amount of computer resources that the project needs is dependant on the Portal application that the project team has chosen, as well as the goals and objectives that the project team has set for the project. I advocate that the project team set up three separate environments for their Portal projects; although this will ultimately be decided by the project’s budget. The development environment is where all of the functionality will be developed. The staging environment can be used for many different uses; its primary purpose is to be used as a final testing environment, but it can also be used in the development environment to test the load balancing and failover capabilities, and it can also be used as a back-up for the production environment. The final environment is the production environment, where all of the

The Project Plan

113

applications and developed functionality will sit to be accessed by the users. Project Charters Signed Off A project charter is a project management tool that completely describes what will be developed for the individual Portal releases. This document will serve as a “legal document” that both the business and the development team can use as a guide to what will be included. From the development side, the development teams will use the project charters to tell them what types of work needs to be done. If it is not mentioned in the project charter they are not responsible for developing it. This also clearly tells the business teams what they will be getting in the Portal release. Everything that is mentioned in the document should be included in the final release of the Portal. These documents are signed off by both the development teams and the business teams; and if any changes are needed to the document these changes will also need to be approved by both parties. I advocate that a separate project charter be created for each department that is contributing business requirements for a particular release (this includes the core Portal business requirements as well). Development Work Completed At this stage all of the development work and its associated testing will have been completed. The business teams should be able to compare what development work has been done to what was specified in the project charters. The development work should also include a technical review of the work and to have it signed off by the lead developer(s). At this stage, all of the completed development work should be moved from the development environment and placed on the staging environment. Documentation Complete One of the parts of any technical project that usually gets overlooked is the documentation. This documentation should include the setup of the servers and the Portal applications on them, as well as the development effort surrounding the functionality in the Portal. The documentation should be centered around documenting the

114

Portal Building

development effort, so that other development teams can understand what was done. It should also include documentation that can form the user’s guide, as well as an administrator’s guide. The documentation should be written by both the development and the business teams to ensure that the targeted audiences can understand its contents. Testing Once the development work has been moved to the staging environment user testing can begin. This testing should be conducted by a number of different people, preferably by some of the members of the groups that will be targeted in the release and not just by the Portal team members themselves. Before any testing can begin, the Portal team should ensure that the functionality is located in the proper sections of the Portal. Also, use cases must be created that the testers will follow. As use cases are created directly from the business requirements, they can be used to ensure that each of the parts of the Portal are properly tested. Once the use cases have been approved they can be given to the testers so that they can start their testing. There should also be a standardized form for collecting the results and feedback from the testing phase. This will make the tabulation of the results much easier. Operations Team Created In order to ensure that the Portal is able to function properly in the production environment, an operations team must be established and trained. This team will ensure that the Portal remains operational and can also be used to respond to any of the feedback and questions that come their way. Tasks that need to be completed here include sizing the team, selecting the team members, providing them with training and ensuring that the team’s budget is in place. Move To Production Once all of the user testing is completed, the development effort can now be moved to the production environment. This move is usually done by the operations team and not by the development team. Before this happens the development team and the production teams need to sign off on the work. This sign off usually involves ensuring

The Project Plan

115

that the development effort and the documentation is approved. This move to production usually involves a period of time before anyone uses the new functionality in the production environment to ensure that it will not negatively affect the rest of the Portal environment. User Training Another item that needs to be addressed in the project plan is ensuring that all of the users have received training before they are expected to use the Portal. When most project teams think of training they usually think of end user training. For an Enterprise Portal, the training team can usually break down the end users into two different groups; casual users and power users. The power users are users in the group that is having their functional business requirements implemented in the Portal release. This group of people will need to have focused training on how to use the functionality that is being integrated into the Portal. The other group of users contain the casual users, who will only need an overview or awareness level training for the Portal. While end user training is important, it is not the only group of people that need to receive training. The Portal administration team, the developers, and the support team each need to receive training before the Portal is officially launched to the population. Portal Launch The launch of the Portal should be an exciting time for the project team and for the entire organization. The launch of the Portal should be preceded by an advertising blitz to increase the overall awareness to the organization. The project team should also have all of the support teams, (like the administration and the technical support teams) ready to go. A pilot or test run of the Portal can be a good way of not only giving the Portal one final shakedown but it also provides the support teams with a testing and assessment of their readiness as well. Training materials and all of the documentation should be completed as well. Processes like receiving end user Portal feedback also need to be in place.

116

Portal Building

Shut Down Of Existing Access Points Once the Portal has been launched in your organization, the Portal team needs to turn their attention to shutting down access to the applications that are now available from the Portal. Once an application is integrated into the Portal, all other previous ways of accessing the application need to be shut down. If they are not shut down, there will be a number of people who will continue to use the old ways of accessing the application and they will not switch to the Portal. By shutting off the other access points, it forces all of the application’s users to use the Portal. Also, if the Portal is replacing the organization’s intranet or website, they must be shut down as well. This is required for the same reasons as mentioned previously. The timing of when the particular application should be shut down and how it should be done should be considered on an application by application basis. As mentioned in previous chapters, the development and evolution of the Portal will follow an iterative development process. This will effect the development of the project plans. In order to keep the time between Portal releases (either major or minor) to a minimum, the Portal team will need to start thinking of the second release of the Portal even before they have launched the first release. What this entails is analogous to the team creating two project plans, one for each release, and then combining them into one project plan, with the plan for the second release offset from the first. This takes some great care in planning the project especially with respect to scheduling the various tasks. (This also requires some special attention and skills from the project team to be able to flip between two different Portal releases and not confuse them. This will be discussed further when the composition of the project team is discussed.) One important aspect of the Portal project is that it requires accurate data on its users in order to properly achieve its personalization functionality. This data will usually come from existing information sources from your organization, like your human resources department. In some organizations, this data may not be as accurate as required by the Portal project team. If this is the case, the team

The Project Plan

117

may need to adjust their project plan to take into consideration the correction or even collection of this required data. The project team should not be held responsible for ensuring that this data is accurate, that is the responsibility of the data owners. There are even some cases where the data owners may use the Portal project as the incentive to clean up their data. The Portal team should resist accepting this statement. The Portal project team’s goal is to ensure that the data they need to use is correct. If the existing data sources cannot meet these requirements, the Portal project team should be looking for other ways to get this information. This could even entail creating and managing the data themselves. The last item that needs to be discussed with respect to the project plan deals with collecting metrics and measurements on usage of the Portal. Not only are proper metrics concerning who is using the Portal and for what, important for establishing the Portal benefits, acceptance rates and supporting information for the project’s next budget, but it is also an indication of how successful the Portal actually is. In order to get a proper understanding of this, the project team needs to collect metrics on the “before Portal” situation of the organization. This means that the team needs to ensure that metrics are collected about the usage of the firm’s existing tools. This can usually be done by using a survey, but it does need to be included in the project plan to ensure that it gets done. You can define at least 3 sets of metrics to interpret; the business result/benefit, user acceptance as measured by usage statistics, and the support “burden” as measured by help-desk activity.

118

Portal Building

14 Project Charters & Secondary Documents There are a number of secondary project documents that the Portal team can utilize in their effort to implement a Portal in their organization. These secondary documents are focused on providing more detail into the project management aspects, enabling the team to better manage expectations, and to ensure that once implemented, the Portal will provide the most benefits to its users. The previous chapter discussed the importance of the overall project plan. This plan is used to provide a high level view of the entire project to the project team and the project sponsors by highlighting the major milestones. However, this overall project plan does not provide enough detail for the project team. What is needed is a number of more detailed and focused project plans. Each of these detailed plans should be created by their respective work stream as they will be the ones responsible for this specific component’s delivery. They should also have the most expertise related to the tasks that are needed to be completed and the time required to complete them. Therefore the project team should have a number of these more detailed project plans that they could work from. The overall project plan’s dates and milestones should be reflective of the contents of the detailed project plans. It is the responsibility of the overall project manager to not only ensure that the work streams are tracking to their respective project plans, but also to ensure that any changes to the sub project plans are reflected in the overall project plan. During the creation of these more detailed project plans, the work streams may need some direction. This can be made even more difficult if the work stream team is having trouble understanding the concept of a Portal, (which can happen during the early phases of the project when these plans are being created). What the overall project manager should do in order to reduce this possibility, is to carefully

119

120

Portal Building

explain what the high level tasks the work stream needs to complete are (which should be found in the overall project plan), and to illustrate how each work stream’s tasks fit into the overall plan and interact with the other work streams. This assurance is required to ensure that the work stream is involved in the project and that they feel that their work is an important part of the project. This is needed since during the early phases of the project, there may be some difficulty in seeing how all of the various work streams will come together in the end. This can be quite difficult for some people who are used to seeing the whole picture right from the beginning. For the Portal project, while the high level goal and vision can be clear from the beginning, what the Portal will look like and the functionality that it will contain may not be finalized until later in the project. If this begins to cause a problem with the work stream team members (and especially its work stream leader) the project manager should try to explain as much of the project as possible to the work stream leader. A project manager who is experienced with Portal implementations can make some assumptions about the organization and what they would be looking for. As long as the project manager qualifies his assumptions it should still provide the work streams with an idea of what the final Portal implementation may look like. Another type of secondary document that the project team should be developing during the implementation of the project is what is referred to as service level agreements (SLA). The most common of these documents are usually written between the IT department and the business owners of an application. These would clearly spell out the expected levels that the application needs to be “up and running”. The project team should be creating these documents with the organization’s information technology department that is responsible for maintaining the infrastructure. Not only should the SLA cover the availability of the infrastructure and the applications but the project team should also include acceptable levels for user response time of the application. Your information technology department may be reluctant to sign off on this requirement as there are many dependencies on this. (Since the Portal will be accessible from a browser, this requirement takes into consideration the organizations entire network infrastructure.) One way that some IT departments try to get around this is to get the business to sign off on a number of

Project Charters & Secondary Documents

121

other statistics, like through-put values, network utilization figures, etc. The only figure that the project team should focus on for this issue is the user response time. To an end user of the Portal, this is what they are most concerned about, and not the other statistics. Service level agreements in general, but especially with the IT departments will need to be created early on in the process so that the IT team will have enough time to prepare their employees with training and experience in order to meet these targets. The more time that the department has to prepare, the higher the levels of SLA can be achieved. Also, if they are unfamiliar with the application they may need time to investigate the product before they will even sign the agreement. One thing should be made clear about the SLA concerning the Portal application is that the business should remain strong on their requirements for both the user response time and the application up time values. If the IT department is unwilling to provide the required values, the project team should be prepared to look at other options, (like outsourcing the Portal application). A proper IT department should not being saying no to a service level target. If the IT department is uncomfortable with the target they should merely be placing a higher cost on achieving that level to the business. Not only should the project team create SLAs with the IT department for the care and feeding of the Portal application, but they should also be creating business focused SLAs as well. These types of SLAs deal with the processes surrounding the Portal. Some of the most important business SLAs focus on collecting Portal feedback and the help/support desk. Most large organizations have existing help/support desks that have been established to provide end user support for technical applications. During the initial stages of the Portal’s rollout, it may be beneficial from a cost perspective for the Portal team to leverage the existing help desk. Since the Portal will be a different way of accessing the applications, there may be times when the Portal does not work smoothly and end user support is needed. The easiest way for an end user to come up with an answer is for them to access a familiar process; calling an existing help desk. The SLA that the project team creates with the help desk should be focused from an end user perspective. It should cover areas such as

122

Portal Building

how long a user should wait before their call is answered, and the various stages of escalation that the call will go through if an answer cannot be immediately provided. As mentioned numerous times throughout this book, collecting user feedback is an important user component in ensuring that the Portal is able to continue to provide value to the organization. However most feedback mechanisms for applications are left to the last minute and not completely thought through. By focusing on creating SLAs for the Portal feedback process in the early stages of the project, a proper feedback mechanism and process can be created. The SLA for feedback should include topics such as responding to the user to inform them that their feedback submission was received and is being considered, and follow up with the user if their submission is being used or not. By incorporating feedback mechanisms that achieve certain levels of interaction with the users, it can assist in ensuring that the feedback process will be used more often. The other type of secondary documents that I will discuss here deal with the Portal after it has been implemented. The most important of these documents deals with how the Portal will deal with an unforeseen problem. This is usually called a disaster recovery document. The project team must plan for future problems that may take place. The plan should cover the area of how the Portal can be brought back into use as quickly as possible after a disaster occurs. Most disaster recovery plans are created for applications that contain mission critical information. While the Portal itself does not contain any information, it does provide the access to all of the other applications. If the Portal is to become the “new desktop” for the organization, and since it can be accessed from a web-browser from any internet connection, it is very important that the Portal remains accessible even when the office is closed. There are stories of disasters hitting offices, but since the employees can work from any internet connection, the organization’s clients did not notice any difference. So from a disaster recovery plan, it should not only focus on how to bring the Portal back into operation as quickly as possible, but it should also focus on ensuring that it remains operational. Most large organizations will have established procedures for creating disaster recovery plans, however they are usually created at a later

Project Charters & Secondary Documents

123

stage in the project. In order to truly be effective, they should be created or at the very least, be considered at the beginning stages of the project. The creation of the disaster recovery plan, and the other plans mentioned here, should utilize the existing resources of the organization. It is not expected that the project team would have the necessary skills to properly complete these plans, but they should be open to using the expertise from other parts of the organization. This discussion is not meant to include all of the secondary plans that the project team should be considering. The intent was to bring to light some of the plans and to get the team to start thinking in this direction. Once the team starts to concentrate on these types of plans, other plans will surface that need to be taken into consideration as well. Also, your organization may have a number of standard plans that need to be addressed both from a project management perspective and from an operations perspective. The main thing to take away from this discussion is that the project team needs to start thinking about these issues early on in the project. The longer the project team waits to discuss these issues, the more difficult it becomes to plan them properly.

124

Portal Building

15 Approving The Plan The best way to ensure that the Portal project is able to deliver its expected benefits on the agreed upon dates is to ensure that all of the Portal stakeholders are following a single project plan. The project plan will need to include all of the various sub-projects (and their respective plans), that are needed to complete the project. Not only should the plan include all of the tasks required but it should also include the dates that these tasks are to be completed by. The main project plan should contain the high-level tasks and milestones to be accomplished. This plan will be used by the project team leads and the project executives to track the project and ensure that the various work streams are all tracking properly. The tasks in this project plan should also include who is responsible for each particular task. (This adds accountability to the completion of the task.) The finer level tasks and detailed information that are required to complete all of the work streams should be recorded and tracked on separate project plans. These separate plans should even be completed by the leads for the work streams as they are the best people to have input into the tasks required. The overall project manager should have some input into the secondary plans in order to ensure that all of the tasks are included as well as to ensure that the dates in the sub-plans match up with the dates in the overall plan. (In fact, it is always better to develop the overall plan either in conjunction with the secondary plans or after the secondary plans are completed.) The development of the project plans should be accomplished following your organization’s established procedures. In fact, there are many ways to develop a project plan, almost as many ways as there are people developing them. One of the easiest and quickest ways of creating a project plan is to take the project plan from the previous time the organization did a similar project. However, an

125

126

Portal Building

Enterprise Portal implementation is usually only done once in an organization. Also, Enterprise Portal projects are very customized and their implementations are very unique to the organization. This leads to the fact that the project team will need to start the project plan from scratch. This is also a reason why most organizations consider bringing in outside consulting expertise to help them with the initial phases of their Portal implementations. When developing project plans, I prefer to work backwards on them. I start with the end goal since the launch date of the Portal will usually be predetermined, (at least it will be hinted at very seriously) by the project executive. From the end date I then begin to work backwards, including all of the tasks needed to complete the project. It then becomes very easy to determine if there is enough time to complete the project as the beginning date on the plan will need to be after the project has started. If this is not the case, the tasks can be re-examined (as we all know that most project managers will always ensure that there is some level of “padding” included in the plan). If there is no “padding” left to remove, then the date of the Portal launch will need to be revised. If the launch date has already been advertised to some of the organization’s executives, as this sometimes happens by an over zealous project sponsor, there are ways to accomplish this. One of the methods is to create a “pilot release” of the Portal. This pilot group can be used as an extended Portal testing phase, which means that it can be launched earlier than the “official” launch but it also allows for the Portal executive to have a Portal in front of users when they first mentioned it. One of the most important parts of creating the overall project plan is to have it approved by all of the project’s stakeholders by getting their sign-off on it. Not only will this serve to inform the stakeholders of the key dates associated with the plan, but it will also give them an indication of how the project will proceed and how the team plans to solicit the requirements that will directly influence the Portal’s functionality. By having their sign-off on the plan, they are approving of the project and being informed as well. (In order to get their sign-off, the team may need to create some additional material that will be presented to them as well as the plan.) Once the team has put their plan on paper, everyone will be expecting the team to

Approving The Plan

127

reach the dates mentioned in the plan. With projects as complicated as Enterprise Portal implementations, it is very difficult, especially to the inexperienced, to create a plan that the team can follow without changing. (Not every project plan will change to some extent, which is why good project managers try to build buffers into their plan, but when the team is dealing with changing people’s behaviors and even a company’s culture, it becomes very difficult to accurately predict timelines. For this reason, most project managers will be hesitant about sharing the project plan outside of the project team until later in the project when they can have an idea about the validity of the assumptions that were made in the beginning.) The project team can expect some resistance to the project and its plans from some members of the organization. Some of the resistance will come from people who will think that the project is too large to be successful or that the benefits will not be seen. There are two main methods that can be used to reduce the resistance to the project however it is better to be proactive and try to prevent the resistance from becoming too large in the first place. The first method is to stress the iterative nature of the project. This will help to break the project down into manageable phases that the organization can understand; not only with respect to milestones but also to the benefits that can be expected. Stressing the iterative nature of the Portal will also have a benefit for the team in that it will help with the managing of expectations of the Portal’s functionality and benefits. The other method is to put a demo in front of the Portal team’s executive as early as possible. To some people the concept of an Enterprise Portal may be a bit difficult to understand, but if they are able to see what the idea of the Portal is, by looking at a demo, it will be much easier for them to understand. However, there are some dangers associated with showing a demo too early in the project. If the demo is shown too early it may not look or have the same functionality that will be present in the actual finished product. There is also a good chance that once someone sees the demo of the Portal they will be excepting that that will be the finished product, even if the team mentions that it is only a demo; the images will stay in their minds. The team should wait until at least the design or look

128

Portal Building

and feel of the Portal has been determined and implemented before widely showing a demo to the organization. The functionality of the Portal can always be mocked up or faked for a demo but the look & feel of the Portal is either there or not. One temptation that is usually experienced by the project team is that the Portal vendors will be more than willing to demo their product at an early stage of the project. This demo is usually not customized for the organization. These demos can be very beneficial to the project team but should not be shown to the Portal executives or even the Portal stakeholders due to their lack of context to the organization.

Building

Building From a technical and business perspective, this is where the challenging portion of the project begins. Don’t get me wrong, this is also the most enjoyable phase of the project as you get to see the Enterprise Portal slowly come together from a design on paper into a workable business solution. All of the information skills and energy that have been building up from the beginning of the project get to be released in this phase. However, if this release is not controlled and directed, you may end up with an Enterprise Portal solution that does not resemble what the business is expecting at all. Hint: follow the plans that were created in the previous sections. This section deals with a number of technical topics. Again, these technical topics will be explained from a business perspective and will deal mostly with the items that the business user needs to consider. I will try not to bog you down with technical details, and will provide you with just enough technical information to ensure you can understand what is going on in this phase. Items that will be discussed are; setting up the various development environments and dealing with development issues, like scope creep. Another important topic that will be discussed is dealing with consultants. Many projects of this scope rely on consultants to help move the project along and to ensure the project is on the right track. While consultants can add value to the project, they can also eat up a great deal of the budgeted time and fiscal resources that could otherwise be spent on more important items. This chapter will discuss methods on how to ensure that you get the most out of your consultants, if you need them at all, and to ensure that they contribute the right information and benefits to the project. The other business issues that will be addressed in this section relate to the creation of the Enterprise Portal governance structure, implementing the communications plan, user training, and collecting measurements and metrics. All of these issues deal with ensuring that the “less glamorous” issues are dealt with and are not forgotten.

131

132

Portal Building

This is also the time to include other parties into the project on a regular basis, like the production support team. This will ensure that once the Enterprise Portal goes live, its success is all but guaranteed. This section’s milestone is a fully developed and stable Enterprise Portal residing in either the UAT or staging environment. Once all teams involved in the Enterprise Portal project (IT, business, support, etc) sign off on the project, it can be moved into the production environment and begun being used by its target audience.

16 Development Issues Even though this book has focused on the business aspects of implementing an Enterprise Portal; since the solution will involve the installation and configuration of software applications, there will be some technical aspects to consider. While this chapter is not meant to provide a detailed technical explanation of all of the development issues associated with this project, it is meant to provide an overview of the major development issues that the team needs to be aware of. Each of the development issues discussed in this chapter are explained from a business perspective with attention given to why the issue is important. Since an Enterprise Portal can be positioned as the organization’s new desktop, it needs to be available all the time. In fact since most organizations allow internet access to their Portals it needs to be available even when the rest of the organization is not. This creates a great emphasis on the disaster recovery issues for the Portal. (This issue also results in a snowball effect by causing other applications that are accessible through the Portal to have their availability increased as well.) In order to achieve these availability metrics, the organization will need to look at creating an instance outside of the organization. Most organizations may already have an external data center (either provided from a third party company or at one of the organization’s external sites) that can be used by the Portal. An organization does not need to implement a redundant external system for disaster recovery purposes at the initial Portal launch, but they should at the very least be considering and planning for the eventual inclusion of this. (Most organizations will plan and design for this, but will not implement it at the beginning due to financial reasons. They will then wait until the organization starts to receive benefits from the Portal before requesting the additional funds. By doing it this way the team is walking a fine line of waiting to get the buy in and hoping that a disaster does not occur before then.) Whatever

133

134

Portal Building

design is selected and used by the organization, it will need to be considered during the development of the Portal. Before a discussion regarding the development issues surrounding the disaster recovery instance can begin, the team should be consider creating the infrastructure for a duplicate Portal environment. As mentioned above, Enterprise Portals can be seen as a replacement to the desktop and therefore if they are not available to the organization's users, they cannot perform their tasks. For this reason they must be available all of the time. Not only is this important for disaster planning, but it is also important when dealing with regular maintenance and upgrades. If the organization only has a single instance of their Portal, maintenance must be done during periods of no usage; (if the organization is global in nature finding this time period may be difficult). Also, having only one instance of the Portal means that if there is a problem with the Portal, the users will be unable to access the Portal until the problem is fixed. For these reasons, most organizations design their Portals with what is referred to as redundancy. This means that they actually create two (or more) instances of the Portal; each of which is capable of handling the entire user base. This allows for one of the instances to be taken down for maintenance (or in case it comes down by itself) without the users being negatively effected. (In fact, if the redundancy is designed in such a way, and with enough financial resources, the users may not even realize what is happening.) The business needs and the project’s resources will dictate the level of redundancy for the project, which will result in the amount of interruptions that will be experienced by the end users. Some Portal software solutions are better at incorporating redundancy and failover (the ability of the Portal to recognize that one of the instances is not functioning and to direct the users to the functioning instance) than others, however as Portals become vital infrastructure at more and more organizations, software vendors are beginning to incorporate this functionality into their products. Depending on the Portal solution that the organization chooses, or even the redundancy issues provided by the business, the team may need to incorporate additional hardware and software into their Portal design. This will directly affect the Portal hardware budget,

Development Issues

135

and the team should rely on their information technology department (or external consultants) to ensure that everything is designed properly. (I am not advocating that the project team needs to de knowledgeable about the various ways of designing redundancy, but the Portal team does need to be aware of the requirements, what it means and who should be providing the assistance to achieve it.) The Portal team should be able to describe their redundancy requirements (in business speak) to the organization’s IT department (or equivalent). The IT department should then be able to provide the team with a number of different ways of achieving the redundancy and their associated costs. Most IT departments will provide organizations with a number of different scenarios in different cost ranges, it is then up to the business to select which scenario (and cost) that they are willing to accept; which the IT department will then implement. From a development perspective, this means that the Portal and the functionality included within it needs to have the ability to switch between instances if required. This will impact how developers plan to handle the temporary storage of information, to ensure that users will experience as little interruptions as possible when the switch between the Portal instances does occur. The actual development requirements will depend on how the system is architected and how well the Portal solution handles redundancy itself. Another factor that will affect the design of the Portal is the geographic layout of the organization. If the organization is concentrated in a single location, a single instance of a Portal can be sufficient. Or, if the organization is equally spread out from a geographic perspective, the team may want to consider a number of Portal instances. What makes this decision difficult is that most organizations fall somewhere in between the two extremes. From a financial perspective, and even an administration perspective, the common sense approach is to have one complete Portal infrastructure. This allows the organization to put their money into developing a properly sized infrastructure (including some room for expansion). This also allows the team to centralize support and administration staff. Since most Portals will be accessed via the internet, this also means that the organization only has to install and

136

Portal Building

pay for a single connection to the internet. This single pipe can then be sized according to the traffic being used. However, if the organization will have users that are concentrated in a number of centers throughout a country or even the world, the team may want to consider creating more than one Portal instance. If the team is unsure about the response times to access the Portal from the remote areas, it may be worth the organization’s time to investigate in creating a number of regional Portal instances to break up the amount of users that will be accessing a single, centralized Portal. Each regional instance can be sized to support the users in that region. However, regional Portal instances can also be incorporated into the overall disaster recovery plan. If one instance of the Portal goes down, the users can be redirected to the remaining Portal instances. From a regional perspective, the users from the faulty Portal instance can be redirected to an instance that is currently in non-business hours. This is so that the additional users will not negatively affect the performance of the other instances. One of the main topics that needs to be addressed when deciding on whether or not to create multiple Portal instances, is where the organization’s back-end applications are located. The Portal itself is just the access point that allows the users into the other backend applications of the organization. This means that one of the main factors that will dictate where the team puts regional Portal instances will be where the backend applications are located. If all of the applications are located in a centralized location, it does not make too much sense to create regional Portal instances, as the user will need to access the Portal and then travel back to the application. (This can be affected by regional internet links and the company’s internal linkages to the central location.) At the very least I will always recommend having an offsite location for the Portal in addition to the regular Portal instance. (This is mostly from a disaster recovery program perspective.) This additional Portal instance can be located at the disaster recovery facility, however if the team is planning on creating multiple Portal instances, the disaster recovery instances can be incorporated into the overall deployment plan.

Development Issues

137

The main factor that will determine the organization’s need, and even where to place the Portal instances, would be a result of user response time. IT departments may provide the Portal team with information regarding network utilization rates, capacity, and bandwidth. There numbers are great for reporting to technically oriented people, but from an end user perspective, the only thing that matters is users response time; “how long does it take for the Portal to do what I want it to do”. The goal of the design of the Portal infrastructure is to minimize the end user response time. All of these points revolve around the issue of insuring that the Portal is available at any time that the users want to access it. If the team is promoting the Portal as “the new desktop” for the organization, and are promoting the ability of users to access the Portal from outside of the office, (from home), users will take advantage of this freedom. If promoted properly, most organizations have experienced that their users come to expect the Portal to be available at all times. Some people are even beginning to refer to the Portal as “dial tone”. “Dial tone” refers to the belief that when users pick up a telephone receiver, they assume that the phone will work. (Some people do not even listen to for a dial tone, they immediately begin dialing as they assume that the dial tone is there.) People in organizations with mature Portals are also starting to expect the same kind of availability from their Portal. This will have consequences with respect to the Service Level Agreements that the project team has with their IT department. If they are looking at having the Portal approach 24/7 availability, they will need to have more than one instance of the Portal. This means that a combination of load-balancing/failover & disaster recovery techniques need to be deployed. In most organizations the IT department will have the experience and knowledge to tell the Portal team what is required in order to achieve the desired availability for the Portal. The Portal team therefore should only tell the IT department what the desired availability should be and let the IT department come back to them with the answer. The answer will usually contain a number of different options, each with the associated costs. This will allow the Portal team to see the costs of each option which will allow them to way the costs over the benefits for each. The Portal team, with

138

Portal Building

business approval, then picks an option for the IT department to implement. Other development issues that will now be discussed will focus on the actual Portal itself. The first design issue that should be considered revolves around the information architecture of the Portal. Information architecture can be described as how the content and applications are laid out on the Portal. A properly designed information architecture can improve the end user’s acceptance of the Portal and can even decrease the amount of training that users will require. Properly designed information architecture will allow the navigation and design of the Portal to be very intuitive and user friendly. Before the team can design the Portal’s information architecture, the team needs to have a defined vision for the project. As the team will not know what all of the functionality that will be included in the Portal will be; if they have done their homework and research, the team will have a solid understanding of what types of functionality and content they can expect to see in the Portal. Also, by looking at the objectives of the project, they can tailor the information architecture to help support them. Some of the Portal objectives that can be assisted by the information architecture are; employee self-service, a client or sales culture, and information sharing. Once the team is armed with this information they can then begin to create the Portal’s overall information architecture. This architecture will define the overall organization of the Portal and will serve to guide the direction of the Portal. Although the information architecture can be slightly modified as the Portal matures, its focus should be consistent throughout the Portal’s evolution. This consistency is vital to ensure that the end users remain familiar with the Portal. For these reasons, most organizations look for outside assistance when developing their Portal information architecture. Most good design firms will also offer information architecture services. The Portal team should take the time to consider from the start if they need external assistance. One of the benefits of using an external consultant is that the team can benefit from their experience by utilizing “best practices”. When selecting external help for the organization’s information

Development Issues

139

architecture, the team should be reviewing what the design firm has done for other organizations. This process in itself can provide ideas for the Portal team. Like always, the Portal team should be stressing that the external firm provide templates or other methodologies to the team so that once finished, the Portal team can use the templates to adjust the information architecture as the Portal evolves. The Portal team will also need to be able to describe the information architecture to other members of the firm as they will be asking where their content or functionality will be placed in the Portal. One of the key factors to keep in mind when developing a Portal information architecture is to keep the end user’s perspective in mind. The information architecture should be easily described so that when groups come to the Portal team with their business requirements, the Portal team will ensure that the functionality will be configured according to how it will be used, and not according to its owner. This has issues not only with the layout and navigation of the functionality and content, but also in the labeling of the Portal’s navigation and functionality; all of which should be directed by the information architecture. Another aspect of a Portal that the Portal team can take advantage of is that a Portal can effectively hide the back-end application from the end user. This is a point that not many Portal teams have really taken advantage of currently. By fully taking advantage of the Portal’s integration capabilities, the Portal team can create a series of interfaces that can utilize functionality from either a single back-end application or from a number of different ones. Previously, if a user wanted to access a specific piece of information or functionality, they had to log into a specific application, now with the Portal, the user logs into the Portal to access any type of content or functionality. By applying a common interface design to the Portal and its integrated applications, the individual back-end applications become less prominent to the end user, as everything has a common look and feel. (The main distinction of an application used to be the fact that the end user needed to supply a separate user id and password, but with single sign-on capabilities of the Portal, even that can be “hidden” from the end user.) From a user’s perspective, they do not

140

Portal Building

need to worry about whether the information that they are looking for is currently residing in multiple repositories, they just want to access it from a common spot. The Portal, with its integration capabilities can be linked with a number of different repositories through a single interface. That way the end user will think that they are searching a single repository. This example can even be taken to functionality as well as content. By separating out the interface from the functionality of the back-end applications, the overall design of the Portal becomes very important. The Portal design should be documented clearly so that other developers can use it as well. From a future perspective, this can even help out the development of future applications, as they can be made up of functionality / content from existing applications. Not only will the back-end applications be hidden from the end user, the business logic and the actual owner of the application can be hidden. Business logic can even be taken out of the back-end application and brought up a layer to cross multiple applications. Also, from the end user’s perspective, they do not need to know who the owner of the application is as long as they can access the information or functionality that they need. Change management issues also need to be taken into consideration for the design of the Portal. One of the biggest of these issues deals with the development process for the functionality of the Portal. As mentioned earlier, it is always recommended for an organization to have a production environment that is separate from their development environment. It is also recommended to have a third environment, a staging or testing environment that is placed in between the production and development environments. If all three environments are used, the development process would be as follows; new functionality is developed on the development environment. After the development is complete and the developers sign off on the code, the functionality is moved to the testing and staging environment. This is where the functionality is tested by a number of business users. It also allows the development team to test how the new functionality interacts with the rest of the existing Portal functionality. After all of the testing is completed and the

Development Issues

141

Portal team signs off on the functionality, it is then moved to the production environment. What I recommend is that the Portal team does not move individual pieces of functionality from the staging environment to the production environment. It is much better to bundle functionality into regularly scheduled releases. This is a much better way to handle change management issues from an end user perspective as they will not be constantly faced with new functionality on their Portal. I have discovered that having 2 major releases in a year, not only provides the development team with enough time to schedule their development effort, but it also allows the end users to become comfortable with the new functionality before more is introduced. (The organization needs to be careful not to utilize too many regular minor releases, just to get functionality out sooner.) The move from the staging environment to the production environment is a very critical process. Some organizations will even go through the expense of setting up a separate testing and staging environment. (Most organizations will simply create two separate environments on a single server to accomplish this.) What this allows the Portal team to do is to do all of the testing with the functionality and then once done, it can be moved to the staging environment where it can sit until the next scheduled release. This “cooling off” period is important as it allows all of the new functionality to be incorporated into a single Portal to see how they will interact with each other. (This staging environment is also important from a backup/disaster recovery point of view as the staging environment can also hold a snapshot of the production environment, so that in case anything happens to the production environment, the staging environment can be used to re-create the production environment, or can even temporarily replace the production environment if necessary.) Another change management issue that may affect the design of the Portal has to deal with the Portal application itself. Portal application vendors will continually release upgrades to their application software. These release upgrades are usually scheduled for regular intervals. The organization should create a policy that

142

Portal Building

will provide guidelines for when and how these new releases are incorporated into the production Portal. (Most organizations will already have policies regarding this issue for other applications, and the Portal team should examine these before making their own.) The policy will usually discuss how the release updates will be incorporated into the development, testing, and production environments. The most important aspect of this issue is for the organization to not fall too far behind in the number of release upgrades that they have not installed. Most vendors will only support a specific number of releases, and if the organization’s Portal is using a later version of the software, they will not be able to get support from the vendor. What most organizations will do is to create a policy that says that their application will not be more than x number of releases behind the latest release. (The most common number for x is usually 2-3, but this will depend on the skill set of the IT department, and on the track record of the Portal software vendor.) Even with this policy, there may be a number of occasions when a Portal release will need to be implemented on a much quicker timeline. This usually occurs when the Portal vendor releases a software upgrade to fix a security flaw or to repair a major problem with the software. Even though this will require a much faster implementation schedule, the team should follow the documented procedures, only with reduced timelines. What happens in some organizations, is that they will implement a major security “patch” directly on the production environment, however, not only will this reduce the team’s ability to test the patch, but it also means that the other Portal environments, (development and testing), will not match the production environment. If this is not corrected, the development teams, and even the testing teams will be focusing their efforts on a Portal that will not match the production environment. The last development issue that will be discussed is the one issue that tends to get overlooked the most. This issue centers on the various forms of documentation that must be completed before the Portal can be considered completed. In the rush and the excitement to produce a Portal version, documentation has a tendency to become forgotten about in order to meet the published timelines. This is especially

Development Issues

143

true when the Portal team is in the process of launching the first release of the Portal. During this time, there will also be a tendency to try and build in as much functionality as possible in order to truly show the benefits of a Portal to the entire firm. With this type of pressure on the development team, the first item to slip is usually documentation. When developing the overall project plan, make sure to include time for documentation, also, when preparing the development deliverables, the Portal team should make it clear that without the proper documentation completed, the development efforts will not be signed off. There are three main types of documentation, each type focused on a particular audience. The three types/audiences of Portal documentation are; development, administration, and end user. The development documentation is centered around all of the custom effort that went into producing the organization’s Portal. This type can be further broken down into two sub-types. The first sub-type deals with the custom effort that went into making the Portal application itself conform to the organization. The majority of this type of effort is focused around changing the look and feel of the “out-of-the-box” Portal into something that reflects the organization. This can also be applied to the navigation of the Portal as well. These changes are all focused on making the Portal as friendly and comfortable to the end user as possible. Other aspects of this type of development work involve integrating the Portal into the organization’s existing infrastructure, security, directory, etc. The other sub-type associated with development documentation is centered around the actual development effort for each individual piece of functionality, whether it deals with integrating a specific content repository or an application. Any changes to either the Portal or the backend application need to be documented. The purpose of this type of documentation is to provide a detailed description of what was done in order to produce the Portal. This documentation should include detailed descriptions within the actual development code as well. This is all done with the intent of ensuring that the entire process of building the organization’s Portal can be duplicated by another set of individuals. Not only does this

144

Portal Building

protect the organization’s investment in the project from an ongoing perspective, but it also allows new members to be brought into the development team and have them be able to quickly discover what was done in the past, in order to make improvements, correct errors, or merely extend what was previously done. The second type of development documentation is focused on the administration of the Portal. This is sometimes referred to as a subsection of the development documentation as it contains information on the changes done to the Portal, but I prefer to keep them separate as the administration documentation is a very important aspect. The focus on the administration documentation is to provide the administration team with the information they need to keep the Portal operational according to the agreed upon service levels. The administration of the Portal itself is relatively straight forward and because of this the documentation provided from the Portal software vendor can usually suffice, as long as the development customizations are included in it. However, since most Enterprise Portal projects usually involve a great deal of integration efforts, the administration team needs to ensure that all of the other interconnections are also operating properly. Since each organization is different from the next, these interconnections between the Portal and the various other applications and infrastructure pieces will be unique to each organization. As such, the documentation associated with ensuring that these interconnections are operating properly will also need to be customized. Not only will the administration team need to be supplied with information about how to ensure the Portal is operating properly, but there are also a number of regular tasks that they will need instructions on. Tasks like adding a new user to the Portal and changing the security of a user/functionality are just two examples. Each one of these tasks should be clearly documented for the administration team. The administration team should also be provided with information on how to install and configure the software. This is vital for upgrades and for rebuilding/expanding the Portal infrastructure.

Development Issues

145

The third type of documentation is for the Portal end user. End user documentation for the organization’s Portal is only one piece of an entire end user change management and communication plan. I do not want to give the impression that by simply providing the end user with documentation on the Portal it will ensure a successful acceptance of the Portal in the organization; it must be part of a complete plan. That being said, end user documentation is usually comprised of a number of different types of documentation, each with its own delivery mechanism, timing and purpose. The main overall purpose of the documentation is to ensure that the Portal users are comfortable in the Portal environment, and that they can answer the majority of their questions themselves. Some of this documentation should be provided to the end user in hard copy format so that they can have it handy. But the majority of the documentation should be provided via the Portal itself, this means that the documentation will be in a web format. Demos can also be included in this format to provide further instructions to the end user. The important part of the end user documentation is that it must be maintained to ensure that whenever new additions to the Portal are added, that this new functionality is added to the documentation. In fact the more complete the end user documentation is, the better it will be for the end users as well as the Portal support team and the organization’s help desk staff, as the more questions or issues that the end user is able to solve on their own, will equate to a reduced amount of calls that are being answered by your support team.

146

Portal Building

17 Project Charters Next to the overall project plan, the project charter is the most important project management tool available to the Portal project team. Project charters are created in the early stages of the project and are a result of the project management technique of ensuring that everything is documented. (This applies to more than just project charters, such as change orders, service level agreements, disaster recovery plans, etc.). One of the main purposes of the Portal project team is to ensure that the expectations of the organization and the project’s stakeholders are properly managed. This can only be done if all parties are clear concerning what they can expect from the individual releases of the Portal. Most organizations will have their own interpretation of what they consider should be included in a project charter, but speaking generally, a project charter contains detailed information concerning the release of the Portal. The project charter should contain the expected timeline for the Portal release, when the functionality contained in the document is expected to be completed as well as a brief description of the entire Portal release. The project charter should also explain in detail what functionality will be included in the Portal. (This is usually made easier if the project team has created use cases from their Portal business requirements. Each group of tasks in a use case document can be formed into a discrete item in the project charter.) A section can be included in the document that describes what is considered in scope for the release in question as well as a section of what is considered out of scope for the release. The content contained in this section should be detailed enough so that the business owners of the functionality will be clear about what to expect without having any questions or confusion. Most project teams will also try and create a single project charter for all of the functionality that will be included in the release of the

147

148

Portal Building

Portal. However, trying to describe all of the functionality in one document can lead to some important aspects being left out. It is recommended that the Portal team create a separate project charter for each major grouping of functionality that they are including in the release of the Portal. For instance, if the Portal project team is focusing on delivering functionality to 3 departments for the release of the Portal, then the team would create 3 separate project charters. (The team should also create a separate project charter if they are including Portal functionality that will not be owned by a specific department.) Once all of the project charters have been created, they should then be signed off by the business and the Portal development teams before any development work is started. The project team will use the project charter as a way to avoid scope creep for the release of the Portal. In most development projects, there is a tendency to make changes to the business requirements; most times caused by the business trying to include additional functionality in the project. This is true with Portal projects, especially for the first release of the project. Trying to launch a Portal to an organization is the most difficult part of the project as the project team is trying to collect business requirements from the organization, as well trying to ensure that the initial functionality contained within the Portal will provide benefits to the majority of the organization. This will lead to the Portal stakeholders and the project owners making functionality requests late into the project. The Portal team should expect this and from a pure project management perspective should discourage this. However, from the perspective of trying to ensure that the Portal gains acceptance within the firm, they should be prepared to accept these additions. Once the Portal is released to the organization, the Portal project team can follow proper project management techniques more closely. The project charter can be used as a road map for both the project team as well as the business owners of the Portal, or Portal functionality. Since all parties have signed off on the document, they will have agreed to its contents. (The process of getting them to sign off on the document will ensure that they are completely familiar with its contents and that it contains exactly what they are

Project Charters

149

expecting.) Although these documents are used to ensure that all parties are aware of what will be included in the Portal, they are most often used to settle disputes or to clarify misconceptions of the Portal release. The project charter can be considered as the document of reference and that whenever there is a disagreement between the various parties, the information contained within the document will be considered as the correct version. Because of this, any mutually agreed upon changes to the document, must follow a change process to ensure that various documents are updated. Any changes to the project charter must be mutually agreed upon by all parties before they can be accepted. Each change request should be fully scooped out by the Portal team to determine its impact on the resources and the overall time line. Most organizations will have an existing process set up for dealing with changes to project scope. As with all of the other cases, the Portal project team should take advantage of the organization’s existing processes. This information should then be brought to the requester’s attention and even the project sponsor/project owner’s attention, especially if it will negatively impact the project’s timeline. The ultimate decision for each of these change requests will rest with the project sponsor. If the change will not affect the project’s timelines, the decision can be made by the project team, as long as they keep the project sponsor informed of the change. Even with the change management process and the executive’s approval, the project team will need to make a decision on whether or not a change should even be considered. This decision will mainly be based on the timelines of the project and where in that timeline the project currently is. At some time, the project team will have to make the decision to not take any more changes for the current release, and to push all further changes to the next release of the Portal. By ensuring the functionality owners that their requirements and changes can be accommodated in the next releases of the Portal it may relieve some pressure on the team to get all of the changes into the first release of the Portal. Project charters are very useful when the Portal team is dealing with contributors to the Portal, but there may be cases where the Portal team requires content or services from other projects or teams. In this case the Portal team can request that the project charters be used,

150

Portal Building

but if this is not the standard case for the organization, the team may have trouble getting the other team to agree on the idea of using project charters. Whatever is chosen by the other project team, the Portal project team should ensure that all of their requirements are documented. The reasons for this have been explained throughout this chapter. One of the aspects of this documentation process should be the inclusion of service level agreements, if appropriate. Service level agreements are documents that contain information that specifies minimum levels of expected levels of service. Costs associated with these levels are usually included in this document so that the team can clearly see what their required levels of services will cost. These documents can also specify penalties in case these minimum levels are not met as well as ways to remedy the problem. This documentation process can be helped if the Portal team clearly knows what they require, and document this in a user requirements document. This document can then easily be transferred in the service level agreement as well as a project charter. The points raised in this chapter all deal with the importance of the Portal project team documenting everything that they are doing, especially when it relates to dealing with other teams or stakeholders. The idea of documenting everything as the team goes along with the project will also benefit the team when it comes time later on in the project to develop the various end-user documentation types. For most projects, the end user documentation is created at the end of the project and very little time is devoted to the process. If the project team works on the documentation throughout the project, the content can be integrated into the user documentation. The project team needs to create documentation for the following items, service levels agreements, disaster recovery plans, user requirements, and project charters. All of the points raised in this chapter all deal with one thing; being better able to manage the expectations of others. This expectation management is especially important during the very first release of the Portal. Since the idea of an Enterprise Portal may not have past into the mature phase, there are currently many different definitions of a Portal. (This book has tried to create a common definition, even though it may have inadvertently created another definition.) These

Project Charters

151

many different definitions will lead many of the people within the organization to expect a certain amount of functionality when the Portal is released. Even with a complete and thorough communications plan, without being able to see a Portal in front of them and to use it, some of the organization’s people may still hold onto their original beliefs. This can also be associated with the benefits, or expected benefits of the Portal. The organization and the Portal stakeholders must have a firm and clear understanding of the functionality that will be available in the first and early releases of the Portal. If they are expecting a certain amount of functionality that is not in the early releases of the Portal, they will have a negative impression of the Portal. The Portal team must ensure that they communicate to the organization the functionality that will be included in the Portal. This is a relatively straight forward thing, as it is just merely a reiteration of the functionality list for the Portal. What becomes more difficult for the Portal team is to translate the functionality into benefits for the organization. This can be helped by having a complete set of documented business requirements that spell out the individual benefits for each requirement. These benefits must be clearly communicated to the firm as well as the Portal’s functionality. It is recommended that the Portal team try to actually under sell the Portal to the firm. Then when the Portal is actually released to the firm, there will actually be more benefits than what they were expecting. This is much better than over selling the Portal and then not being able to deliver what on what was promised.

152

Portal Building

18 Setting Up The Infrastructure It was mentioned earlier that most organizations will need to create more than just a production environment for their Portal infrastructure. Like other large projects, an Enterprise Portal initiative will not only require the creation of a production environment, but also the creation of a development environment and a staging/testing environment. This chapter will briefly describe these three environments as well the benefits of each. This chapter will also discuss the business aspects of having these three environments and will not be focusing too much attention on the technical aspects of the environments. A Portal environment is a collection of pieces of computer hardware that when combined together will allow the Portal software application that the organization has chosen to run properly. The environment will consist of computer servers, network connections, switches, cables, etc. What the actual Portal environment consists of will vary from organization to organization and is dictated by a number of different factors. The first of these factors is the technical requirements of the Portal software that the organization has chosen. Failover and connectivity issues, both described earlier, can also affect the amount of hardware in the environments. Also, what the organization actually defines as what is included in their Portal will dictate the composition of the Portal environment. For instance, one organization may include an Enterprise search engine as part of their Portal project, and as such, will need to include the computer hardware associated to run the search engine as part of their Portal environment, while another organization that already has an existing Enterprise search engine would not need to include its associated hardware in their Portal environment. Below is a description of each of the three Portal environments, including their purpose and their benefits.

153

154

Portal Building

The most important Portal environment in the organization would be the production environment. It is this set-up that will be used by the employees, (and/or clients), on a daily basis. The employees will use this environment to access the tools and information that they require to do their jobs. As such, without this environment, the organization would not have a usable Portal. Because of this environment’s importance, the project team should be ensuring that the availability of this environment is meeting, and even exceeding, the project’s requirements. For this reason most organizations will create what is referred to as either a redundant environment, or a failover environment. What this means is that extra hardware is purchased and installed to create a duplicate Portal instance that is always available. Whenever something happens to the original Portal instance, the extra Portal instance is immediately and automatically brought into action so that the end user will not realize what has happened. Also, the Portal team should also create many Service Level Agreements with the organization’s infrastructure teams to document the expected availability of this environment. This environment is also the most complex of the Portal environments. The production Portal environment will have connections into all of the applications that are integrated into the Portal, as well as the organization’s authentication, authorization, and directory tools. Each one of these connections should also have an SLA established for it. (The stability of the Portal will only be as strong as the stability of the connections feeding it.) One of the major factors affecting the extent of the production environment is the size of the organization and the geographic dispersion of the expected Portal users. The number of Portal users will affect the size and quantity of the computer servers that are required to operate the Portal, while the geographic dispersion will have an impact on the performance of the servers. This may dictate that the organization create a number of different Portal instances spread throughout the geographic area of the firm. This way, the users can be spread out over a number of different Portal instances, each instance being relatively close to their access point. The next most common Portal environment is the development environment. Most organization’s development environments are

Setting Up The Infrastructure

155

usually smaller than their production & staging environments. This is because most Portal applications come with their own development environment that can be loaded on the individual developer’s workstations. This means that the developers will work on creating their pieces of functionality on their own machines and only move their work onto the development environment for testing purposes. As most organizations will have a number of developers creating individual pieces of functionality, there needs to be a single development environment that will allow all of the developers to test and share their work. For this reason, development environments tend to only be a single server (1 piece of hardware). Even if the organization’s production environment has multiple Portal environments for failover and load-balancing, the development environment does not necessarily need to have multiple environments as well. For financial reasons, most organizations only have a single development environment, as long as the testing/staging environment allows them to test how their piece of code works with the Portal’s failover functionality. The last environment that I will discuss is the staging/testing environment. This environment has many purposes, and needs to be flexible enough to handle all of its potential uses. The main purpose of this environment will be to conduct final user testing of all of the Portal functionality. Testing will have been done in the development environment by the developers, but that testing is usually focused on testing the individual pieces of the functionality. The testing that is done in the staging/testing environment is done by end users, and is focused more on a holistic point of view. This type of testing is conducted to ensure that the individual pieces of functionality all interact properly with the Portal and the other pieces of functionality. Usability is also conducted to ensure that the functionality not only does what it is supposed to do, but it does so in a user friendly manner. This testing process also allows the production team to become familiar with the code before it moves into production. Another functionality of this environment is to act as a “resting place” for the individual pieces of functionality. This allows the code to sit in the staging environment and run for a couple of days to ensure that the code is stable and will not crash. (Most testing is

156

Portal Building

done over a short period of time, however some problems with development work will not occur until some time has passed.) The final role that this environment usually fills is to act as a “backup” version for the production environment. As the staging environment is meant to closely resemble the production environment, (it is usually only a couple of weeks out of date), it can be used as a temporary production environment in the event that the full production environment fails. In order to accomplish all of these roles, the staging environment needs to closely resemble the organization’s production environment. This means that if the production Portal environment has fail-over incorporated into it, then the staging environment should have it as well. The staging environment should resemble the production environment as much as the project’s budget can allow. It usually is not an exact clone of the production environment, but if the organization has the resources, the project team should strive to get it as close as possible. Now that the different environments have been described, some time should be devoted to discuss change management issues that relate to the environments. Since the Portal will be following an iterative development process, additional features and functionality will continually be in different stages of development. This, combined with the three separate Portal environments can very easily lead to confusion and not having the Portal environments in sync with each other. For this reason, change management procedures are put in place. The organization may already have established procedures for change management. These existing procedures should be followed, or if necessary modified to suit the nature of the Portal project. If the organization does not have any existing change management procedures, it is strongly recommended that change management be implemented for this project at the very least. There are a number of organizations that promote best practices and standards, one of which is ITIL. The organization should choose the standards that best fit with the culture and existing practices of their organization. One of the main reasons for implementing a change management policy is to control the access to the various Portal environments. The development environment is usually controlled by the

Setting Up The Infrastructure

157

developers. This means that they get complete access to the environment and can make whatever changes and modifications that they need. This will allow them to develop their code and do whatever testing they require. The staging/testing environment should be controlled by the Project team. Once the development team has signed off on their development effort, they would notify the Project team, who would then accept the code. After this acceptance, the code changes are moved from the development environment to the staging environment. In this environment, the Project team is responsible for ensuring that all of the functionality is completely tested. Once this testing is completed, (and all of the other components of the release are completed, like documentation, training, etc) the production team can move the code from the staging environment to the production environment. This may seem like it is building a lot of red tape around the Portal release process, but it is quite necessary to ensure that all of the production Portal functionality is as stable as possible. In order for any functionality or other changes to be incorporated into the production Portal, it needs to pass at least one, and preferably two, testing phases. Also, by having no direct connection between the production environment and the development environment it removes the temptation to create a “quick fix” if a problem arises on the production Portal. If there is a problem with the new functionality on the production environment, the production Portal should be rolled back to the previous version. Most organizations will focus on leaving the functionality in the production environment and developing a quick fix for the problem, however this can lead to a number of untraceable problems. Other change management policies and procedures should be implemented; however this discussion was only to provide an example and benefit of change management that relates to the various Portal environments. Even though testing in the production environment has not been mentioned, there should still be some limited testing in the production environment before the functionality is widely released. This final round of testing should be done since the other testing environments will not be pointing to the production versions of the various back-end applications. In the development and staging

158

Portal Building

environments, Portal functionality will be pointing to development or staging versions of the various back-end applications. This final round of testing can be accomplished by utilizing the personalization functionality of the Portal application. This functionality can allow the new pieces of code to be presented to certain individuals on the production Portal for final testing before it is released to its entire audience. All of these environments will also have an impact on the design and implementation of the backup and disaster recovery procedures that will need to support the Portal. Focus is usually drawn to the production environments in order to ensure that the environment is able to produce the required up time as dictated by the service level agreements agreed to by the Portal team and the organization’s support team. However, some attention should be focused on the other environments as well. The staging environment should also be backed up regularly, especially if it will also serve as a temporary production environment in case of failover of the actual production environment. This back-up does not need to occur at the same intervals as the production environment, although it should be backed-up after any changes are done. One point to note on backups is that before any new changes are implemented into either the staging or production environment, a back-up should be done to capture the existing settings. This backup is useful in case the new changes cause problems in the environment and everything needs to be rolled back to the previous set up. The development environment is usually not covered by the organization’s support team. The development team is usually responsible for implementing their own system of backing up their work. A number of software applications are available for creating this environment specifically for development work. This chapter has focused on a number of technical issues that are not normally discussed in a business oriented text. However it was necessary to include this discussion so that the reader can understand these issues from a business perspective. The setting up of the environments will definitely effect the funding required for the project, both for the initial setup and for ongoing costs. If the reader is responsible for the project’s budget, they must be aware of what

Setting Up The Infrastructure

159

the money is being asked for. As mentioned before, proper control of new releases of functionality will affect the timing of the releases which will need to be incorporated into the project’s communications strategy. A final business related issue is the ability for the team to demo new functionality to the various audiences within the organization. The various environments can be used for demoing the functionality at various times in its development cycle, but the business should also understand the consequences of conducting a demo on a particular environment. (Demoing functionality on the development or staging environment may not run as smoothly as if it were on the production environment for a variety of different factors.)

160

Portal Building

19 Consultants In most cases, most organizations will not have the in-house expertise needed to complete an implementation of an Enterprise Portal. The needed skill sets required for implementing such a project are usually augmented by using external consultants. The skill sets required for the implementation part of the project are usually unique to that part of the project and cannot usually be transferred over to the next phases of the project. (This is more of the case when the organization is looking at people who are experts; however there are some people who are knowledgeable in their field and can help with the future phases of the project.) For this reason, most organizations are not looking to permanently hire the expertise and are willing to “rent” them. Before a decision on using consultants can be made, the project team needs to take a close look at the existing skills inventory of the organization. Consultants can be used to fill in these gaps. Another aspect of the project where consultants can help with concerns the timelines of the project. If the organization is looking to have a Portal implemented with very tight timelines, consultants can be used to increase the size of the team in order to reduce the project’s overall timeline. However, the most important point that the project team needs to discuss concerning the use of consultants deals with looking at the future. Issues dealing with how and by whom the Portal will be managed and supported can effect the decision to use consultants. These issues are very important, however the project team needs to take into consideration the organization’s willingness to use external consultants. Some organizations prefer to implement important projects themselves, using existing internal resources. (These resources can be augmented by hiring additional resources, either on a permanent or temporary basis.) Other organizations prefer to rely on expert consultants in order to ensure that the project is implemented properly and on time.

161

162

Portal Building

If your organization does decide to bring in external consultants to assist with the project, they should be used to augment the team, but not lead the team. They should be used as contributors to the team, not leaders of the team. External consultants may be experts in their particular field but they do not have the intimate knowledge of the organization that is required in the implementation of an Enterprise Portal. Therefore, the project management functions of the project should be done by someone from the organization. Some consulting companies prefer to lead or run the project themselves, and in most other projects this is acceptable, but not with an Enterprise Portal project. If there is considerable pressure to have the consultants take a leadership position, they can assume leadership positions for certain aspects of the project, like hardware setup, development, etc, but the overall project leadership should be the responsibility of someone from within the organization. Once the project team determines the expertise required of the consultants, and the size of the consulting team, it may be difficult to find people to match these requirements. The Enterprise Portal market is a relatively new market and as such, not many consulting teams have experience implementing Portals on an enterprise-wide scale. The organization should be looking for consultants who have actually implemented a similar Portal project before. Since Enterprise Portals is a very popular term, many companies are using it in their literature, however they may not have the experience that the organization requires. Some companies will use their experiences in website development or implementing large scale ERP projects and translate them into Enterprise Portal projects. The organization’s project team should be asking for specific examples and references of previous Portal projects. This is also helpful to determine if they have expertise in implementing Portal projects on a similar scale to what the organization is planning. Most consulting organizations, especially the larger ones, have a tendency of beginning a project with a pre-determined solution in mind. Most have an existing methodology that they use, and if they have done a number of Portal projects, they may be looking at doing something similar to what they are familiar with. Other consulting companies will even include in their methodology some time to

Consultants

163

spend getting to know the organization so that they can then build a proper Portal that meets the needs of the firm. This can all result in the consultants telling the organization what they need from a functionality perspective in their Portal in order for it to be successful. (Portal vendors have a tendency of doing this as well.) It should be noted that the people that best know the organization are people from the organization and not external consultants. Also, the project should be driven by the business needs of the organization and not by the Portal solution itself. If the project has followed the earlier steps mentioned in this book, the project team should already be aware of what the Portal project needs to achieve. It has been advocated that the time and money spent by consulting teams doing an analysis of the organization is money that can be spent in other areas. This work can and should be done by the internal members of the project team. They can discuss the results of their investigation with the consultants, but the consultants should not be doing this work. The internal team members know their organization better than external consultants and they should be able to do this work quicker and more accurately. In some projects, this work can be done by both consultants and internal team members if there is no previous internal experience in this area, but the work should be led by the internal members. By having the Portal team members do the majority of the data collection activities before the consultants come aboard, not only saves the project time and money, but it also demonstrates to the consultants that the team is knowledgeable and is dedicated to the successful completion of the project. This also gives the consultants the idea that the project team has already laid the ground work for the project. (Some consulting firms will prefer to handle the entire project, but the Portal team should make this clear during the consulting selection process.) As mentioned earlier in this document a number of times, the implementation of an Enterprise Portal project is an iterative process, with functionality being added to the Portal over a number of releases. When the organization brings consultants in to assist in the implementation of the project, the focus is usually only on the current release, and if the project team does not realizes this at an early stage they will need to continually bring the consulting team

164

Portal Building

back for future releases. One of the ways to avoid this continued expense is to require that the deliverables from the consulting team include templates and the methodologies that were used. Some consulting teams will be reluctant to do this, but if the organization has a good relationship with the consulting firm they should provide this. By having the templates and the methodologies that were used in the project, the Portal team members should be able to acquire the expertise to continue with the future releases of the Portal themselves. This is also another reason why members of the Portal team should be either leading or at least involved in the process being done by the consultants so that they can see first hand how the methodologies are implemented. They also have the opportunity to see what worked well and what methodologies need to be improved for the next releases of the Portal. The methodologies should not be specific to the current release of the Portal, but should be general enough so that they can be applied to future releases of the Portal. (Some minor modifications may be required to make the methodologies relevant to the specific details of the Portal release.) Another point to make is that the more clearer the vision of the Portal is to the Portal team, the better they can give direction to the consultants. This is especially true with respect to the look and feel of the Portal as well as the functionality to be included in it. (This exchange of information does not have to focus on the immediate release of the Portal, and in fact should focus on what the final vision would be.) If the consulting team has implemented a Portal before, they may try to have the organization’s Portal look and operate similar to ones that they have done before. It is the Portal team’s responsibility to ensure that the consultants are aware of what the organization is expecting. The consultants should be implementing what the organization wants, and not what they (the consultants) want. This is not to say that the Portal team should not take into consideration what they have done in the past, as there may be some experiences that can be used by the organization, however the final decision always rests with the Portal team and not the consultants.

Consultants

165

Once the consulting team is on board the project, the first thing that the Portal team should discuss with the consulting team is the end of the engagement. Focusing on the end of the engagement accomplishes a number of things. Firstly, it reinforces the fact that the project team is following timelines in a project plan and will not be expecting the engagement to go on for extended periods of time. This also leads to creating specific deliverables for the engagement that will clearly spell out what is expected, which greatly reduces chances for scope creep. More importantly though, the team needs to discuss the issues associated with knowledge transfer from the consultants to the Portal team and to the other members of the organization that will be involved in the operation of the Portal. This knowledge transfer should encompass a variety of different avenues. Members of the Portal team should always be present with the consulting team in order so that they can learn and acquire knowledge by participating and watching what is happening. It should also encompass the collection of documentation. This documentation can consist of existing manuals, white papers, and thought leadership. It should also include the documentation associated with the consultant’s deliverables. The project team should be insisting on documentation for every deliverable, even if the deliverable is focused on a presentation. Another benefit of focusing on the end goal is for the project team to put in place measures for when the consultants leave. Many times, project teams are busy focusing on the current tasks and allow the consultants to perform their tasks without considerations for how the project team will operate once the consultants have finished their engagement and are gone. This can take the form of placing certain team members to take over the consultant’s tasks or even supporting the products that the consultants have created. All of these things should be put in place before the consultants leave.

166

Portal Building

20 Bringing In Other Teams Considering the scope/vision of most Enterprise Portal implementations, the project team will need to rely on the expertise and knowledge of a number of different teams throughout the organization. This inter-team cooperation is vital to ensure that all of the various parts of the Portal that touch different pieces of the organization are implemented safely and securely. These different teams have a variety of different priorities on the project that will vary depending upon the organization make-up and on the implementation of the Portal project itself. This chapter will mention some of the teams that the project team may need to interact with on the Portal implementation and will serve to provide an indication of what is required and what should be looked out for. The one thing to remember when dealing with other team members is that clear roles and responsibilities should be defined and communicated from the beginning. This was mentioned in an early chapter dealing with the project team, but it applies equally as well when dealing with team members from other teams. If the Portal project team needs to rely on another separate team for any component of the Portal, whether it is a data feed or just support of the hardware, the project team should always insist on creating a service level agreement that is signed off by both parties. Most organizations have existing processes for creating service level agreements from a technical perspective, and these should be followed, but the project team should also consider creating SLAs for non-technical dependencies as well. For example, if part of the requirements for the Enterprise Portal is to have news submitted to the Portal on a daily basis, the team may consider creating an SLA between them and whoever will be providing the content. The project team should also ensure that they create SLAs for whenever they have a regular deliverable to another team. SLAs can take a variety of different forms and formats. For some cases, a written

167

168

Portal Building

document stating what is expected from both parties and penalties for lack of service is needed and required to be signed off by all parties involved. In other cases an email can serve as an SLA as long as it clearly states what is to be delivered. The main goal of the SLA is to clearly define what is to be delivered and for the project team to ensure that their expectations are clearly defined and communicated, whenever they have a deliverable dependency from another team. The extent that SLAs are used within the project will usually be dictated by the culture of the organization, but the general rule of thumb is to have an SLA if the team is depending on a regular delivery of either a service or product from another team. The extent that the Portal depends on this delivery will dictate the type of SLA that is used. One group or team that should be brought into the discussion is the team that deals with the operational support of the Portal once it is launched. This team, like the help desk team, or the production support team will need to be informed about the project early enough on in the project to ensure that they get the proper training required. They may also want to be operational for any piloting or testing that the team has scheduled. Not only will this allow for the Portal itself to be tested, but it will also allow for the testing of the help desk and operational staff. A team that is associated with this group is the learning and education team. If the organization has this team, they would be the ones who would be the primary group responsible for providing training for the Portal end users. In order to do this, they would need ample time to learn about the project and to create the various training packages and materials. The important part when dealing with these teams is to ensure that they are informed of the project and are a part of the project with enough time for them to be comfortable with their roles and responsibilities. From the development side of the project, the core Portal project team may, and probable will, be looking to other teams to help ensure that the integration of the Portal to other core systems within the firm is done properly. Most of these teams will be based in the production support area of the organization as they are responsible for ensuring that the various existing systems are operational. Not only will the project team be relying on their expertise with these

Bringing In Other Teams

169

systems, but these teams will also need to approve any changes or integration points that will be touching their systems. The teams that will need to be brought in to help with the infrastructure will vary depending on the systems that are existing in the organization and the scope of the Portal project itself. One way that some of the Portal implementation teams have structured themselves is that they have created a core team that serves as the high-level management of the project. This team is comprised of a number of people who would represent the various different workstreams that are required to implement the Portal. Each one of these team members would have the responsibility to ensure that they have the proper resources needed to ensure that their deliverables are met on time. It is these individuals who would be charged to ensure that they bring in the proper external team members to ensure that not only are their deliverables completed on time, but are also approved and are ready to be moved into the testing/production environment. With this type of team setup, the project team will be leveraging the existing expertise that already resides within the organization. With the extent or scope that most Portal teams are facing, and the timelines that they are expected to deliver within, they should not be looking at building up the expertise within the team. Their primary focus should either be using the skill sets that are found within individuals currently in the firm, or can be brought into the firm for the project. By using the expertise from other teams, it frees the core Portal team to concentrate on the high-level issues of the Portal project. It also has another benefit in that it provides exposure to a larger amount of people, who if treated right, can act as a groundlevel avenue of advertising the Portal (word of mouth). When dealing with expertise from different teams, a key focus should be on ensuring that the proper skills transfer is occurring. This is especially true when the project team brings in experts from outside of the firm. The Portal project team, and the workstream leaders should be responsible for ensuring that their team members have the proper skill sets to ensure that the project is maintained and expanded.

170

Portal Building

One aspect that should be focused on when dealing with a number of different teams for implementing the Portal occurs when there is more than one development team providing functionality for the Portal. If responsibilities and deliverables are not clearly defined in the beginning, there is a risk of some functionality being duplicated and others not being created at all. (The preferred way of doing this would be to have a single development team responsible for the Portal functionality. The single development team can “subcontract” out parts of their work to a number of different teams, however the overall management and responsibility would remain with a single team.) Clear processes will also need to be established for how the different teams will have their functionality tested and signed off. This will also include how the various pieces of functionality will be integrated with each other. Additional time for this integration and testing process may need to be added to the various project plans to accommodate this. Also, special tools can be purchased and used to ensure that the different teams are storing and using their code in a proper manner. Another set of teams that will need to be brought into the picture are the group of people who will be responsible for ensuring that the various sections of content throughout the Portal are populated with relevant and timely information. These teams will usually be associated with the groups that have provided business requirements for the functionality of the Portal. But in some cases the functionality will be created from an organization-wide demand. In this case, the project team should try and find the most appropriate team that can fulfill the content need. The teams should be made aware early on in the project of this requirement so that they can be prepared and trained for this added responsibility. (In some cases it may not be an added responsibility, only just a change to their existing ones.) In any case, some changes may need to be done to the team’s internal processes and procedures in order to supply content to the Portal. Depending on the amount of changes that are required to be done to the existing processes some advance time will be required to be provided to the team. The most important issue here is that the team takes ownership of the content for the specific piece of functionality and is committed to providing it in a timely manner.

Bringing In Other Teams

171

There may be a number of other technical and or infrastructure teams that the project team may need to deal with throughout the life span of the project, (especially during the implementation stage of the project). The project team should make all attempts to ensure that these teams are given enough advanced timing to ensure that they are capable of properly meeting their deliverables. Also, the project team should ensure that these teams are given the proper amount of information so that they can make informed decisions about their deliverables. This is usually the most difficult part of the project team’s job when dealing with other teams; deciding on the proper amount of information to provide to the various teams. Since the Portal project has the possibility to encompass a large percentage of the systems within the organization, (and they sometimes have the vision to touch all of the systems), the sheer amount of information can seem daunting to an outside team. The project team needs to discern the proper amount of the information that should be provided to each team. Not enough information could cause the external teams to decide on a certain path that may not fit into the overall goal of the project. Too much information could overwhelm the external teams to the point where they are spending all of their time analyzing the information. It has been found that the best approach is to provide the information to the teams in a number of “manageable chunks” and as the team is able to digest and understand each chunk, another can be provided. Also, the external team members will be a good judge of what types of information they require. Use them to help guide what should be provided to them. The initial pieces of information should be core to what they are required to deliver, and based of the external teams questions, that should direct what additional information is required.

172

Portal Building

21 Governance Structures One of the most important aspects of an Enterprise Portal implementation that often gets overlooked is the Portal’s governance structure. The Portal team is usually so involved in the implementation aspects of the project that they can sometimes delay the creation of the governance until the very end of the implementation. The governance structure of the Portal will define the groups within the organization that will be responsible for the operation and maintenance of the Portal. As the Portal will touch on many different groups throughout the firm, it may be necessary to have multiple layers of governance, (to be discussed in more detail later in this chapter.) Also, since the Portal involves changing the way people work, which usually leads to a culture change for the organization, the Portal will need some focused governance early on in its development stage. The important thing to realize is that the governance structure that is put in place for the organization should reflect the project’s business objectives but should also reflect how the organization operates, (or how it would like to operate if the Portal project will be used to help change this). External consultants can assist the project team in this respect by showing how other organizations have dealt with this issue, but in most cases it is best if the project team examines what has been done, and then takes what will fit into their organization and applies it to create their own governance structure. The Portal’s governance structure should not be focused on controlling the Portal, but should be focused on helping the Portal grow and mature. As the Portal’s functionality will be mostly dictated by the business requirements from the individual groups within the firm, and that the applications that are presented through the Portal will not be owned by the Portal but by the business groups themselves, there is actually very little within the Portal for the

173

174

Portal Building

governance structure to actually control. Instead, the governance structure should be focused on encouraging the use and expansion of the Portal. One author has previously written that a proper Portal governance structure should resemble that of a gardener. The gardener is not able to completely control their garden, however they can help shape the final result by planting the seeds, and encouraging growth by showing attention to the garden and helping determine which should grow in the garden by weeding out the unwanted parts. The focus of the gardener is to let things happen naturally while striving to guide the growth. The Portal governance structure should be set up the same way. Allowing the Portal to develop naturally with the firm, while focusing the efforts on helping to encourage and guide its growth. The overall governance structure of the Portal will usually involve the combination of two types of structures; one for the management of the technical side of the Portal, and another for the business side of the Portal. The governance of the technical aspects of the Portal project involves the care and feeding of the various pieces of the computer hardware and network infrastructure that is involved in ensuring that the Portal remains operational. Most organizations will have existing processes, procedures, and responsibilities associated with the care and maintenance of the information technology (IT) infrastructure. These established methodologies should be respected when the governance structures are created for the Portal project. In fact, it is helpful for a member of the existing IT department (or whoever is responsible for the maintenance of your infrastructure) to help create the governance structure, as it will usually need to be approved by that group before the hardware is moved into production. Creating the governance structure for the business side of the project is usually more complicated as there may be no established policies that can be used as a reference. The business side of the project will need to focus on the overall management of the project, which includes the overseeing of the technical aspects as well. Firm-wide issues like content management can also be placed in the responsibility of the Portal team.

Governance Structures

175

Not only will the governance structure help nurture the development of the Portal but it will also be involved in the creation of a number of policies that will be influential in ensuring the Portal remains a key tool for the organization. The business side of the governance structure will also need to consider how and more importantly who will participate in the governance of the Portal. A brand new team can be created to manage the Portal. This new team will need to be established within the organization with responsibilities and reporting structures. What can also be done is to create a virtual team comprised of members from existing groups within the organization, (usually comprised of the project’s stakeholders). The biggest factor that will guide this decision will be the culture of the organization and even the project’s sponsor. While the project team can develop the organizational plan and the rationale behind its development, they are really only making a recommendation. The ultimate decision for determining the governance structure for the Portal project will reside with the project’s sponsor or owner. For this reason, the project sponsor should be made aware of the importance of the governance structure early on in the project so that they can begin to help shape and be able to actively participate in the governance discussion. The Portal project may actually go through a number of different governance structures in its lifetime, and this is to be expected. During the implementation phase of the Portal project, the governance structure may be focused entirely around the project team. Once the Portal has been implemented the governance structure will then move to an operations focus. Also, governance structures can and should evolve over time, especially when dealing with an Enterprise Portal. As the focus of the governance structure with a Portal is to nurture the development of the Portal, as the Portal (and even the organization) changes in its growth, so too must the governance structure. Even with the changes to the project and the governance structure, the firm should strive to include some consistency in the governance structure. This consistency could be centered around a core group of people, or even a core set of values or beliefs. Whatever it is, this consistency will permit the transitions to be done in a very smooth and less traumatic fashion. Also, the

176

Portal Building

transitions should be done gradually, especially once the Portal is in operation. This allows for a less dramatic change for the users and for the team that must maintain and support the Portal application. One of the main goals in creating a Portal governance structure is to clearly define the roles and responsibilities; not only for the Portal team and the associated stakeholders but for everyone involved in the project, right down to the end users. During the project’s implementation stage, the roles and responsibilities are usually well know, if each member is clear on what is required of them to accomplish in order to complete the project. However, some issues can arise if the roles and responsibilities are not clear in this stage. It is a good idea to clearly document and review with the team everyone’s roles and responsibilities at the start of the implementation stage. Problems and issues can arise without this step as some team members may have different ideas of what is expected of them, and if not dealt with early on, this could lead to team member issues as well as not completing some of the required tasks. Similar issues can arise once the Portal project moves from implementation into production except that the project now has more teams working on the project, some of which may not be as intimately involved in the project as the members were in the implementation stage. During the development stage, the closeness of the project team members can be taken advantage of when dealing with cloudy and overlapping roles and responsibilities. When the project moves to the implementation stage of the project, this becomes less possible. This is where all of the roles and responsibilities need to be clearly documented and discussed with the various groups. Like the governance structure, the roles and responsibilities of the various groups associated with the project can also evolve over time. The initial roles and responsibilities can be created based on the organization’s experience dealing with other large-scale projects. (If the organization does not feel comfortable with this, they can rely on external expertise to help establish the first version of the Portal roles and responsibilities.) However, once the Portal is implemented and

Governance Structures

177

begins to be used on a regular basis, the various roles and responsibilities of the different teams should be revisited. The Portal team should ensure that all of the various roles have been clearly defined and documented at the earliest part of the project as possible. Once each of the roles has their responsibilities documented, as each position is filled with an individual, this document can be used to clearly outline what is expected of that individual for that particular role. This will help to ensure that each person will know what they are getting into when they accept the role. This also requires that the responsibilities are clearly defined in the document with enough detail to ensure that the document is useful. When this document is being written, the author, or author(s) should keep in mind the intended audience. By knowing that one of the main uses for this document will be to explain the position to new team members, they should put themselves in the new team member’s role to ensure that the detail is at a sufficient level. Once the document has been finalized, it should be stored using proper document management procedures. This means that any future changes to the document will need to go through an approval process before the document can be changed. Although, this document should be completed for each role, before team members are selected for the project, in most cases this is simply not done. Usually, due to time constraints, this document is created once people have already assumed the positions. If this is the case, the Portal team should work closely with the individual when creating the responsibilities for the position. One thing to note is that the responsibilities should be designed for the role on the team and not the particular individual who is currently filling the position. Outside expertise, will usually be needed to help determine the appropriate roles and responsibilities. This can be achieved by researching best practices and even by utilizing external consultants with experience with Portal implementation projects. One of the key aspects to consider when developing the governance structure of the Portal is to rely on “single points of contact” who act as key interface points to the project team. This single individual would be the prime, if not the only, access point to the rest of the Portal team. One of the interfaces where a single point of contact is

178

Portal Building

most useful is where the Portal team deals with the business. Depending on the size of the organization, and the roll-out schedule for the project, a single person should be responsible for interfacing with the business. This can also be established within the Portal team as well. In most project teams, the business side of the project team would interface with the technical side of the team (the developers) by talking to a single technical lead. The Portal team should also recommend to the various business groups within the organization that the individual groups should elect a single individual to represent their group as well. (A back-up should also be chosen.) There are many benefits to setting up this structure. The main one being that the project team always knows who to talk to whenever they have a question. This also creates a single point of responsibility for deliverables. This allows for a consistent message to be sent out from the Portal team if there is always a single person doing the communications. When the business sets this structure up as well, it puts in place a vetting process so that any business requirements that are brought to the Portal team will first be approved or filtered by the business point of contact. This will avoid the Portal team from having to handle business requirements from a wide variety of business users, especially when the business group will need to find resources for the development effort. This also benefits the Portal developers as well, as once a business requirement is brought to the attention of the Portal team, and the proper business requirements have been collected, the Portal business contact will meet with the Portal technical lead to discuss the Portal requirements with respect to resource and timing issues. This provides clear lines of authority and accountability for the entire organization; the Portal business contact will not accept any business requirements accept from the business Portal contacts, and the Portal developers will not begin any development effort unless instructed from the technical lead. Since most organizations that are currently implementing Enterprise Portals tend to be large organizations with many different locations/departments, there will be a tendency to create a structure to govern the Portal that has many different layers or levels. The

Governance Structures

179

amount of layers or levels will be dictated by what is common at the particular organization, however the Portal team should try to ensure that the organization structure is created that serves the project and not the individuals who would like to be associated with the project. The Portal project team should entail only what is the bare minimum required to ensure that the Portal effectively serves the organization. What is important with respect to this point is that as the layers of organization increase, there is an increase importance put on clearly defining the roles and responsibilities. By having clearly defined roles, not only for individuals but for each layer, it will clearly define what is expected of each layer. This process can also be used for justifying whether or not a position, or even an entire governance layer is needed. If, when creating the responsibilities document, the team cannot determine what a particular layer should be doing, it should not be implemented. Another aspect of the project that will need to have its roles and responsibilities clearly defined has to deal with the various Portal technical environments that have been implemented in the organization. If the organization has implemented three environments, (as was discussed previously) then each of the environments needs to have clear owners and each owner needs to have their responsibilities defined. Most often, the organization will already have established roles and responsibilities when it comes to the various technical environments for firm-wide applications, but these need to be documented and shown to the team members to get all of their sign-off. In most organizations, the production support team will have full control over the production environment. The development environment is controlled and maintained by the Portal development team. The staging / UAT environment can be handled by a number of different teams, however it has been found that the best situation is when control of this environment is given to the Portal business team. By having clear roles for each of the environments, it ensures that the development effort of the Portal that is moved into production is thoroughly tested and signed off by all parties. This ensures that the final Portal product that the end user sees is of the highest quality possible.

180

Portal Building

22 Communication Plans Ensuring that all of the various groups within the organization are aware of the Portal and are fully educated as to what to expect when it arrives is best managed by the Portal project’s communication plan. This plan should encompass all of the different avenues of communicating about the project to the organization. Since most organizations will either have a separate communications/marketing department, or at the very least some individuals with this type of experience, this part of the project can usually be handled by internal resources. In fact, it is recommended that internal resources be utilized as much as possible since they will be the ones who are most knowledgeable as to what are the most effective communication channels to each the various audiences within the organization. This group should be agreeable to trying new techniques, as the Portal project will likely require new techniques as it may be a very different project as to what the communications team is used to. Once the communications plan has been created, it will need to be signed off by the Portal project owners. Any changes that occur to the project, will cause the communications team to go back to the communications plan to see if any revisions need to be done. Each of these revisions should be signed off as well. Not all changes that affect the project will result in a change to the communications plan. The communications plan should also be examined regularly to ensure that the key messages and actions are still relevant and are the delivered in the most effective manner. This is especially true in long term projects, as communication mechanisms and processes change over time. One of the main differences of this project that will need to be incorporated into the communications plan is the fact that the Portal project will follow an iterative development plan. This will result in a continued and regularly scheduled number of releases that will

181

182

Portal Building

need to be communicated to the users. This will require the communications plan to be developed in such a way so it can be reused for each subsequent Portal release. This also results in incorporating the Portal as a communication vehicle for future releases. Due to the iterative nature of the project itself, it has been found that by breaking the end user communications into four separate phases, the project team is able to effectively target the messages to the needs of users for each perspective release. This effectively structures the communication strategy for the Portal around the four phases of the Portal lifecycle itself. For the purpose of the communication strategy, these phases have been labelled, Awareness, Understanding, Deployment, and Sustainment. For each of these phases of the project, impacted user groups will need to be identified and messages developed to specifically address their communication needs. These specific communication needs will directly affect the timing of the message delivery. The first phase of the communications strategy is the Awareness phase. In this phase the focus is on providing introductory information to the targeted audiences, (users are provided with their first communications about the project). Not much detail is provided in this phase as it is used primarily to give users a “heads up” about what will be happening in the near future. The level of detail will be adjusted due to the individual targeted audience’s understanding of the project and their “willingness to embrace change”. The second phase of the communications strategy is the Understanding phase. This phase builds on what was done in the previous phase and is focused on providing more detailed information to the targeted audiences. This is the phase where the end users start to get detailed information about the project and how it will directly affect them. The frequency of the messages is increased as is the number of different types of messages. This phase will also focus more on the specific target groups and tailor what is delivered to the end user depending on what group they are in.

Communication Plans

183

The third phase of the communications strategy is the Deployment phase. This phase begins just before the launch of the project and is focused on preparing the users for the project’s implementation. Again, frequency of the messages is increased as are the methods used to reach the individuals. This phase will also contain messages from other groups that will be involved in the project’s deployment (like the learning and education group for end user training). The final phase of the communications strategy is the Sustainment phase. This phase is focused on ensuring that the energy and enthusiasm associated with the launch of the project is maintained. The focus here switches from being a pushing out of information to bringing in information, (user feedback). It can be used to talk about the success of the project as well as to describe how the pitfalls of the project are being dealt with. Another function of this phase is to provide a sense of the new functionality that is scheduled for the future. (In effect this begins the awareness phase of the next release project.) What is important with this type of classification of the communication strategy is that the project team must also define audiences for each of the various groups that will be affected by the Portal project. Each of these audiences will have their own requirements for messaging with respect to the types of message delivery, technical experience, message focus, and even wording. A good rule of thumb when developing communication audiences is to determine if all of the members of a group can receive the same message or would a separate message be of more benefit. Now that the audiences have been created, the team can start working on developing the key messages for each group at each of the four phases of the communication strategy. It is not necessary to finalize the messages with complete wording at this time, it is only necessary to document the key concepts or ideas that you would like to present to them. These messages should also be generic enough so that they can be used in future Portal releases. This will not be applicable for the very first project messages, as the initial launch of the Portal is an event that will require some specialized messages.

184

Portal Building

Once the key messages have been completed for each group and for each phase of the strategy, the group should also document the types of delivery mechanisms that can be used for each phase and audience. The team should also note any considerations that should be noted for the different groups and phases that could affect the success of the messaging. (If the project team has developed the dates associated with the milestones at this time, this can also play a factor in the success of the messaging. Items like summer vacations should be mentioned in the considerations category, if a large number of employees take vacation at a specific time of the year.) Documenting all of this information into the communication strategy may seem like a lot of work. However, what has just been created is a communications strategy template that can be continually re-used for each successive Portal roll-out, with very little changes required. One of the benefits of developing the communications plan in this manner is that it allows the project team to deliver messages to groups during the middle of the iterative process of the project. Depending on the release schedule of the project, and the technical nature of the audience, it may be possible that the communications members of the team will be working on messages for more than one Portal release at the same time. For instance, the communication messages for the Sustainment phase may be delivered at the same time as the awareness or even the Understanding messages for the next Portal release. This can even become more complicated with shorter release timelines that could result in working on three Portal releases at the same time. By having the communications strategy focus on specific audiences, and by having the key messages already documented, the communications team members only need to slightly modify the messages, providing full text for them, and use the suggested delivery mechanisms that have already been documented in the strategy. When developing the audiences and the key messages, the communications team should be aware of the current technical level of the organization. One method of determining the audiences is to break them down by their expected technical levels. Many factors can go into making this determination; such as experience using the

Communication Plans

185

web, and experience using technical applications. Another set of factors that can go into this type of audience grouping can also be centred on the individual group’s willingness to accept change, and if they are open to new ideas and concepts. Once the audiences have been determined, the criteria that was used to create them needs to be taken into consideration when developing the individual messages. If a particular audience is comprised of a number of individuals with very little technical experience, the wording of the messages will need to be very clear and not use any technical jargon. This will also affect the various delivery tools or mechanisms used to deliver the messages. If the user group is not very up-to-date with technology, then the team should investigate using delivery mechanisms such as posters, and even face-to-face meetings. The audience make-up can also affect the number of messages that are actually sent to the group. Frequency is a very difficult aspect to judge in the initial release of the Portal. (After the team has a number of releases under their belts they will be able to judge from experience, what type of frequency is best for each audience.) The key with message frequency is to ensure that the message is being received by the group without over-exposing the project. Too many messages from the group and the audience will start to tune out and ignore any new messages. Too few messages and the audience will not receive all of the information that they need. The project’s Communications Strategy should include a Feedback Strategy. This Feedback Strategy should not be considered as a “frozen” document. It should be continually updated to reflect any changes to the overall project plan, especially with respect to the timeline of the project. Any changes to the document should be approved by the project team to ensure that the team agrees with the changes made. Also, after each Portal release, and even after each phase of a Portal release, the project team should set aside some time to review the communications and determine its effectiveness in reaching the various audiences. Collecting feedback, both formally and informally can also be used to assess the communications. It has been found that informal feedback mechanisms are very valuable in collecting user’s feedback. A quick conversation in the hall with a fellow employee can act as a quick gauge of response to a

186

Portal Building

messaging campaign. Properly asked questions will allow users to provide feedback without feeling that they are being recorded and under a microscope. Minor adjustments to the communications strategy can be made throughout a Portal release project. Larger, more drastic changes to the strategy should be delayed until after the project has finished and incorporated into the strategy before the next Portal release. Each Portal release will have a slightly different focus (different audiences targeted, different functionality, etc) than previous releases, and therefore will require some modifications to the communications strategy. This is a good time to go over the entire strategy and make any changes and incorporate any suggestions or feedback that are warranted. In most organizations, communications tend to be delivered for the most part by a single delivery mechanism, corporate email. Although this delivery mechanism is relatively cheap, quick and easy to use, it is becoming more and more less effective. One reason for this is that the volume of emails that most users have to deal with on a daily basis is increasing at an alarming rate. This is causing individuals to only skim their email inbox, looking for important emails that must be actioned immediately, while ignoring the rest. The project team should not rely entirely on email to deliver their Portal messages. Using a variety of different media and methods is the most effective method. Not only can traditional methods like email, posters, flyers, etc. be used, but new methods that take advantage of new technologies can also be used. In Europe, where cell phones with SMS messaging is very popular, a project sent everyone in the firm an SMS message about their project. The project team should try and come up with new and different ways to get their message out, as these are the ones that will most likely be remembered. Not all methods need to be high-tech. Another project chose to place a short message on a small “sticky” note that was placed on everyone’s desk phone overnight. This is another example where experience with what has worked well in the organization can really pay off. Also, some organizations have very strict guidelines on how

Communication Plans

187

and even when messages can be communicated to their staff. These will need to be respected by the project team. (Even though these issues need to be respected, the team should try to push the envelope with what can be gotten away with.) Most importantly is that the project team should try to inject some humour into the messages. In most cases, the project will create messages that are very serious and business-like. If this is the case, by livening up the messages a bit, they have a greater chance of standing out in the user’s minds. Again, this goes back to the fact that the team should try to be different in both their techniques and messages. The communications team can and should develop a number of smaller project plans for the tasks that they need to accomplish. Having the communications strategy is only a guide, and it does not go down to the level of individual tasks. Smaller, more focused project plans should be created so that the entire project team can see the tasks that the communications members are responsible for and more importantly, when the tasks are due. These project plans are invaluable to the project manager as he/she can use the plans to help guide their resource levels as well as tracking the overall progress of the project. Another benefit to creating these project plans deals with the fact that in most cases, some project team members, especially the communications members, will not be totally dedicated to the Portal project. These individuals will be “on loan” to the project which means that they are still expected to complete tasks on other projects. By creating a communications project plan for the Portal project that goes down to the individual task level, the managers of the communications team members can get a sense of what is expected of the individuals from the Portal project perspective. This can help ensure that the communications team members will be able to focus on the Portal project and have enough cycles to accomplish their other tasks. These project plans can be highly focused to target specific aspects of the project. There is really no limit on the number of project plans that can be created. This is really only a factor of what the team members are accustomed to and what is needed to properly ensure that all of the tasks are completed in a timely manner.

188

Portal Building

The important aspect of the individual project plans is that they all need to roll-up into a single high-level project plan. This high-level project plan will be used by the project manager to track the overall progress of the project, and as such needs to accurately reflect the high-level milestones of all of the individual project plans. This is important to note since any changes that are made to the smaller, detailed project plans need to be promoted to the overall project plan. As mentioned in a previous chapter, change management is vital to ensuring the successful launch and incorporation of the Portal in the organization. Not only does the project team need to be incorporating change management techniques into the project plans, but the communications strategy and messages need to incorporate it as well. By having the messages incorporate change management concepts, it helps to reinforce what the project team is saying as well. One of the key change management techniques is to ensure that the expectations of the various user groups throughout the firm are properly managed. This can be accomplished by clearly and carefully defining what the individual user groups can expect when the Portal is launched. This is especially true if the project has been going on for an extended period of time, as rumours of the Portal project can start. Clear and concise messages will help dispel any misconceptions that might have arisen. Another way of ensuring that the various user groups of the Portal, especially the Portal stakeholders are having their expectations properly managed is to create some success criteria early on in the project. By showing the project sponsor and the various stakeholder groups the success criteria, they will all be aware of what to expect once the Portal is launched. The success criteria can also be used to help shape some of the communication messages, as the team may need to create certain audiences or target them at different times/frequencies in order to meet their success criteria. Also, if the stakeholders are not agreeable to the success criteria that is put forward by the team, the Portal team will still have adequate time to make adjustments to their strategy/plan in order to meet the new requirements. Most times, when creating success criteria for an iterative project like the Portal, it is necessary to not only create

Communication Plans

189

success criteria for the first launch of the Portal, but to present a road map of how the success criteria is expected to change as the Portal becomes more mature. This “roadmap” is one of the best tools for managing the expectations for the project’s stakeholders as they will be fully aware of what the project team is designing and building the project for. One last item to consider when developing your communications strategy has to deal with the fact that the functionality contained within the Portal may be limited at the first (even first few) Portal releases. If the Portal project follows an iterative development model, the functionality and content that is contained within the Portal will grow as the Portal team has a chance to meet with the various groups within the organization and collect their business requirements. This could result in very limited functionality being contained within the Portal in the first initial releases with respect to certain audiences of the organization. Depending on the size of the Portal team and the length of time before the first release is launched, this audience may be comprise of the majority of the organization. Taking this into consideration, the project team should consider how they are planning on communicating the launch to the organization. This also needs to take into consideration the planned roll-out of the project as well. Some organizations roll-out the Portal to everyone at the same time, while other organizations roll-out the Portal depending on a geographic/departmental basis. Both of these factors will influence how and to what degree the Portal is communicated to the organization. This is where the project team needs to decide on whether the project launch will be classified as a hard or soft launch. A hard launch can be described as a launch that is communicated very well to all audience members. Communication messages are developed in such a way that all audience members are aware of the project and are expecting it. A soft launch is a launch that contains messages that are toned down in nature as compared to the hard launch. This type of launch simply informs the audience members that the Portal has launched but does not overwhelm them with messages. This minimalist approach to messages is useful for projects that require a much lower profile when launched.

190

Portal Building

What some organizations have done with their Portal launch is that they use a combination of both hard and soft launches for each Portal release. The hard launch is targeted towards those audiences of the organization that will have their specific functionality integrated into the Portal for the particular release. The soft launch messages are directed towards the rest of the organization. This is of benefit to those audience members that will not have too much new functionality on the Portal as it does not build up the Portal release too much from their perspective. This helps with managing the expectations of these users. The organization can also go with a completely hard launch if they are comfortable that there is enough functionality within the Portal to provide a benefit to all of the Portal users. If the Portal team is concerned with any aspect of the Portal as they approach the launch date, and they are unable, or unwilling, to delay the launch, they may want to use a soft launch in their communications, which should hopefully reduce the expectations of the user audience. Whatever method is chosen, the Portal team needs to incorporate this into the Portal communications strategy and adjust the messages accordingly. When dealing with the various groups that the Portal team may encounter, the team should be able to classify them into 4 different categories. The four different types of people are; Talkers, Nodders, Planners, and Doers. Each type of person can be either a positive contributor to the project or a negative contributor. Most people are a mixture of a number of these categories, to varying different degrees. If a person is completely within one category, then the project team should try to steer clear of that individual. Talkers are people who prefer to vocalise their thoughts and opinions on a regular basis. On a positive side, these people are very open and are very willing to share their thoughts and ideas. On a negative side, these people will either focus on talking and not implementing any of their ideas or suggestions. They can even be very forceful in imposing their ideas and beliefs on others. Nodders can be considered as the exact opposite as Talkers. These people say very little, and when asked, they will usually only nod

Communication Plans

191

their head or present some of form of agreement. On the positive side of things, these people are very open to new ideas and will help out whenever they can. On the negative side of things, these people can be merely agreeing with a statement without knowing anything about it. Also, since these people do not really say much in meetings, other people may not be completely clear about their position. Planners are people who take the time and record all of the tasks and events that are their responsibility. These people can greatly help out the project team as they have experience in documenting plans (and as mentioned previously, documenting tasks in a project plan is an important aspect of the Portal implementation project). A negative side of these people is that they do have a tendency to spend so much time on the planning stage that they do not leave enough time for the actual implementation. Doers can be classified as the opposite of Planners. Doers are the kind of people that jump into a project and start working as soon as possible. These people prefer to start working and start showing deliverables. The positive side of these people is that they will immediately start working and will allow for results to be shown in a very quick order. The negative side of these people is that they do very little planning, which can result in some amount of rework or wasted effort if they do not have a firm/clear vision of the project deliverables.

192

Portal Building

23 User Training Enterprise Portals can greatly affect the way that the organization’s people perform their work, both internally and externally. This can cause a great deal of change to all of its users. For this reason, user training should be conducted for all Portal users. Portal training can be of a variety of different types and should be closely aligned with the communication strategy of the project. User training should be focused on the specific audiences of the Portal, and should include not only Portal end users, but should also be focused on the Portal administrators, help desk staff, and even developers and other support people. This book has advocated that the Enterprise Portal should be designed/laid out in such a fashion that it should be intuitive to the average end user. This combined with the personalization capabilities of the Portal should result in very little end user training being required. This does not mean that no training should be presented or that the training component should not be given important focus, it merely means that the content of the training and its focus may need to be changed. Some organizations, realizing the importance, and the amount of change associated with implementing an Enterprise Portal have put in place policies that state that people cannot access the Portal unless they first take the associated training. Mandating the training in this fashion does have positive implications that ensure that everyone in the organization will have attended the training, however forcing someone to take the training is usually not the most conducive method of learning. Also, mandating training can have negative implications if it is felt that the organization is pushing the project down on people. This issue must be balanced by the organization’s desire to ensure that the Portal is used properly against the forcing of training on people. Knowing the organization and having experience

193

194

Portal Building

with large project implications in the firm will help the project team deal with this issue. The timing of the Portal training will also vary depending on who the audience is. Whatever group is in question, the training should always be scheduled as close to when the users will actually be using the newly acquired knowledge as possible. For Portal end users, the training should be scheduled as close to the Portal launch date as possible. For the administrators and the help desk staff, they should be attending their training sessions earlier so that they can be prepared for the Portal launch. Some organizations may already have established training or learning and education departments or groups that can be leveraged for this part of the project. Their experience with providing training to the various groups within the organization can assist the project team with determining the timings and the best delivery methods for Portal training. The project team should strive to get the organization’s training department involved in the project so that there is ample time for them to plan and prepare for the end user training. (In order for the organization’s training department to be able to prepare training plans and lessons, they themselves will need to be trained first, most likely by the Portal project team; “train the trainers”.) The two main types of training that are more often used with Portal implementations can be classified as face-to-face training and selfhelp training. With each main type of training, a variety of different delivery mechanisms is available. Both have different advantages and disadvantages depending on the audience and the types of training that need to be shared. It has been found that providing a variety of different techniques for each audience works best. This allows the end user to determine which method is best for them. It also allows the end user to determine if they have not received the training from one method, they can try another. The most thorough and effective type of training is the face-to-face training. With this type of training, a number of users or students are brought together with an instructor. The instructor, or the expert,

User Training

195

provides the information directly to the students. With this method of training there is direct interaction between the students and the instructor. The students can ask questions and have them answered in real-time. Also, experienced instructors can even modify the course to fit the needs and learning styles of the students that are present. However this type of training is also one of the most expensive. Taking people out of their regular work tasks is one of the expenses associated with this type of training, as well as providing the proper room and other resources. Previously, in order to perform this type of the training, either the students would have to come to the instructor, or else the instructor would come to the students. This added travel costs as well as scheduling difficulties. Lately, technology has been applied to this type of training to allow the course to be provided over the organization’s network or even the internet. While it does tend to reduce the student-instructor interaction, it does provide the same basic interaction while reducing the travel and scheduling expenses. Self-help training usually only focuses on the student learning about the Portal from pre-arranged content and functionality. There is no instructor with this type of training and it is only a one way flow of information, No two-way discussions in real time are available. With the usage of some technologies, the student can pose a question to an instructor, but the question will not be answered in real time. The benefit of this type of training is that it is more cost effective than classroom based training, since the content only needs to be created once and can be used for many people. Another benefit is that the student can take the course at the time that is most convenient to them, and they can proceed through the course at their own pace. Unlike, classroom based training, if the student is a fast or slow learner, they are not held up by the pace of the rest of the class. The disadvantage of this type of training is that it tends to be very impersonal and that the two-way communication or discussion is not available. A number of different types of self-help training are available, and there are a number of computer based training modules which are usually provided via a CD-ROM that contain a number of different training modules. Another example of this type of training that is gaining more popularity is having the training presented to the users from a series of web pages. This allows a

196

Portal Building

common spot for users to access the training materials and does not require a number of CD-ROMs to be distributed throughout the organization. Another useful method of providing users training is by taking advantage of “lunch and learns”. These sessions are classroom based and are provided over the lunch hour period so that users can come and receive some user based training. The groups are usually much smaller than the standard classroom based training and also tend to be less formal. This is all intended to provide a friendly atmosphere where users can learn about the Portal and have their questions answered. Some organizations will even provide a lunch in order to entice people to come. These lunch and learn sessions should be conducted over a number of days, with a number of sessions scheduled for each day. It is recommended to ask people to sign up for sessions to ensure that the users are evenly spread over all of the sessions. (In most cases, the first couple of sessions are sparsely attended, but as the word gets out, the latter ones are rather busy.) In order to ensure that the majority of people within the organization will actually be able to receive some type of user training, the project team should work to ensure that there are a number of different methods in which they can receive the training. Providing a mixture of both self-help and classroom based training provides the ability for some users to possibly refresh what they were taught using one method with another method, possibly via “lunch and learn” sessions. It also allows for those individuals who were not able to attend one of the classroom training sessions, the opportunity to still receive some of the training at a time that is convenient to them. Whatever methods, or combination of methods, are chosen, they need to be clearly communicated to the organization. Everyone within the organization should be aware of the effort to provide user training, and all of the options that are available to them. This will allow them to be able to schedule the appropriate training session for them. It also allows for an easier change management effort when the organization realizes that their needs are being taken into consideration.

User Training

197

One aspect of the end user training that most people have a tendency to forget involves the actual use of the Portal. End users should be able to quickly get onto the Portal in order to start putting to use the knowledge that they have just learned. This is important when developing the timing of the user training. Too much time between the user training and the actual Portal launch may result in people forgetting what was taught to them, which may require additional training sessions. Different audiences within the organization will have different training and timing requirements. The Portal team should look to the communication strategy to determine the various groups within the organization. These groups can be applied to the user training sessions. Not only should the end users be looked after from a training perspective, but the people who will be maintaining and administering the Portal will also need training. These groups will require specialized training that is quite different then the average end user training. (They should also receive the end user training since they will be using the Portal, not just administering it.) This specialized training also needs to be scheduled earlier on in the project in order to give the group ample time to become familiar with the Portal. These people need to be experts on the Portal before the Portal is launched to the entire organization. If timing does not allow these people to receive proper training before the Portal launch, this can be taken into consideration by having a gradual Portal launch, thus providing extra time for them to become accustomed to the Portal. The requirements of each of the different audiences will also dictate how the training should be delivered to them. For instance, the organization’s executives may require a special training session just for themselves. This may need to be done to provide them with training first, but it also may be a result of their familiarity with new technology and their willingness or ability to accept change. Some executives may even require individual user training sessions. The location of the audience may also require special attention for scheduling user training sessions. If part of your organization is very seldom in the office, for instance a mobile sales staff, they may require specialized self-help training, or even an offsite training

198

Portal Building

session. These considerations can affect the timing of the training sessions as well as the budget. End user training should not end once the Portal has been launched in the organization. Providing refresher training either through selfhelp methods or even by classroom based training should be considered to allow users be continue to expand their knowledge about the Portal. (After the launch of the Portal, these types of continuing training opportunities should be focusing on the self-help methods from both a cost and resource perspective.) Some organizations have created advanced training modules that are available after the Portal has launched. These advanced modules cover topics in more detail and can also cover topics that are not needed for the average every day user. These training modules are meant to satisfy the users who are willing to know more about the Portal’s capabilities. These users also tend to provide valuable feedback on future functionality as they are the ones that greatly understand the capabilities of the Portal. Continuing training is also important since new functionality will be coming onto the Portal at regular intervals. This new functionality should have its own training requirements, but it will also drive new users to the Portal, (or existing users to use the Portal more, or use more functionality within it). The existing training courses that were used when the Portal first launched can be tweaked to serve as refresher courses. The overall content can remain the same however; the wording and the focus should be modified so that the user perceives them as a different or refreshed course. Another user audience that should be focused on for unique Portal training is the new hire audience. Depending on the type of the organization, the project team may be experiencing a number of new people starting at the organization on a regular basis. These new people will need to receive some form of training on the Portal during their initial time with the organization. This new training can be quite different from the training provided to existing members of the organization as they will not be familiar with the way the organization was before the Portal was implemented. This should greatly reduce the change management aspects of the training. Care

User Training

199

should be taken to provide proper training to this group of people as they can become one of the strongest users of the Portal since, to them, this is the only way to access the functionality of the Portal. There are actually two parts to end user Portal training. The first part deals with getting the users familiar with the Portal interface. Topics that should be covered in this part of the training should focus on the project in general; why the organization is doing this, as an overview of the Portal. This overview should focus on how the Portal is subdivided and organized, and how the users can navigate between the various different parts or sections of the Portal. The second part of the Portal training should focus on the functionality that the Portal contains. Each piece of functionality or content that is accessible from the Portal should be explained to the users. This will show them in detail what the Portal can do for them. (After the initial launch of the Portal, whenever new functionality is brought into the Portal, it may be beneficial to consider them not as Portal release launches but as functionality launches, this places the importance on the functionality that is new, and not the Portal itself.) All of these topics that have been discussed in this chapter will have a large dependence on the advertising or communication strategy. This is needed to ensure that the end users are fully aware of the training opportunities that exist and how they can access them. The main focus of the communications around the training, aside from informing the users about them, is that the project team wants to ensure that the users feel that they are an important part of the project and that the project team is very concerned with their ability to find benefit in the Portal.

200

Portal Building

24 Metrics & Measurements For each project, especially larger ones like an Enterprise Portal project, executives of an organization will be expecting to receive some form of benefits from the project’s implementation. If there are no perceived benefits the project should not continue. In order to report back the benefits to the project sponsors, and even to the organization in general, the project team will need to collect metrics and or measurements from the usage of the Portal. Another reason for collecting metrics centers around the old saying of “You can’t manage what you can’t measure.” Collecting metrics on the project not only allows the project team to discover what is currently going on with the application but it also provides an indication of what could possibly be going to happen in the future. (Either from an infrastructure or usage perspective.) Not all of these metrics will be providing negative information, they can also show which areas of the Portal are the most popular and even which areas of the organization are most embracing the project. The amount of metrics that needs to be collected and the degree in which they need to be collected will be dictated by the expected/communicated benefits of the project. These benefits should be agreed upon early on in the project so that the proper metrics can be collected. This is not to say that the project’s benefits cannot change throughout the life cycle of the project, just that the core metrics need to be determined so that the project team can focus on them. Other benefits may be discovered from the analysis of the metrics, and will be discussed later in this chapter. It should be noted that not all of the project’s benefits will be able to be proven by collecting metrics. These intangible benefits will need to be proven in other ways. The classification of benefits into tangible and intangible is important so that the project team can focus on collecting metrics that will be useful for supporting the project.

201

202

Portal Building

Another reason for collecting metrics does not concern itself with project benefits, but is used to track the performance of the Portal itself. This is important to ensure that the solution itself is stable and is operating within its normal established boundaries, but they can also by used for ensuring that the user experience is positive, and can even be used to track ways of increasing the user experience. Whatever the usage of the metrics, whether they are for proving benefits or for checking the health of the Portal, the team should clearly define what it is they need the metrics for and how they will be used. This allows the project team to clearly define what it is that needs to be tracked and how it should be tracked. One temptation is to simply track all of the metrics that the application is possible of tracking with the assumption that it ensures that the specific pieces of measurements that are required will be included somewhere. As one might expect, this is not the most efficient and in some cases the most practical way for the project team. Generating metrics does take time and processing power away from other aspects of the application. From a user perspective this could result in a slower response time for the Portal. (In order to avoid this a larger server may be need to be purchased, so the team must weigh the added cost of the additional servers against the time required to map out exactly what aspects of the application need to be tracked.) Another drawback to collecting massive amounts of data is that it increases the time required to analysis the data and produce meaningful reports. (This is a direct result of having to go through larger amounts of data.) What the project team should be doing is to focus on collecting only the data elements that are required. This reduces the load on the servers, and it even reduces the amount of data that needs to be analyzed. While metrics are powerful in that they provide a snapshot of what is currently happening with respect to the Portal, they can become even more powerful if they are incorporated into a larger set of metrics that can provide some sort of trend analysis. This trend analysis can show the changes over time and are especially useful when showing metrics like user adoption rates and improvements to the Portal’s response times. However, in order to ensure that these trend metrics

Metrics & Measurements

203

are of value, the information used to create the metrics needs to be the same throughout the duration of the metric’s use. This means that the project team cannot change what is being collected halfway through the project, since this would effectively cause some irregularities in the metrics reporting. Also, some organizations prefer to have a “before and after” snapshot for some of the metrics. This means that the team needs to collect metrics on the existing situation of the organization before the Portal is implemented. In order to accomplish this, the metrics collection needs to begin very early on in the project. Usually the metrics collection part of the project is left to the end of the project when it is already too late to collect existing metrics. One thing to note here is that most organizations do not already have a large assortment of metrics that they currently collect that can be accessed at a later date. For this reason, it is better for the project team to look at the metrics collection requirements early on in the project to determine if any preliminary work needs to begin. Once this initial assessment is finished, the team can then place less of a priority on this aspect until later in the project. There are three main set of metrics that should be tracked and interpreted. The first set of metrics deals with the business result or the ROI of the project. These types of metrics will provide your organization with some description of the benefit that the project brought to the organization. Considering the benefits that the Portal is supposed to bring to the firm, the majority of these types of benefits will focus on the qualitative side of things and not the quantitative side. This will mean that the metrics will be very subjective and could need more proof to back them up. This is usually done by conducting surveys or getting user feedback from representatives of the firm. One item to note here is that care must be taken to clearly identify the Portal project as the cause of the increase in benefit and that it is not attributable to some other external factor. For this reason, it is usually very difficult to accurately track, or even create, an ROI value for the Portal project. It is however, rather straight forward to create an ROI value for the functionality that is brought into the Portal. (Determining what part of the ROI value is attributable to the Portal and what part is for the functionality itself, is usually so subjective that most organizations

204

Portal Building

are focusing on treating the Portal as infrastructure and only conducting ROI analysis on the functionality that is brought into the Portal.) The second set of metrics can be defined as user acceptance metrics. These types of metrics will provide the project team with an indication of who is using the Portal, when they are using the Portal and for how long. This will give the team, and the project sponsors an indication of how well the general population of the organization is accepting the Portal. The project team can collect this type of information by collecting the application logs and running some analysis on them. There are usually a great number of metrics that can be collected and analyzed with this set, and the project team could find themselves spending too much time crunching the numbers. The team should clearly define what they want to track before the analysis stage so that they can target their efforts. There are a number of different products currently on the market that are designed to analyze a log file and present usage data in chart or graphical formats. In fact, some Portal applications are either including this functionality into their product, or are bundling a separate product with it. The third set of metrics is focused on measuring the increased number of help-desk calls or other increases on the technical support staff. These measurements are collected from the individual support areas of the organization. These metrics can be considered as both negative and positive indicators. While they do present a list of all of the issues or problems that the users are experiencing with the site, it also provides valuable tracking information to the Portal team for either examining weakness of the Portal or even showing areas that may cause trouble in the future. It also provides a listing of people that are using the Portal and what particular functionality they are using. Help desk and other support mechanisms also provide an avenue for Portal users to provide general feedback on either the existing Portal functionality or on what they would like to see in the future (enhancements). These suggestions and other general feedback should be captured and actioned by the project team on a regular basis.

Metrics & Measurements

205

Another type of metric can also be collected by analyzing the feedback and general comments from the Portal users. This not only provides information on who is using the Portal but on areas that the users are trying to use it for their work. Positive and negative feedback can even be used to feed into the quantitative metrics analysis being done. User testimonials, especially if they come from an unsolicited user can also prove more valuable than a whole page of numbers and charts. One of the key things to keep in mind when dealing with tracking metrics over a period of time is that the information being collected must be consistent over the time period. The team should be tracking the same metrics, which usually means that the tracking of the metrics needs to begin very early on in the project. One easy way to ensure consistency is for the team to use a single tool for analyzing the data. Different tools may display the data differently which could result in different interpretations of the data. If for some reason, the project team does need to change the type of data that is being collected or how the data is being analyzed, this should be made quite clear on any of the presentations or completed information sets that are created. The team should even consider stopping the trend and beginning a new trend using the new data if they feel that the two information sets are not comparable or would cause confusion to the end user. In either case the project team needs to make the end user aware of the change and why the change needed to happen. If the project team is not able to justify to the end user why the information tracking has changed, the end user may feel that the project team is covering up some negative information. Along with the usual metrics that have already been discussed in this chapter, the project team should go back to the original vision of the project to ensure that there are no other metrics that are specific to this project that should be tracked. Enterprise Portal projects are unique in that most organizations that implement them do so with at least some intention of having the Portal act like some sort of filter; the Portal could be filtering content, applications, etc. In order to gauge how successful the Portal is able to act like this filter, specific metrics need to be collected. These metrics are different in that they will be tracking how effective the Portal is on not doing something,

206

Portal Building

as opposed to how well the Portal does do something. This was just one example of the project specific metrics that should be collected. The project team should be responsible for determining what other specific metrics need to be and what needs to be collected in order to produce them. Timing may also need to be considered, especially if the collection of the information needs to begin before the Portal is launched. These types of metrics also usually require more work to be done on the analysis end when compared to other types of metrics. Tracking these metrics is very important as they are the ones that will be directly tied to the vision of the project. These are the metrics that the project sponsors will be looking for the most as they are tied directly into what has been sold to them.

25 Demos, Demos, Demos The concept of an Enterprise Portal may be difficult to understand for some people. In fact, it can also be difficult to explain for some people. In order for people throughout the organization to become believers and supporters of the Portal project they must first have a clear understanding of what the Portal will mean to them and to the organization. In the early stages of the project, this is done by explaining what a Portal is and what it can mean to the organization. Since the team will not have created a Portal of any type at this stage, showing members of the organization examples of a Portal is usually confined to providing screen shots of what other organizations have done, and from the various vendors’ own marketing materials. It is usually better to provide a visual of some sort when describing a Portal. This visual can be static if needed, as long as the presenter provides some sort of narrative to go along with the image. However, whenever a presentation uses an image from either a vendor or from another company, the team should be careful about the expectations of the audience when viewing the image. If possible, the project team should try and find an image of a Portal that is trying to accomplish the same things as the organization’s future Portal. This provides more relevance to the image. If this cannot be accomplished, the team needs to very clearly explain to the audience that the image is for description purposes only. Nothing provides more relevance to the audience than a Portal that contains the applications and information sources of the organization. This allows the audience to see how the various applications that they use on a daily basis will fit within the Portal. With this in mind, the Portal team should try and create something that can be demo-ed to the organization early on in the project. Care must be taken to ensure that this is not done too early in the project before actual requirements are determined. If this is done, the

207

208

Portal Building

project team might include certain pieces of functionality in the demo that either cannot be technically achieved within the project, or it may provide functionality that the business does not see as a requirement. In the first case, the team must be careful to ensure that what they actually present is achievable, since once the users see it, they will be expecting to have it included in the deliverables. In the second case, the business may be turned off of the project if they do not see value in the functionality that is being presented to them. This boils down to having a clear idea of what is being expected and present functionality that is needed to the firm, at the same time being aware of what the team can actually achieve. This should not be read as a statement that the project team should be conservative in what they put into their demos, in fact the team should use the demos to really push the envelope on what can be done; it’s just that they should always remember that if someone is presented with a certain piece of functionality, whether it is achievable or not, they will be expecting to see it some time in a future Portal release. Depending on how early it is in the project, the team’s demos may be comprised of mostly examples of how the functionality can be accomplished without actually having the functionality working properly. This ability to fake or mock up the functionality is sometimes called “smoke and mirrors” and is used to illustrate to the audience what is possible to be achieved. As the project continues, the team should be able to replace more and more of the smoke and mirrors aspects of their demos with actually developed functionality. Even though the team may want to include a wide variety of functionality in the mocked up portions of the demo, they must take care not to raise the expectations of the audience too much. If there is something that the audience sees in a demo, they will be expecting to see it in the final product. Therefore the project team must be clear on what actually will be included in the early releases of the Portal and what parts of the demo contain functionality that is being planned for future releases. (If after being told this information, the audience still wants a piece of functionality from a future release included in the Portal at an earlier date, they can make the decision if they want to fund the increase in resources required to achieve it or not.)

Demos, Demos, Demos

209

Early on in the project, the team may want to spend the time creating what are known as proof of concepts or pilots. These exercises are usually very small projects designed to determine if the software can actually accomplish a certain amount of functionality. Since these mini projects are meant to only determine if something is possible or not, they are finished quite quickly and therefore are not ready for a production environment. In most cases, the project team will usually have the vendor(s) that they are evaluating for the Portal software provide a proof of concept to ensure that what the vendor has stated in their documentation is achievable. The outcome of these pilots can be used by the project team as the first type of demo provided to the organization. This type of demo would be presented to the organization and usually follows a script. This allows the presenter to focus on the parts of the demo that are functional, while skipping over the nonfunctional parts. However as the project advances, the demos that are provided to the organization should become more and more hands-on. The final hands-on demo is actually the user acceptance stage of the project’s delivery. With all project demos, (especially if they are presented to the users), the project team can always expect to receive some skepticism regarding whether the demo is really an operational demo or if it is merely just a carefully scripted series of images, (smoke and mirrors). This is usually when having a few minor problems with the demo can be a positive thing as it shows the audience that the system is actually a live system. As more and more people start using the demos themselves, and they become more “hands-on” these negative comments will be reduced as more users see for themselves what has been done. During the early phases of the project, the team may experience some resistance to the project and even to the general idea of the Portal itself. This resistance can usually be attributed to the fact that the people are unfamiliar with the idea of the Portal and what it will actually mean to them. The project team should expect this resistance and one of the main ways to overcome this is to put something graphical in front of people quickly. Working demos are the preferred way of demonstrating the concept and idea of the Portal since when you use just pictures, people can assume that you have

210

Portal Building

just mocked the pictures up and may not be able to actually deliver the final product. With a working demo, there is some belief that what you are showing them is actually real, even if there is a great deal of “smoke and mirrors” driving what you are showing them. To make any demo effective, it must be able to demonstrate to the audience how it will affect them personally. This usually means customizing what is displayed, and even how it is displayed to focus on the audience. From the perspective of the project team, this means that a single demo may not be able to serve the entire potential audience of the organization. Some time should be spent by the project team to understand the pain points of their audience in order to tailor the demo to illustrate how the Portal can help solve those problems. It may be that some of the pain points affect a greater audience and therefore can be used in a number of different presentations. Another great use for a Portal demo is to use it as part of the business requirements collection process. Some groups may experience some difficulty in trying to collect or even determine their group’s business requirements if they are having difficulty understanding the ideas behind the Portal, even after a complete and detailed explanation of the project. Showing them a demo, with a user scenario of how a member of their group would use the Portal can go quite a long way in helping in their business requirements generation. Some times, the project team may have received some business requirements, but when after shown a demo of the Portal, the business group will want to change their requirements. This can be attributed to having a visual demo of some of the ideas that are possible. If the project team is planning on using a demo in their requirements collection process, they should pre-populate the Portal with examples of functionality that may appeal to the audience group. These prepopulated functionality examples should not be meant to dictate what will be included for the group, but should be meant as a way to start a discussion of what is possible. Sometimes, an audience will start with agreeing that a pre-populated piece of functionality will suit their needs but after discussing it, their actual requirements will be

Demos, Demos, Demos

211

something different. Depending on where the team is in the project, they may also be able to show the business requirements/functionality that other groups have requested to be included in the Portal. Another reason to create a demo of the Portal project is that it serves as a great way to advertise what the organization and the team is doing. This advertisement can be used to show groups within the organization what the team is doing and can serve as a way to talk about the expected benefits of the project. If the organization is a large organization with operations in a number of different locations/countries, a demo can be a great way to ensure that the rest of the organization is aware of what the project is doing. This can be especially important if the team is looking for a broader base of support for their initiative. A Portal demo can also be used to show to the organization’s clients or suppliers. This can be used to differentiate the organization from their competition. However, once the team starts showing the Portal to an external audience, they must be very clear on what and when they can deliver the product since it is very difficult to take back a concept once it has been shown to an external audience. (Your organization’s marketing/sales team may need to be informed and educated about the Portal before any external demos are conducted. In fact, they should be the ones driving the request to show the Portal to an external audience, and not the Portal team.)

212

Portal Building

Enriching

Enriching More than likely, the Portal implementation team will have an all encompassing vision of the organization’s Enterprise Portal. However grand this vision is, the first iterations will inevitably be some what less encompassing then the vision. In this section of the project, the emphasis will be on maturing the Portal and expanding its functionality and geographic reach. This maturing of the Portal will rely on a number of key factors. The first of these factors is a new Portal governance structure. The previous governance structure was focused on bringing the Portal to life and ensuring the support was there for a successful launch. This structure is not necessarily the most preferred structure for the ongoing care and feeding of a mature Portal. This section will discuss different governance models and provide guidance on how to develop one that fits your organization. It will also deal with how to transition from the development based model to the enriching model. The other key factor in determining the future state of the Portal is to continually collect and analyze feedback and other types of metrics. Before and after metrics should be collected that will serve a number of uses. They can give direction to the Portal team by illustrating which areas are the most/least popular and they can also generate the required supporting information to the executive teams that illustrate how the Portal is contributing to the success of the organization. Feedback is an extremely important tool. Since an Enterprise Portal is designed specifically to assist the end user in their daily job, finding out what they like/dislike about the Portal is very valuable. Their suggestions of what to include next in future releases of the Portal can also provide direction to the Portal team that they might not have considered. Finally, one of the responsibilities of the Portal team is to keep abreast of the Portal market in general. This information is required to ensure that the Portal solution that the organization has implemented will continue to provide benefits to the organization. Future technologies may allow some of the suggestions to be

215

216

Portal Building

accomplished or to make current existing processes more efficient. (This part of the enriching phase could also be classified as the beginning of the research phase for the next release of the Portal. This reinforces the idea of a Portal implementation being an iterative process.) The milestone/deliverable for the final section of the project and thus the book is that the Portal will become institutionalized into the organization. Executives will promote the Portal as a competitive advantage tool not only for reducing costs and increasing revenue, but also for attracting and retaining the best employees. The final result will be a dynamic Enterprise Portal that will continue to change and evolve to match the organization and the markets that it competes in.

26 Looking To the Future The early stages of Enterprise Portals focused on becoming a “super website” that provided personalization and customization capabilities. Right now, what we are seeing is that companies are moving to the next evolutionary step of Portals and actually using them in the hopes of replacing the company’s desktop. (Providing both content and functionality to the user.) With this type of refocusing of Portal projects, the Portal itself (from the user’s perspective) actually becomes less important, being used mainly as a presentation layer, with the true power of the application being its ability to integrate information and functionality from a variety of backend applications. (When the end user is not able to tell where the information is coming from, or even if they stop caring about where the information comes from, is an indication that the Portal is succeeding as an application integrator.) This “replacing of the desktop”, is starting to be taken even further; some companies are starting to look beyond the desktop and are focusing on allowing Portal functionality to be accessible to users from a PDA, cell phone and other portable electronic devices. If an organization is beginning to move their existing Portal, or planning a new Portal that will focus on application integration, two technical concepts that allow this to happen are web services and Services Oriented Architecture (SOA). A Web service is a set of technologies that allows different computer applications to “talk” to each other, regardless of which operating system or programming language was used to create the applications. A Services Oriented Architecture can be defined as a style of development that allows a developer to create a set of pieces of functionality that can be reused within the Portal for a variety of different uses, and can even be used in different Portals as well.

217

218

Portal Building

Web services rely on XML for accessing information from systems. XML can be described as a common language that is used to describe information. This means that different systems can all understand the same pieces of information, regardless of where the information was created. Web services are being supported by a growing number of vendors as well as Portal applications. XML describes only the information itself; it does not contain any information on how the information should be displayed. This allows for the Portal itself to define the displaying of the information; which provides for a mechanism that allows all of the content within the Portal to appear in the same manner, no matter where it is coming from. The concept of XML has been expanded to focus in on specific ways of describing certain types of information. For instance, XBRL has been developed to establish a common way of describing financial information. This will allow information to be shared between different companies, regardless of the applications that are used to generate and store the information. (Governments are strongly behind the XBRL initiative as they feel it will greatly reduce the amount of effort involved with corporate filings.) XBRL is only just one example of a specific use of XML. Even though some companies are using web services and XML in their Portals, this type of development style is currently in its infancy. Most companies begin their Portal projects focusing on the internal aspects of the project. The initial releases of the Portal are usually focused on the company’s own employees and are only available when connected to the company’s own network. Once this first step is completed, the next logical step is to turn the Portal towards the internet. This usually means providing access to the Portal from any internet connection to the company’s employees, allowing them to access the Portal from their own computer at home or any other internet connected device. Another step is to focus the Portal on providing access to the company’s clients. Allowing them to receive valuable information and even perform some key pieces of functionality, like ordering a product, accessing product information, or even to access customer service, all through an internet browser.

Looking To The Future

219

Wireless access to a company’s network and to the internet is becoming more and more common. This new found freedom allows for individuals to access their information and functionality without being directly connected with a wire. Even coffee shops and other public places are providing this functionality. People who access their Portal using wireless technologies need to keep in mind that the speeds are usually slower than a direct, wired connection. (Although this difference is being reduced very quickly with new hardware that is being developed.) Also, security is a concern when using wireless technologies, especially with public access points. As mentioned in the introduction to this chapter, more and more companies are looking at presenting the information and functionality that is currently available via their Portal using a device other than a standard computer or laptop. The 2 most popular devices that are currently on these company’s radar screens are cell phones and personal digital assistants (PDA’s). While most PDA’s and even a larger number of cell phones have the capability to access the internet, care must be taken to ensure that what is presented to these other devices is focused on what is actually needed. It is not appropriate to simply provide all of the information and functionality found on an organization’s Portal to these smaller devices. The easiest way of determining what should be provided is to ask the user community to determine what they want. Using this process, the Portal team should be able to come up with a few key applications that will satisfy the majority of users. (For instance, access to the company’s email or corporate directory are usually pieces of functionality that are frequently requested.) As PDAs and data compatible cell phones become more common, (and as their power increases) more and more functionality can be pushed out to them. The important things to remember here, is to let the business drive what applications are accessible from these devices, and to start slow; pick a few key applications in the beginning and then gradually add more. Just because you can do something, doesn’t mean you should. Another aspect that companies are starting to realize is that the Portal should be viewed not as a separate entity but as part of the company’s overall web strategy. (This is especially relevant if a

220

Portal Building

company has an external, client facing Portal.) Creating an overall web strategy usually entails examining all of a company’s web-based assets, which include the company’s website, Portal, intranets, etc, to carefully position and align each asset to assist the company’s goal. One of the ways that these types of exercises get started is by looking for duplication across the different assets. This may include refocusing certain assets and may even involve the deletion of some altogether. The important aspect here is to have each of the web assets targeted on delivering a specific piece of the company’s web strategy. (If more than one asset is delivery the same piece, it may get confusing to the end user.) Some organizations have created separate strategies; one for the clients and one for their employees. (Depending on the organization, the Project Sponsor will decide whether a single strategy or separate ones are appropriate.) This web strategy can also be incorporated in (and should align with) larger strategies in the company, like the overall marketing strategy, employee work/life balance, etc. The rest of this chapter will discuss ways that the company should be continually improving their Portal. Throughout this book, the importance of continually improving the Portal through feedback and other business requirement collection methods has been repeatedly mentioned. This is even more important once the initial Portal has been launched to the firm. The Portal users need to see that their feedback is being taken seriously by the team, and they also need to visibly see improvements to the Portal. This is so that they will have a comfortable feeling about using the Portal; even though there may not be the functionality that they require on day one, they will be able to see that changes are happening, and that their functionality will be coming soon. From the Portal team’s perspective, they need to document and operationalize how these changes get added to the Portal. In the early stages of the Portal’s release, the Portal team can push out frequent changes to the Portal. It has been determined that once a month is a good frequency, as it provides enough time for the users to digest the changes as well as providing the development team enough time to create the changes. Care must be taken to ensure that the users (and the development team) are able to handle this schedule

Looking To The Future

221

at the start. Each company will need to assess their own capabilities and plan accordingly. (If the initial release of the Portal is felt to be lacking functionality and content, the Portal team may rely on a number of quick releases in order to bring the overall Portal up to a level that they are comfortable with, but if the Portal team is lacking in development resources, they may want to follow a slower plan.) What the team does need to keep in mind though is that at a certain point, the time between Portal releases should be expanded. This will demonstrate to the users that the Portal is becoming more stable and mature. Quarterly releases at this point are a good rule of thumb, with major release of the Portal not happening more than once or twice a year.) The Portal should always reflect the focus of the company and how the employees work (or how the company would like them to work). This being said, companies are not static over time, but change to fit the market conditions and even their customers. The Portal needs to reflect these changes. As very few companies change their focus over night, the Portal can also gradually change. The Portal needs to be continually examined so that any changes that are necessary can be made incrementally which will be more acceptable to the users. In fact, if used appropriately, the Portal can even help drive change within the company. This type of change needs to be conducted by the executives of the company. This is where having an executive steering committee is of benefit. This group can help drive the focus of the Portal and even propose the changes and new functionality that will affect the company as a whole and not just a portion of it. In very competitive markets or industries, it is always sound business practice to at the very least to keep an eye on what your competition is doing. This is especially true if your competition is using an Enterprise Portal to better assist their clients. Not only can an Enterprise Portal help your company retain, and even gain more clients if they are the only ones in the market with a client focused Portal, but if everyone else in the market is using a Portal, your clients may be expecting one from you as well. Market competition is a great way to fully develop a Portal. (Any functionality that is developed for the external, client facing Portal can also be examined to see if it can apply to the internal Portal as well.) Even if the

222

Portal Building

organization is not currently planning on developing a client facing Portal, an internal Portal can help the sales team, customer support team, etc, better deal with their clients. Finding out what the competition is doing with their Portal can be a sticky situation. The first place to look is on their own website. If they feel that they have some compelling functionality on their Portal, they will surely be advertising it to attract new clients. The important thing to note here is to not focus on copying your competitor’s Portal functionality piece by piece (or even doing them one better). The key is to develop a strategy on how the company as a whole will use the Portal to assist in the company’s client strategy. (This may involve using the Portal to increase client service satisfaction, or even to deliver new products to them.) The team should develop their strategy and stick to it. They can revisit the strategy on a regular basis to ensure that this is what the market and more importantly, what their clients want, but they shouldn’t be tempted to automatically change their Portal the instant their competition does. Have faith in the strategy that has been developed.

27 Processes When implementing an Enterprise Portal within the organization, the organization will find greater long term success with the project if they view it as not just another web-based application, but rather as a tool that can help improve the efficiencies of the organization. This view of having the Portal assist in changing the way in which the organization works can only be done if the project team concentrates on how the Portal can effect and improve the processes of the various groups within the organization. By incorporating the group’s processes into the Portal, the groups will not only see value in the Portal but can easily see that the Portal is their tool, as their processes are incorporated into it. By focusing on the processes that are in use by the various groups, the Portal project has the capability to effect the culture of the organization. This is not a task that should be considered lightly. Effecting the culture of the firm will take a great deal of time (as it is best done gradually), and will impact the future of the organization. Before the project team decides to promote this aspect of the project they should ensure that they have the support of not only the project’s sponsors, but also the support of the executives of the organization. This support should also be very clear and strong as the future of the organization will be affected. One of the most crucial points is that the project team needs to have a clear direction of what/how the leadership of the organization feels that the new end state of the cultural shift should be. The Portal project team themselves should not be the ones to dictate this new cultural vision of the firm. (They can certainly help implement and refine the vision, but the overall definition needs to be done by the executives.) The reason that the leadership needs to formulate the vision is that they are the ones who need to believe that the change is

223

224

Portal Building

necessary as they are the ones who will be responsible for selling the idea to the rest of the firm. Changing the culture of the firm is no easy task and cannot be “process-ized” as the starting point (and ending point) for each organization will be very different. The Portal team itself will need to take the firm’s culture into consideration for a number of different reasons. The first reason, as mentioned above, may be to assist with the change that is being requested by the organization’s executives. This type of cultural change should not be done overtly, but should be kept in the back of the project team’s mind when they design and implement functionality for the Portal. The second reason why the team needs to consider the culture of the organization is so that they can easily recognize issues that may effect how the Portal will be accepted by the firm in general. Knowing these issues early on in the implementation will assist the project team in devising strategies that ensure that the Portal is accepted by all members of the organization. The aptitude for change within the organization can also be a factor that either hinders or assists with this cultural change. One of the first things that the team should do is to perform an assessment of the existing culture of the organization. Some of the things that should be looked for include; interrelationships of various critical factors; senior management support, common goals & objectives, transforming resistance to change, rules of engagement, training process and workflow. Once the team has the implementation of the Portal infrastructure under control, they should then focus on “Portalizing” the business processes of the various groups that are providing functionality for the Portal. The Portal should not merely present a series of links to the users, but should be incorporated into the business processes. This “Portalization” process involves examining the current business processes and after finding the high value ones, look for areas of improvement or refinement in the existing business processes. This is where the project team needs to have some skills in process design or improvement. There may be times where the business processes of the business group do not need improvement and can be simply brought into the Portal. However these business processes could be augmented by incorporating or integrating them into other processes.

Processes

225

(The project team should be able to recognize when the business group is asking for help, and the solution is not to create a specific application for their problem when all that they really need is to modify their existing business processes.) The Portal should not need to create entirely new business processes. It should only be focusing on the existing or new processes that have been dictated by the business. By “Portalizing” the business processes, it allows for the opportunity to automate or augment the process with additional information. Some of the benefits that can be achieved here is to remove the requirement to enter information in different systems, sharing information with other systems, and even improving accuracy of the data. Enterprise Portals can be a great assistance with respect to redesigning or modifying the business process of the various groups within the firm. This is for a number of reasons. The first reason is that the Portal can effectively hide the backend applications from the user by having the backend only provide the content/data and business logic and the user interface can be handled by the Portal. Another reason is the fact that since the Portal can consume content/data and create the interface itself, it can actually present information from more than one application or repository in a single interface. This provides a great deal more freedom to the group that is trying to enhance their processes as it allows for a single entry point of data to feed multiple backend applications. For this reason, an Enterprise Portal can be referred to as the “etch-a-sketch” of process re-design. Once the Portal team is able to show how easy and effective the process re-design can be achieved using the Portal, the organization will quickly come up with other areas that could use enhancement as well. Without this incorporation of processes into the Portal, it will be very difficult to prove the benefit of the Portal as it will merely be just another, and very expensive, website application. One of the ways that this can be accomplished is for the Portal project team itself to start talking to the various business groups within the organization about the benefits of the Portal and how they can best take advantage of the Portal by incorporating their processes into it. Most managers and people who are higher up in the organization will most likely

226

Portal Building

view the Portal as just a fancy website. (Although this is currently true and can be partially a result of the infancy of the Portal, with few true Portal implementations in production, it is hoped that as more organizations invest in Portals this attitude will change, resulting in a much easier task for the Portal team.) Convincing this group of people about the benefits of incorporating processes into the Portal can be accomplished much easier if the Portal team is able to quickly identify a small group that is receptive to the Portal concepts and is in need of some process re-design. The Portal team can then use this team as their demo. They can create the functionality that the team needs and while solving their issues, the Portal can also act as a demo for the rest of the organization. This can also be used as a case study with the group providing quotes and even becoming a champion for the project. The focus to this key group of decision makers is that the Portal is not just a collection of content and applications that can be linked to from a single location. It is able to allow the various groups within the organization to perform their jobs more quickly and effectively by having contextual information and functionality, with the processes to allow them to act on the functionality as well. The Portal team itself also needs to be focused on bringing more processes into the Portal. After the initial release of the Portal is completed, the Portal team needs to continue to promote the inclusion of processes. By focusing in on the process side of things, they will also be including more applications and content sources by default, as most processes will include applications. But by merely focusing on the applications and content sources, it becomes more difficult to then look at the business processes that are associated with the application. Another way that the Portal team can incorporate more business processes is to complete the incorporation of a business process for a particular group. These business processes may include a number of applications that need to be integrated into the Portal. After this particular group has their business processes incorporated into the Portal, the project team should then go to the applications that have just been integrated into the Portal to see if any other group’s business processes touch the applications. These would be very quick wins for the Portal team as the applications have already been integrated into the Portal and may

Processes

227

only need a small amount of development work (if any) to incorporate the new business processes. One of the key things that should be kept in the minds of the Portal team, is that they should be striving to ensure that the Portal can be used as a way of cleaning up all of the old applications and content repositories that are in existence within the organization that are not providing any value any more. These could be the result of an application or database that was created for a specific use or project and that when the use was finished it was not decommissioned and left on the network. By only bringing applications onto the Portal that the business is specifically asking for, it acts as a mechanism to allow the firm to determine what is of use, and by the same token, what is not of use and can be removed or archived from the network. Not only does this free up some network resources with respect to the management of these databases and applications, but it also reduces the confusion that can be happening to the end users when they have too many locations to go in order to access similar content. Another thing that the Portal team should consider is that once an application or content source is fully integrated into the Portal, all other ways of accessing the application should be shut off. Not only does this force more usage of the Portal, but it also reinforces the idea that the Portal is the single place to go. This is also of benefit if the organization is leveraging the ability of the Portal to present content that is amalgamated from a number of different sources, since the users will no longer need to know which application is holding the content, or parts of the content, they will only need to know where on the Portal to go to get it. Whatever focus point is chosen by the Portal team, they need to ensure that the various application owners and the application users are aware of these decisions at an early stage. This is especially true if the other access point of the application will be shut down, as a communication plan and a “shut down” strategy may need to be created for each application. Not only is this applicable to content repositories and applications, but once the Portal is launched, any similar pieces of functionality that are currently in operation within the organization should also be immediately shut down. Examples

228

Portal Building

of these types of technologies are department intranets or websites. These can be seen as competing technologies, and their owners should be included in the Portal project from the beginning so that they are supportive of the project and are ready and willing to shut down their application when the time comes. One of the things to keep in mind when dealing with business processes from a particular group is that the Portal team should try and examine the entire business process if possible. Most times, a specific business unit will only deal with a specific portion of the entire business process. While “Portalizing” just a portion of the business process may be of benefit to a specific business unit, “Portalizing” the entire business process may produce even more benefits to a larger audience. However, examining the processes from a holistic view does have its difficulties. In most organizations, business processes are intertwined with one another and it may be difficult to determine where one ends and another begins. If this is the case, it will be up to the Portal team to determine where they should focus on the process for this version of the Portal. Other complexities that this brings to the table is that the project team will be dealing with a larger number of groups, as the processes will span multiple teams, and they will also be dealing with a greater number of applications/content repositories. While the shear number of applications that the team is using is not really the issue, it is the business logic that is contained within the applications that the team must deal with that is the problem.

28 Governance Structures Up until now, the project team has been solely focused on the successful implementation of the organization’s Portal. This has been most commonly reflected in the organization of the project team and how they interact with other groups. However as the implementation date of the Portal draws near, the project team needs to start thinking about their demise. This “death” of the project team will be the result of the team shifting from an implementation focus to an operations focus. This new team will be focused on the day to day operation of the Portal after the implementation dust settles. Part of the thinking that goes into the proper setup of this new governance model should be driven by the future focus of the Portal. More importantly, what types of people will be using the Portal? Will the Portal strictly stay focused on the employees of the organization? (A business to employee, or B2E Portal) or will it also include an external focus that will interface with clients and suppliers? (Sometimes called a business to clients or business to supplier Portal, B2C, or B2S.) This type of thinking; focusing the Portal on a specific user group; like a B2E or B2C Portal results in a number of different Portals, each serving a different audience. This not only increases the administration and development aspects of the Portal product, but it also makes the task of showing benefit to the organization more difficult as it is spreading the benefits over an increased amount of infrastructure. Organizations should begin to take a holistic view of their Portal infrastructure so that one project will include all potential users to the Portal. (Each user, whether they are an employee or a client would log into the same Portal, but the Portal’s personalization and the security of the various backend applications would prevent the users from seeing inappropriate information or content.) Some organizations are not willing to make this leap to a single Portal due to security and other concerns, but it is something that should be seriously examined, especially early on in

229

230

Portal Building

the project. The earlier on this is discussed, the more time will be available to overcome the concerns of the stakeholders. Almost all of the Portal vendors will try to classify how their product is able to assist, or can be positioned in the B2E or B2C or B2? market. These labels were first created in the days of websites, when every organization was busy creating a website, thinking that they would solve all of their problems. In that time, websites were commonly organized around advertising the organization to the rest of the world. The focus was on showing the importance of the organization and not on the end user. Portals should not be thought of as websites. (If you are thinking of it as a website there are a number of much less expensive and quicker ways, of producing a website than implementing an Enterprise Portal.) I personally do not like the way that the B2? label is used to describe Portals. I believe that if used to their full potential, Portals provide a mechanism that allows the organization to deliver content and functionality that is geared completely to the end user. Using the personalization and customization techniques of the Portal, what is displayed to the user will be what they need or want to do their daily jobs. Also, the context that the Portal provides allows information and functionality to be displayed to the user not based on the organization of the company or its hierarchy, but based on what the end user is trying to do at that moment. One example of this can come from an organization’s human resources department. If they were to analyze why people need to interact with them, they would discover a number of common reasons why people normally come to HR. These groups of reasons, which some organizations have labeled “Life Events”, could then form the basis of how the Human Resources department delivers services to the organization through the Portal. This concept places the end user as the most important part of the equation and not the organization. With this in mind, it is preferable to label the different segments of the Portal as either C2B or E2B, thus placing the emphasis on the user and not the organization. Once the Portal has been launched to the organization, the Portal team should begin to evolve into a Portal operations team. This may

Governance Structures

231

mean that the individuals who are best suited to implementing the Portal may not be the ones who are best at focusing on the day to day operations of the Portal. However, these individuals may be suited to a number of other tasks that the Portal team still needs to focus on. One of these tasks is to focus some energy on starting to engrain the Portal into the fabric of the organization. This entails promoting the Portal to the various parts of the organization and trying to get these different groups to start taking the Portal into consideration when they are designing new processes and even improving their existing processes. This becomes a lot easier once the Portal has launched and people have begun to use it. They can then very easily make the connection to what it currently does and how it can be incorporated into their daily activities. (Even though this process should begin before the implementation of the Portal, it becomes much easier after the Portal has launched and people begin using it.) What the team needs to do is ensure that there are a few key groups that support the Portal and begin to integrate it into their processes at a very early stage. Not only will this show the benefits of the Portal right from the beginning but it also makes it very difficult to remove or stop the project if a number of different groups are relying on it for their daily tasks. This argument becomes stronger as more groups being to integrate the Portal into their processes, or the existing groups integrate more of their processes. This new operations team will need to quickly create a number of different processes and procedures. Some of the key processes that need to be created early on and shown to the organization should focus on how the team will deal with new functionality requests for the Portal. This is important as some groups will want to ensure that the Portal team does not show favoritism to some groups over others. These processes and procedures should be representative of the organization. (Some people will say that they should follow existing processes for other applications, however this should only be the case if the existing processes are appropriate. Creating these processes creates the opportunity to ensure that the processes are of benefit to the organization.) These processes can also be a reflection of the operations team; which should be a reflection of the organization’s culture; participatory, democratic, rotating members, etc.

232

Portal Building

One way of forming the operations team is to create a steering committee that can help determine what types of functionality the Portal development team should be focusing on. Some organizations have even considered creating two different types of steering committees. One level would be comprised of the executives of the firm as well as the project sponsor. This team would be focused on setting the general directions of the Portal. This team would generally meet once a quarter and would receive updates when not setting the general direction. The other level of the steering committee would be comprised of a more cross section of the organization. This group would meet more frequently and would be charged with ensuring that the feedback from the various groups within the organization is brought to the attention of the Portal team. Most organizations will have this team be comprised of the various Portal representatives or champions that have been developed throughout the project. This team should be focused on providing a “ground roots” feel and participation to the project. Care must be taken when these various groups are created to ensure that the entire organization is represented. Not only should the various departments and groups within the organization be included, but it should also be representative of the geographic spread of the organization, if this is relevant. Another factor to take into consideration for the composition of the group is the various languages that the organization works in. Another factor to pay close attention to is to ensure that the members on these boards are not totally comprised of executives of the organization. These teams will need to devote some time to the Portal work which should also be focused on the lower levels of the organization. This is why some organizations have decided to create two separate teams, so that they can ensure that they will have the participation of all the levels throughout the organization. (Some people may feel intimidated with executives in the same team, which is another reason why they have decided to create a separate team.) Once the various teams have been created, care must be taken so that the members of the teams are all aware of the vision and of the goals of the Portal. This may be more relevant in the earlier stages of the

Governance Structures

233

Portal, but as the Portal begins to become incorporated into the organization, this should be less of an issue. This may involve selecting individuals that can easily understand the goals of the Portal. An initial session (or multiple sessions) should be devoted to ensuring that all of the team members are all on the same page, with respect to their expectations of the Portal and their role on the team. One of the key aspects that the team members should be focused on would be to ensure that the Portal continues to focus on the functionality and applications that the end user needs. This means that the team needs to continue to ensure that the project remains business focused. (Depending on the culture of the organization, this may be more or less difficult.) Not only will this drive what is displayed on the Portal from a functionality and a content perspective, but it will also drive where and how the functionality is incorporated. (With respect to content and even functionality, the focus should be on providing context to whatever is added to the Portal. Information and functionality should not be added to the Portal in isolation.) One of the goals (or the potential benefits) of an Enterprise Portal project is that it actually allows the backend application to be hidden from the end user. By using webservices and XML, and other open source technologies and techniques, it allows for the presentation and aggregation of data from a variety of different sources to be presented in the Portal. By separating the data from the application, it allows for a common user interface to be presented in the Portal. This greatly reduces the amount of training that is required when bringing in new functionality into the Portal, since users will already be familiar with the overall Portal’s look and feel. This also helps with the overall branding of the Portal. It must be made clear here that by using these techniques, the Portal in no way will reduce the security or the business logic in the backend applications, the Portal is merely just accessing the data in the application and presenting it. This also greatly reduces the amount of time required when the overall appearance needs to be updated on the Portal. Instead of having to update all of the individual backend applications that provide data to the Portal, the overall Portal design only needs to be

234

Portal Building

updated. Once this is updated, it can be cascaded to all of the other functionality pieces of the Portal. It has been discussed a number of times during this book the benefits and the applications of using the Portal’s built in personalization functionality. This can be utilized to greatly reduce the amount of information and functionality that the Portal users need to sift through on a daily basis, (information overload). There are two warnings that need to be discussed regarding the Portal’s personalization functionality. The first one deals with using the personalization functionality as a type of application security. Some organizations that have implemented an Enterprise Portal have relied on the personalization functionality to screen what users see in their Portals. While this is essentially what personalization does, it by no means is a substitute for backend security. The individual backend applications, whether they are just simple content repositories or full blown applications, still need to retain their own security. The other caution associated with Portal personalization functionality deals with the fact that in order for the personalization functionality to work properly, it needs to have proper and accurate data. This data needs to be associated with not only each user, but with all of the individual pieces of Portal functionality as well. Each Portal application deals with personalization differently, but they all need these two types of data. Collecting the initial data and then maintaining this data needs to be done on a regular basis to ensure that what the Portal end users see is actually relevant to then. Even considering that the backend applications retain their security context and don’t allow a certain Portal user to access a particular backend application, the user would still be presented with a number of pieces of Portal functionality that are not useable to them. (Nothing is more frustrating to the user than having a number of error messages or unauthorized access screens displaying on their Portal, not to mention that they cannot find what they need to use to do their job.) Ensuring that the data is accurate and is constantly being maintained is of importance to the Portal team. Due to its high importance, the updating of the information should be automated as much as possible. (This reduces the reliance on having an individual devote their time to inputting the required information.) Even though this

Governance Structures

235

process should be automated as much as possible, there should still be a single individual, (or group of individuals) who is responsible for the accuracy of the data. Without this accountability, ensuring the ongoing accuracy of the data becomes much more difficult.

236

Portal Building

29 Feedback & Metrics It has been written a number of times in this document that the Portal should be treated as an iterative development project, always growing and evolving to meet the needs of the business. In order to be able to continually meet the needs of the business, the Portal team needs to have the ability to determine what future changes need to be developed. There are two types of information that the Portal team can use for this purpose. The first type of information involves tracking all of the suggestions and comments that come from the users of the Portal. (Suggestions can also come from groups or individuals that may not be a direct result of the Portal usage.) These suggestions and comments can be classified as “feedback” and in most cases a piece of functionality is included directly on the Portal itself that allows users to enter their feedback right in the Portal, and right from the part of the Portal that sparked the idea/suggestion/comment. (It should also be noted that negative feedback should also be solicited and actioned as much as positive feedback. It has been said that no news is good news, and this is especially true of Portal applications; if users are happy with the Portal, chances are the team will not hear from them; but if they are unhappy about something in the Portal, they will definitely hear about it.) This type of information is focused on the future of the Portal; what people want next or how they would like the Portal improved in a future release. The next type of feedback is about looking at the past & present, and involves examining how people are using the existing Portal. Tracking the popularity of certain areas or pieces of functionality of the Portal as well as who uses the Portal can provide the Portal team with information about what users find useful and what they don’t find useful.

237

238

Portal Building

Metrics and feedback should actually be treated as the “life-line” or “pulse” of the Portal. There is an old saying that states that “you can’t manage it if you can’t measure it”, and this goes true for the Portal. Having clear and timely information on the usage and feedback of the Portal will allow the Portal team to not only plan for the future but to also get an idea of what users like and dislike about the current Portal. These metrics can be applied to the original goals of the project to ensure that what was created is actually able to produce the expected results. (It can also give an indication, through trend analysis, of how close the Portal is to achieving the expected benefits.) Metrics can also be used to validate future, or planned, functionality against what is currently being used or requested on the existing Portal. More importantly, the Project Sponsors will be looking to the project team to provide some indication that the money invested in the project has been a wise investment. This is most likely to be achieved if the project is able to hit the established benefits that have been agreed to by all of the parties. Without metrics, this type of validation and analysis cannot be accomplished. Also, the individual groups that are providing functionality for the Portal will want some indication of how successful their functionality is. (They also might want to know who is not using the Portal so that they can target those individuals with a “friendly” reminder.) By treating the evolution of the Portal as an iterative development process, the evolution of the Portal can be considered similar to human development. The Portal’s evolution will be entirely based upon the feedback of its users. This is similar to a child that is reliant on its family and its environment to learn and evolve. Portals can continue to develop and grow old or they can remain at an existing development state; all based on the outside influences that they face. Portals, especially in the beginning phases of their life, need the most care and feeding. As the Portal matures, and becomes more engrained in the minds of the organization, they will require less direct focus. Some people have also linked the care and feeding of an Enterprise Portal to tending a garden. The organization should not have a heavy hand in the development of the Portal. What they should do is to plant the seeds of the initial functionality and benefits

Feedback & Metrics

239

and watch it grow. During the growth phases, it should be tended like a garden, the team should be focusing on removing the weeds or the negative parts, but they should also leave the core functionality to grow at its own pace and at its own direction, (which will be dictated by the firm.) This is not an entirely new concept in the technology sector; companies have been doing this for many years, but few have codified it until now. The most highly publized example of this kind of thinking is the Linux operating system. With this operating system, a core group (a single person) created the initial genesis of the operating system, but then has relied on feedback and suggestions from the users and developers of the operating system to continue to make improvements/suggestions. This will ensure that the operating system continues to evolve to meet the needs of its users. Also, all changes to the operating system need to be approved by the core group before they get promoted to the final application. Demos allow for feedback to be received early on in the implementation process of the project. Users tend to be able to grasp concepts like a Portal more easily if they can see the idea visually. For this reason, the Portal team should try and create a number of demos that users can provide feedback to. The team should try and focus the feedback on a particular area of the Portal at any given time. This focus should be linked to what the team is currently working on. For instance, the team may create a demo that allows for end users to comment on the design or the look & feel of the Portal. The demo that is created and used for collecting feedback should be designed for that single purpose and focus. Care must be taken to ensure that the demos do not mislead the users as to what will be delivered in the next release of the Portal. This can cause the Portal team to have to deal with a number of expectation management issues. Collecting feedback and providing suggestions and guidance to the development of the Portal is best done by using a variety of different techniques and mechanisms. Similar to the communications strategy that was created in an earlier process, the feedback mechanisms should also be varied in order to include as many people within the organization as possible. One of the easiest mechanisms is to include a simple link from the Portal itself that allows the users to

240

Portal Building

provide their feedback directly from the Portal. This is great for capturing suggestions from people who are using the Portal, but it does not capture any comments from the group of people that have not yet used the Portal. Face to face meetings, surveys and even training sessions can all be used to collect feedback and suggestions that can be fed back into the Portal processes. The Portal team, and even the project sponsors, should always be on the look out for ways to improve the Portal. Some users may not yet have fully grasped the concept of the Portal and therefore may not think that their suggestions are Portal related. For this reason, the Portal team, and other Portal champions should try to be aware of other initiatives, meetings and discussion groups that are occurring throughout the organization. Listening and participating in these events can generate not only support and enthusiasm for the project, but they can also generate some feedback and suggestions as well. As the Portal evolves and the organization begins to fully embrace the concept of the Portal, more and more people will understand the Portal and will be presenting their suggestions. This means that the feedback and suggestions for the Portal will become more of a push to the Portal team instead of a pull from the Portal team. Processes should be established by the Portal team to ensure that feedback, and the people supplying the feedback are handled correctly and in a timely manner. The most important part of collecting feedback from individual users, is to make sure that the end users know that their comments are being heard and not just being delivered to a “black hole”. One of the ways to do this is to visibly demonstrate to the users that their comments have been received and are being actioned. This can be done by responding to every feedback comment, or some companies have created a “bulletin board” of all of the feedback comments and the responses from the Portal team that can be viewed by everyone. These ways visibly demonstrate to the end user that not only is their feedback important, but each one will be actioned and followed up on. Both of these solutions require that the project team implement a series of processes that deal specifically with feedback. This is needed to

Feedback & Metrics

241

ensure that the feedback is actioned on a regular basis and that they do not get forgotten about when other, more important issues arise. During the planning stages of the Portal project, the team should have established a number of key metrics that they need to track. They should also have created a number of key metric thresholds. These thresholds should be keyed into the goals/expected benefits of the project. These key metrics and thresholds should be tracked very closely. Some projects will even begin to track these key metrics before the Portal is even launched. This would provide the team with some “before and after” analysis. (Care must be taken with this type of before and after metric, especially if the type of metric can only be tracked with a Portal . . . just because this metric was low, or non-existent before the Portal, may be that a Portal is required to achieve this metric.) Metrics that will satisfy all of the business requirements may need to come from a variety of different sources. In most cases, a standard web tracking tool will be able to track the generic/user access level to the Portal. To get information on detailed usage, the Portal team will probably need to have to access to actual user logs of the Portal application itself. (This may even need to extend to the infrastructure middle-ware to get to some metric information.) Existing tools are being developed by vendors that are able to draw information from a number of different sources into a single analysis tool. The Portal team needs to weigh the benefits of these tools with their costs to ensure that they meet the needs of the organization.

242

Portal Building

30 Internalizing & Institutionalizing One of the most difficult and time consuming aspects of implementing an Enterprise Portal is changing the culture of the firm and the employees so that everyone in the firm is able to recognize that the Portal is where they need to go for information and functionality. This cannot happen over night, and should be part of the overall project plan from the beginning. Changing the culture of the firm and its employees can be accomplished in a number of different ways. These different methods can be broken down into 2 categories; internalizing and institutionalizing. In order to have a successful Portal the team will need to ensure that both categories are considered. (Also, the categories are not mutually exclusive; making headway in one category will ultimately affect the other category.) Institutionalizing can be defined as having the organization as a whole accept the Portal and incorporate it into the various processes and procedures of its everyday life. This means that the various groups and departments of the firm need to make changes to their processes to incorporate the Portal. This may also entail changes to other organizational systems/programs, (like rewards/incentive programs). These types of changes can begun rather quickly, all it takes is the executives of the firm to star the ball rolling, but it may take time in order to complete and finalize them all. The key is to focus on the most important processes that will affect the most people or will provide the most benefit. The benefit of having the Portal institutionalized is that the firm itself will end up promoting the Portal and by having the processes changed to incorporate the Portal, they will be increasing its usage. Internalizing the Portal is slightly different from institutionalizing as it is concerned with the individual changing the way that they

243

244

Portal Building

personally work in order to take advantage of the Portal. This type of change usually takes more time to accomplish as the individual must first realize that there is a benefit for making this change (no one is forcing them to do this). However, if the Portal has been institutionalized, it becomes much easier to internalize as there will be fewer alternatives to the user. As most large scale Portal projects tend to take an iterative approach to their development, the benefits of the Portal to the individual may not be readily apparent until a number of releases have been created. (If the Portal team is able to focus on some of the key benefits for the initial releases of the Portal, it makes this easier.) The benefit for this type of change is that the end users themselves will be driving usage to the Portal and will even be providing suggestions and comments on how to improve the Portal. Another benefit of having the Portal internalized is that it ends up acting as a form of self promotion for the firm in general. In order for an individual to internalize something, they first need to believe that it provides a benefit to them. This positive experience can translate to a positive experience to the firm in general. If the Portal is internalized, the employees will be promoting it to their friends and colleagues (even those from outside of the firm.) When an employee leaves the firm and starts work at another firm, they will be expecting to receive the same type of functionality and benefit from a Portal at the new firm. If this is not available, they may think about leaving or may talk positively about the company to their new firm. Selling the Portal becomes a great deal easier when it has been institutionalized and even when it has been internalized. Having it institutionalized demonstrates to the rest of the firm that the executives are behind the project and that they are making the necessary changes to ensure that it succeeds. This shows commitment and that this project is not just a passing fad, as changing business processes take a good deal of time. If the Portal is internalized, the selling of the Portal becomes easier as the majority of the selling will be done by the Portal users themselves. The only drawback to this is that the team may need to be ready for the increase in demand of the Portal. As users are beginning to internalize the Portal they need to see that the Portal will continue to

Internalizing & Institutionalizing

245

benefit them. If they perceive that the Portal will not be able to continue or even expand the benefits, they may stop or delay the internalization process. Institutionalizing, since it involves making changes to the firm, is a lot more difficult to stop once it begins, (however beginning it is the hard part). If the Portal project has strong executive support from the beginning, institutionalizing the Portal should be an event that can be planned and scheduled. If the project is experiencing a reduction in its executive support, the institutionalization process may need to be delayed, or even forced through. Once both of these processes have begun, is when the true benefits of the Portal will begin to be shown. (Other than that, the only benefits the Portal can realize will either be short term or very specific to a group or individual.) One of the best ways to get people to start buying into the Portal (and even internalize and institutionalize it) is to actually show them the Portal. The concept of a Portal can be very different to some people, and therefore may take a great deal of explaining before they begin to understand it. If the project team is able to show the users an actual Portal, it greatly helps the explanation process. Most project teams will rely on a demo or even a mock up to provide this visual representation of the Portal. The project team should be careful of using “stock” demos or even mockups as there are a number of risks associated with them. The first is that the demos must actually be relevant to the user audience. “Stock” or “canned” demos must be modified in order to provide this relevancy. Also, when creating a demo or a mock up, the team must be careful to not over promise what will be delivered, as the user will be expecting what they are shown. (It is not enough to show them something and tell them that this specific piece of functionality will not be delivered for some time, as the users will tend not to remember what they were told, but they will remember what they were shown.) Demos and mock ups do have a place in the early stages of the project, but the team should be focusing on an iterative development schedule that produces results at regular intervals, (not an all or nothing approach). This will allow the project team to start showing the business what they will be getting at an early stage. This has multiple benefits; not only does it provide something to show people,

246

Portal Building

but it also demonstrates to the business that the team is making progress and it also provides an opportunity for the business requirements owner to validate/test the solutions at an early stage. Having a positive response to the demos will also increase the support for the project and generate buy-in. (It may also increase support for the project to the point where more requirements are being generated. The team must be diligent to remain focused on the initial deliverables and not increase the scope of the first release. Even though there is the temptation to add to the scope in order to increase the benefits of the first release, it is always better to deliver what was originally asked for and then worry about expanding or adding functionality for a later phase.) One of the most effective ways to ensure that the Portal is successful in the organization is to ensure that it is the single source for information and functionality. This is the point that most Portal implementations either do not consider at all, or it is left to the end of the project for consideration. People are creatures of habit. If given the choice between doing something that they are used to doing and have been doing for some time, and doing something new, chances are people will keep doing things the way they are used to doing. Implementing an Enterprise Portal that provides a new way of accessing existing information can lead to difficulties if people are able to access the same content from other avenues. What needs to be done is to have the other ways of accessing the content shut down or removed so that the content can only be accessed from the Portal. What this effectively does is drive users to the Portal. Hopefully, once in the Portal they will discover the other features and functionality and their related benefits. There are a number of tasks that are associated with shutting down, or removing access to an existing application. Most importantly is the fact that this action needs to be clearly communicated to the application owners and the end user. (Hopefully, the application owners have been aware of this fact from the beginning of the project, and they will be prepared themselves.) The planning, testing and implementation of the shut down procedures all require time and planning and cannot be left to the end to be considered. The most important people who need to be informed of this change are the

Internalizing & Institutionalizing

247

organization’s support staff (help desk, trainers, etc.) These are the people that will be getting the calls from people asking what happened to the old way of doing things. (Even if the group produces a great communication package, chances are, there will be some people that will still not realize what is happening.) All access points should be removed, not just the most used ones. The project team should fully scope out all of the possible access points to an application and ensure that they are shut down. This scoping exercise can also help the project team to plan for some of the difficulties or some of the issues that may be raised by users to the help desk. If a user is used to accessing the database in a certain way, they will need detailed instructions on where to find that same functionality or information in the Portal. These instructions cannot simply be discussing the areas of the Portal that the content can be found in, but they will need to be explained in some deal, especially if the content has been included in functionality that is incorporated with another repository. The functionality in the old database was probably distinct and separate from other pieces of content, and users will be used to this. In the Portal however, the content may be displayed differently, either being grouped with other content to form a larger piece of functionality or it may simply just have its look and feel modified. Any of these changes, even if they are considered minor changes, will cause some reaction to the end users, which must be carefully planned for and reacted to. Not only will a successful Enterprise Portal be a benefit to the firm by providing its users (employees, clients/customers, suppliers, etc) with much needed content and functionality, but it can also be a benefit to the firm by raising the profile of the firm as a leading edge company. (Or a company that is able to meet the demands of its customers and employees in an efficient and secure manner.) This can happen if a portion of the Portal users are external to the firm, (clients, suppliers, etc.) By using the Portal themselves, they will be able to experience the capabilities of the Portal and relate them back to the firm. Clients will be able to see that the firm is able to respond to their individual requests, or that they can provide innovative and progressive functionality to them.

248

Portal Building

Even if the Portal does not include external users in its initial stages, (or maybe not at all), there are a number of ways that the firm’s Portal can be “shown off”. As the Portal market is still relatively new, especially from a large scale implementation perspective, Portal vendors and industry associations are keen to show off successful Portals in the form of case studies, contests and trade show displays. Having an organization’s Portal displayed here not only raises the firm’s name by having it displayed, but the exposure in general will act as advertising for the firm. Some companies are not interested in providing examples of their Portal for contests or other vendor media relations, (like reference calls). This may be the result of the overall culture of the firm, or it may be that the Portal contains functionality/content that the firm does not want to share with its competitors. If the firm’s Portal is successful in its launch, word will get out about what has been done. If consultants or contractors have been involved in the project, they may describe what they are doing to their colleagues and peers. Again, this should be treated as some degree of validation of the direction that the firm is headed. Exposure may increase for the project team members as they may be requested to attend/speak at industry conferences and shows. If the firm has a number of subsidiaries and even other locations, word will quickly spread to these other locations about the benefits of the Portal. (This is assuming that the project has not been created as an Enterprise wide project from the beginning.) There is the possibility that if the project is begun in a sub-office location or a subsidiary, the project may be broaden to include the entire firm. While this can be treated as a success for the project, if it occurs at a later stage in the project, it can actually cause difficulties. Changing the scope of the project from a single office or subsidiary to one focused on the entire firm can create many changes to the entire project. The project team needs to decide if the project has already passed a certain stage that the project as originally scoped should continue to its first deliverable point. After that point, the project team can re-evaluate the new scope of the project. This follows the advice that it is better to deliver something then continually be changing the project to make it better.

Internalizing & Institutionalizing

249

Another issue to consider regarding this point is that the project may be taken away from the team and transferred to another group (this usually happens when the project is focused on a subsidiary and the head office decides to make it a firm-wide project with a brand new team). These political “battles” should be avoided, and the new owners should be made to guarantee to the business sponsors that they will be getting the same business value in the same timelines as was originally agreed to. If this is not the case then a case can be made to keep the project where it is.