The goal of this article series is to provide tools and assistance that you can use with your chosen Web development project process. Although it does not prescribe a methodology, it does assume you have one. Appendix A. Methodology in our world discusses some of the processes we have encountered in our work. If you don't have any formal methodology in place, then following the path or general phases laid out in this article series may be enough for your team. However, if you already have an established process, then you can use this information and the tools provided here to compliment your process, or to help adapt it for a portal project.
This article series was written by hands-on portal specialists and architects who have successfully delivered countless projects. While experience in the technology and product suite is probably more important than a well-defined process, the best situation includes both. However, if you don’t understand the issues, risks, and available options, then all the tools and processes in the world might not be enough.
After years of working on portal and other Web projects (sometimes with disturbing results) the authors writing this series are convinced that there is still much discussion to be had about the running of a successful portal project. A lot of the success and failure of a project hinges upon an organization’s project methodology, including the steps that a project will follow, as well as the thinking behind taking those particular steps.
Some of the questions that successful methodologies help to answer are:
- What are the phases our project will use?
- When is one phase complete and another begin?
- What are the deliverables and work products within each phase?
- What happens when a phase slips and the next phase can’t start on time?
While this series will address some of these, rather than answer all of these questions for you, we hope you keep these important questions in mind when planning your project. When you see books or articles on this topic, the discussion is often based on a defined process that is being recommended. Although we might not choose the process being advocated, we still read new material on this topic hoping to glean new ideas, which can be used in future projects. We find that understanding new methodologies can help us learn new techniques for dealing with specific issues, adapt a subprocess, or get ideas for a new tool.
Experienced practitioners will almost always have a preconceived idea of the direction they want to go. These preconceived assumptions can sometimes lead to a project's failure. So what do you do? Well, having worked through many portal projects, we believe that we can help future practitioners avoid some of our battle scars as they embark upon a new project, regardless of the method (or lack of method) used.
This series provides:
- A set of "practical" work products, or tools, which can be used in almost any portal project to help you gather, track, design, and deploy a successful portal. Even if you do not adopt the documents and templates exactly as provided, you can use them to gain a new understanding of many of the tasks that should be done.
- Best practices that have been gathered by portal architects and specialists over dozens of projects that you can apply to your effort.
Hopefully, most of this discussion will be the "I didn’t think of that!" kinds of information that will help you annotate another line item on the project plan, resulting in a better planned project which is based on more informed decisions.
There are many ways to gather requirements. Most projects have a dedicated requirements phase in which business analysts and consultants talk with end-users and business owners about what they want or need the system to do. In the case of agile methodologies, such as Extreme Programming , gathering requirements (user stories) takes place over the course of a few hours or a few days. For more information on agile development and Extreme Programming, see Resources.
In a more formal environment it may take several weeks of user sessions before requirements can be fully documented to the point of usefulness. Generally, after these requirements are gathered and prioritized, some scoping is done to determine what can be accomplished, and the resources and time required.
However, this is not always what happens in the real world. In many projects, formal requirements are done as an afterthought, if at all. Even in projects where requirements are given more attention, they are often not in a usable form. Ask yourself how many times you have you worked on a project and asked the question, "Where are the requirements?" or been given requirements that have no relevance to what you are doing.
The focus here is not to place blame, but to provide some thoughts toward working within any deficiencies in the process. In later articles, we will show you how you can document requirements for a particular component, whether they have been formally gathered or not. In all cases, requirements should be immediately useful to the project team, as they are gathered. Spending time gathering generic requirements such as, "The system shall display information in multiple languages" is of little use to anyone. Instead, a more specific statement such as "The system shall handle the following 6 languages and the user may switch languages at any time," enables the team to understand the scope of what is required and how it might be delivered.
At some point in your project you will need to gather requirements, and how you treat this area of your project will dictate how successful you will be in meeting your client’s expectations success.
One approach is to treat requirements as a project-wide work item that stretches across the entire project lifecycle. You gather high-level requirements at the conception phase of the project. During design, the team assimilates these requirements and debates any questions that arise about the feasibility of implementation versus the actual benefit the feature or function will bring to the users. Toward the end of a project, during the testing phase, these requirements are brought back to the project conversations in the form of test cases or test scenarios. In this approach, requirements are a fundamental part of building a successful portal project. The requirements are not changed between these different time frames; rather they are used appropriately at different times within different phases.
What is important about requirements gathering in a portal project is to clearly define the scope of the project in terms of how this will impact the chosen user community. Defining the feature and function set of the portal will come more naturally once the objectives and goals are clearly defined within the scope of the project, by selecting the user community that will become the primary target of users for the portal.
The four primary influencers of requirements in a portal project are:
- Functional requirements
- Non-functional requirements
- Content requirements
- User community
Figure 1 shows how the first three elements compose the core requirements. The user community is the purpose for which we gather these requirements.
By clearly identifying the primary user community, you define who the beneficiaries of the portal will be. You can do this by defining several target groups and choosing features that will benefit these groups.
Figure 1 - User community and requirements
In our years implementing portals we have witnessed some confusion among many teams running portal projects regarding the nature of requirements versus the project scope.
- Requirements should be what later will become the laundry list of features and functions desired for the chosen user communities. Of course this should be within the constraints and guidelines provided by the sponsoring business units, and with the enablement of the chosen technologies.
- The scope of the project is the contractual commitment of the project team, with the supported user community and the sponsoring business units, to the chosen feature set, in a give period of time, based on a specific explicitly-stated set of assumptions.
The scope of the project builds on the project requirements by choosing specific requirements that will be implemented. Agreements on those requirements are made based on business goals and objectives and on limitations of project resources.
We have a way of classifying portals which we think is helpful. A recent article, Developing an On Demand Workplace, Part 4: The business value of WebSphere Portal, outlines 5 potential types of portals. We encourage you to read this article to help classify the type of portal project you are starting; however for our purposes we have boiled it down to three generic types of portals.
Content portals are those portals whose primary purpose is to share knowledge or information. These types of portals are informational in nature. Content, or information, can be spread throughout or beyond the enterprise. This content can be aggragated from disparate systems, or it could be pulled from a centralized content repository. Users access the content thru the portal as the primary channel.
Transaction portals are those portals whose primary purpose is to provide users with a system with which to execute transactions or to receive updates of transactions executed by other users. This type of portal might include workflow-- either within the applications or within the portal. Transaction portals are usually the integration of two or more disparate systems such as an enterprise resource planning (ERP) system, a customer relationship management (CRM) system, or a supply-chain implementation.
Collaboration portals provide tools for people to work together in a variety of ways. They can include real-time communication support, using Sametime® or another instant messaging system, asynchronous communications with message boards, and document collaboration capabilities.
Why it is important to define the type of portal? Determining the class of portal you will build helps you define the bulk of the work items for implementation and affects how you assign resources in your project.
Content portals require more effort in finding content, defining the content lifecycle, and integrating the processes that create this content. There is also a great deal of effort involved in the formatting of the content to fit specific branding and corporate guidelines. The user community that will create, update, maintain, and own this content on the portal must be trained on the processes supported through the portal for publishing content.
Figure 2 shows a typical implementation of a content portal.
Figure 2 - Content portal
On the other hand, implementing transaction portals requires more understanding of each system that has been selected for integration with the portal. Such integrations are stand-alone projects with challenges, such as near-real-time system integration. This type of systems integration forces you to focus your resources and efforts more on clearly defining each integration point, and on spending a great deal of time and effort defining interfacing documents for each and every system to be included in the portal.
Implementing collaboration portals involves aspects of the other two types of portals. There is usually a good mix of the typical integration of messaging systems, transactional-based systems, and a sizeable amount of content to integrate as well. Much of the so-called Knowledge portals fit into this category of portal deployments. These collaboration portals require that you have a seasoned team on each of the technologies used because there is a little of everything going on. So, you need to have some experts on content portal implementations, as well as system integration experts, onboard when planning a collaboration portal deployment.
What makes portals so attractive is the promise of integration they offer. Yet, integration is often oversold as a simplistic solution to the actual needs of the client's user community. Of course, you as the implementer of the solution are the one who must face the reality of trying to interconnect dozens of disparate systems within the given business, political, technological, and time constraints. From the point of view of integration, portals do offer the perfect framework to enable the enterprise to present a unified face to the demanding user community.
If your portal incorporates aspects of all three types of portals-- or perhaps some set of functionality that is not defined here -- then the challenge can become even greater. The need to spread critical resources across many unrelated areas can kill even the best-defined project. One key theme that you will hear over and over is to start small for the initial release of your portal. Do not try to include every function that your users' wish list, even if they think they really need it. Be strong-- your reputation may depend upon it. If your project does have a lot of major requirements, then plan a "series" of releases to make sure that everything is not released at once.
Defining a target user community is one of the most important tasks in building a successful portal. For a clearly targeted portal, such as an agent or call center portal, determining the user community might be a simple exercise; however for multi-user portals, this activity involves more than you might imagine. One portal implementation might address the needs of many user communities. For example, a project which starts as a simple B2E portal or dynamic Workplace can encompass many different types of users within the organization. You need to identify and classify the different users who will access the portal.
Defining your target communities will help you to define the features, content, and system integration needs. The user communities can be critical to helping you narrow down requirements to a very useful set of features and content. On the other hand, sometimes the various user communities bring to the table very contradictory requirements. This can put tension on the project team. Depending upon the audience, user communities should be an integral part of your planning when it comes to classifying and prioritizing your requirements.
While we don’t offer a specifiy work product to help you with this activity, we suggest that you:
- Set aside time to identify and discuss who needs to access the portal.
- Define a mission statement for the portal to help you stay on target as the scope of the project builds.
- Start a simple list or spreadsheet of the different types of users, different groups of users, and the kinds of activities they will perform with the portal.
Later in this article you see will see how to define some of this information into more formal documents.
Governance of a portal is an area that is commonly overlooked in many projects, especially when the project is being driven by the technology team and does not have sound business drivers. What we have noticed is that most projects fail to account for this important part of the portal solution when it counts the most--at the very beginning of the project. Consequently, when portal governance is not part of the early planning of the project, the final solution can appear to look like a complete after thought becoming cumbersome to manager, or being handled as a piece meal solution at best.
What is portal governance and why it is so important? Portal governance is the set of processes and procedures, to manage the ongoing operation of the portal, and its associated processes and technologies. It is defined by the organization that owns the portal solution, and is a part of the core portal solution.
Technology alone cannot solve the business problems we try to address by implementing a portal. Our solutions will very likely also involve human beings and organizations. Therefore, you need processes and structures in order to keep solutions working within a framework of assumptions, and within physical, political, and organizational limitations.
Granted, this is not always the case. In many smaller portals there are streamlined processes or small teams who work together quite well to manage and advance the functionality and use of the system. In large-scale releases, where there may be multiple teams or departments, governance can become a very troublesome issue. Multiple releases, competing resources, and time pressures can all add up to additional issues within your environment or organization. Understanding how the portal will be used, managed, and enhanced can ease many potential problems in the future. These issues will be discussed in greater detail later in the series. However, for now, consider:
- How many different providers will there be for the portal? Will different teams from different business units be competing to get their information into the portal, or will everything be driven from a single source or department?
- How will you set up the infrastructure for your portal? Will there be a single portal server from which all information will be served, or will you set up several different portal environments which users will switch to for different needs.
We will continue to revisit this topic throughout the article series.
Scoping the portal (or portlets) might sound a lot harder than it really is. It’s really all about requirements and knowing what you want your portal to do. (See our definition of scope in the section An approach to defining requirements.
A portal is really just a window to people, content, and applications. Your requirements help to define those windows and the content or data within each one. What you need is a mixture of requirements, design, and information architecture to effectively start the scoping process. Most projects know that they want to have portlet A, and that this portlet will display information from a specific source. They may even define the information that will be displayed and in which format it will be shown. This is what scoping is all about --defining your portlets and providing some detail about the data source behind the portlet.
There are a few scoping worksheets available, but they can be confusing. We do not want to get too much into design of the portlet or set of portlets at this state. Most teams will not know enough about the portal framework at this point to make good design decisions anyway. Decisions about topics such as portlet messaging should be left for the full design session for each portlet.
At this stage, there are only a few additional points you need to consider. For each portlet, or set of function points, consider the following:
- Identify the role and main function of the portlet or application.
For example: Display a list of the current top 10 high performers in the program.
- Determine the source of data from which the portlet will retrieve, add, and edit data.
For example: Portlet will query the database for the current program and display a list of names, geographical locations, and point scores for the top 10 highest point values.
- Mock up a display of what the portlet may look like.
This might not be possible right away. Information Architecture (IA) is a bigger topic than we can cover in this article, however, we will look at design and IA issues later in this article series.
- Consider who can interact with this portlet--who can view the list of data, and who can change or edit the portlet configuration.
Start breaking down your users into roles so they can be mapped later into LDAP groups. This includes end users as well as different administrators within the company if necessary.
Figure 3 illustrates a sample spreadsheet that you can use to begin this initial process of outlining pages and portlets.
Figure 3 - Scoping the portlets in a portal
If you have all this information before you conduct a portal workshop, then you are ahead of the game. As consultants who have handled many of these workshops, we like to start the first morning with a review of the functionality and some whiteboard drafts of the functionality that the portal will offer. Beginning with this set of information, an architect can start to focus on your particular requirements, and help you map out an initial design plan.
There are many tools, or work products, that you can use to help get you started in defining the basic requirements of your portal. These artifacts can provide you with ways to get over the hype of methodologies, or the current "flavor of the month" technique, for your project. The ones we have chosen are a few that we think are reasonable, and are simple enough to help you record your portal requirements with enough detail to continue.
Our initial set of work products for portal requirements includes the following:
- Content inventory
- Content taxonomy (not to be confused with portal taxonomy)
- Page and portlet matrix
- Portal taxonomy and navigation (also known as Information Architecture or IA)
- Application and services inventory
- Content and services map
Some of these work products are simple spreadsheets in which you identify and document major decision points about your portal. Let's look these in more depth.
If you are designing a content-based portal, then the content inventory is of particular interest, especially if your portal will replace an existing group of Web sites or intranets. The content inventory provides you with an account of the content that will be migrated into the portal, and with the data to calculate how much effort the migration will require.
For new portals that will not use existing content (which is not usually the case) the content inventory can help the stakeholders start to think about the type of content that will be produced for the portal. This work product is the beginning of the content taxonomy, and helps you to organize your ideas regarding content for your portal.
For transaction and collaboration portals, this work product has less importance but is still a good practice to develop. It helps you to clarify your requirements for content which, no matter how small the requirements are, you will still need to address. For these two types of portals, see the services inventory and map work products for help on gathering your functional requirements.
The main purpose of the content inventory work product is to create an accurate account of all existing content, and to get statistical data including the number of pages and types of content that need to be migrated into the portal. In addition, this document helps you identify who owns, and who is responsible for, producing each type of content. Then, when you are ready to perform the migration, you know the content owners who should be involved in that process. The content owners are also important contributors in the event of reformatting or re-purposing the information.
Table1 shows a sample content inventory summary that was used to help estimate the amount of time it would take to migrate content from a group of Web sites into a portal project.
|Number of URLs listed in the inventory||558||169||221||897|
|Number of web applications surveyed for migration to WIN Portal||69||25||28||98|
|Number of content items currently NOT distributed via the Intranet that departments may want to post on intranet||84||4||10||95|
This inventory example illustrates three different geographies: Americas, Asia, and Europe (EMEA). The number of Web content items to be migrated from the Americas geography outweighs those from other geographies by a sizable margin. This could have implications when the time comes to migrate content into the new portal. Depending upon the time frame of your initial rollout to different audiences, and what they might expect, it could take a lot more effort to migrate the existing Americas information then for the other geosThis type of information can be discovered while doing a content inventory and it will prove to be very helpful later in planning and scoping your project.
The content inventory is a "living" document. It becomes out-of-date the moment it is completed, and will continue to change with time, as you approach the release of your portal. Therefore, you need to define a maintenance process very early in the project, so that it is updated and kept in sync with any changes made to the sites which the portal is intended to replace. Establishing an content inventory maintenance process can help create a transition strategy which makes content owners accountable for reporting their content publishing activities, and which provides key information about the content. This transition strategy is critical to the successful migration to a formal Web content management system in your portal.
The content inventory should include most of the following properties for each content item:
- Location, such as URL, path of a shared drive on the network, or location on a content repository.
- Name of the content owner or creator. This person is responsible for updating, and archiving or retiring the content item.
- Contact information for the content owner.
- Intended audience for the content, such as a department, a division, or a role within a group.
- Name and description of the content item.
- Language or languages in which the item is written. There may be several copies of the document in different languages.
- Priority for migration. A priority release will help determine whether or not a piece of content is migrated into the portal content repository. You can also use this information to determine the size of the migration effort.
One underlying aspect that needs to be considered is the security around different components of the portal. Security provides the means to ensure that content or applications are available only to those users who are authorized. Unlike customization, which we will discuss in a minute, security is based on policies created by system administrators to enforce corporate and departmental defined access controls. The user has no choices when it comes to security. In most content or access implementations, security is set in a binary fashion -- users either see the content or they don’t. In most cases there is no in-between state.
Portal security controls the level of access to all the portal resources, including content. Security controls for most resources are applied based on group membership and user attributes. If security is an issue for some of the content you are migrating into the portal, then now is the time to start examining how that will be handled in the new environment. Many implementations delay this effort and allow only public or "internal public" information into the portal until they better understand the capabilities and limitations of the portal framework. In some cases, however targeted and personalized content is the core of the new portal itself and, as such, becomes the majority of the effort.
In addition to content, portal resources include tabs, navigation menus, pages, portlets, portlet skins, portal themes. Access to all these resources is managed based on roles and group memberships. When a user is a member of a specific group, then that group can be assigned to a role that is entitled to access resources for which the security policies allow.
According to the American Heritage Stedman's Medical dictionary, taxonomy is "the classification of organisms in an ordered system that indicates natural relationships."1 This definition works pretty well for a content or portal content taxonomy. We also need to distinguish between a portal taxonomy and a content taxonomy, which are closely related, but are not the same.
A portal information taxonomy (or Navigation Taxonomy, as usually defined within the field of Information Architecture) is the orderly classification of terms used to navigate the portal. This includes all types of navigation such as tabs, pages, portlets, and, in some cases, permanent content links inside some key portlets; for example, links created in a bookmarks portlet. This classification is based on the natural relationship of terms using either formal definitions, or implicit terms, which are understood the same way by a particular user community of the portal. In other words, the portal taxonomy is designed with the portal end user in mind. See How to create effective taxonomy for some of the basic concepts needed to create an information taxonomy.
On the other hand, a content taxonomy is the internal taxonomy, used in the content management system, to classify the content based on the specific needs of the content creators and content owners.
To facilitate content and template creation, decide on the taxonomy guiding principles before starting development work. You lay out the foundation for the metadata to be defined for each content type, and determine how the content is organized, based on natural relationships. Also, try to develop an initial high-level taxonomy as soon as possible, even if all the content has not been defined.
Figure 4 shows a sample content taxonomy, which follows a geographical approach. It uses only three levels, which is a best practice to keep the structure flexible.
Figure 4 - Content taxonomy
The page matrix is a work product or artifact you create to document all the pages and portlets that the portal will use. This work product is created after the information architect has defined the portal taxonomy. It uses that taxonomy to lay out which elements become pages, and which ones become tabs or sub-pages. It also helps to round out the design by showing the information architect how the taxonomy gets implemented at the page level.
The page matrix in Figure 5 is pretty similar to what we started to create when we were scoping the portal. Taking a second pass at the matrix, we start to add additional information that will be useful during the requirements and design phases. This matrix can become part of the portal requirements, by taking this matrix back to the business sponser for validation of the security and permissions for each page and of certain portlet information.
Figure 5 - Page and portlet matrix – revised
The portlet matrix is an artifact that shows as the parameters for each portlet instance what will be implemented in your portal project. It contains a list of portlets and their associated properties, such as security requirement, personalization and customization requirements per portlet, and types of views desired per portlet.
Figure 6 shows a list of commonly gathered portlet properties or attributes in a portlet matrix.
Figure 6 - Portlet properties
For content-based portals, after you have gathered your portlet requirements on the page and portlet matrices, and you have also documented your content inventory, you need to map the content that will be displayed on specific pages and portlets in your new portal. In a large organization with hundred of thousands of users, this task can be very daunting. Our word of advice for this task is (as we stated earlier in this article) summed up in two words: incremental releases.
The implementation of a portal is already a complex task orchestrating systems integration, streamlining business process, and managing internal politics. So, if your content inventory is on the order of the tens of thousands of content items, we suggest you release that content incrementally. We know you may face very stiff opposition on this issue; however, the welfare of your project is really at stake here. This task of content mapping includes content re-purposing, reformatting, and, ometimes, adding new workflows for content publishing approvals. It is not trivial. In large organizations it requires the involvement of many departments and multiple company locations.
To generate a content map will need a content inventory, a content taxonomy, a fully developed portlet and page matrix, and a fully approved portal IA (or Navigation Taxonomy). The end work product is usually not one document but a series of documents which explain how the existing and new content will be deployed into different portlets and pages throughout the portal navigation schema. It also involves rules for personalization and customization, if these are part of your project scope.
The services inventory and map is a work product that helps you define the list of services (or applications) your portal will deliver to the user community. Services are any size application that enables users to execute a transaction, which could be as simple as a query to a database or as involved as the execution of a batch process which updates thousands of records in a back end system (such an ERP or a CRM system). These could be remote applications, such as remote Web services, which need to be integrated with your portal. These applications do not all have to exist, but for the ones that do, you need to define all the required elements for integration.
For the services that will be developed as new functionality, this work product can help you gather basic requirements regarding target audience (that later on translates into user groups), and integration points necessary to make the access to these services as seamless as possible for the end user.
The three main purposes of this work product are to:
- Define all the attributes required for these services in order to be integrated or developed into your portal
- Identify the business and technical owners of these candidate applications for portal integration
- Identify the target audience for the candidate services to be provided by the portal
The services map in Figure 7 shows a typical services and application inventory with some typical attributes gathered to document technical requirements for the integration. The functional requirements gathered will be constrained by the sum of functionality of these applications together with the additional capabilities that the portal can provide.
Figure 7 - Services map
Personalization and customization are similar and many end users cannot distinguish between them. However, there are clear differences between the two.
Customization is something we find in our daily lives. For example, when in a restaurant, it is quite common to request changes to a meal. We request these changes and adjust the menu to our preferences. In other words, we "customize" the meal. Similarly, customization on the Web, involves the user making changes to the "default" user interface, the layout, and to the content being presented based on his or her specific preferences.
Personalization, on the other hand, is more about matching content with the user. For example, when you visit your doctor, the nurse first identifies who you are. By asking you a few questions she verifies that you are who you say you are. She may also ask for your social security number, or an ID, or ask for your home address. Next, the doctor may proceed by asking you for a few very personal questions, such as the reason for your visit, and any symptoms that you may be experiencing, if you are ill. Then, the doctor takes that information and adds it to your personal "file". This file contains a wealth of information about you. It provides the physician with information that enables him to provide you with very "personalized" treatment. The physician wants to make sure that if he prescribes you a medication that you are not allergic to that medication, that you will not experience negative side effects, and so forth. This is matching the level of service to the user. This is very similar to how personalization on a Web portal works. Based on a user profile, personalization uses rules to match the "services", or content, to the specific user.
To some degree, you can think of the two like this: customization is in hands of the end user, personalization is not. Of course actual personalization is often based on your role or job function within the portal context.
What the user sees in a portal is determined by the integration of the various scoping mechanisms we have described in this article. Figure 8 illustrates the filters that are applied to achieved the "individual user's view".
All content must be tagged with content attributes and metadata, including those for security policies, by content administrators and portal administrators. It is also tagged for specific target audiences. Each of these attributes helps to determine which content is provided for which user.
- Security view. This filter shows that content--out of the entire universe of available portal content --for which the user has access rights. This view is created and enforced by the content administrators and portal administrators (and within the content by the content owners).
- Personalization view. This view further filters the amount of content the end user views, by applying personalization rules which have been created by the line of business. This view is created by the lines of business by defining the personalization rules applied to each individual portlet.
- Customization view. This view applies the end user’s preferences to further filter the content being displayed. This view is created by the end user by making changes to the user’s profile, and by editing portlet subscription to content channels.
Figure 8 - Users viewpoint
There is nothing worse than making it through a difficult project and then having problems at the end. Not being able to take a site live because it won’t stand up to testing or use by your end users, is not only hard on the soul but also can be very hard on your career! Worse yet, is the site that goes live and then crashes on the first day because not enough testing was put into it, or it was designed and created without the proper experience and subject matter experts. In many cases, it has been "back to the drawing board" and calling in the highly paid specialists to help fix a problem that could have been easily avoided with some up-front diligence.
This series is designed to get you started off on the right foot. By following some of the recommendations outlined in this series and calling in some experts early in the process, you can avoid many of the problems that other teams have had. Hopefully, you will learn by these efforts, and avoid extreme but not uncommon situations by understanding some of what it takes to build a portal and how to succeed in your effort.
In the future articles, we will follow the project process to define the scope, and then design the portal leading toward implementation, and finally --go live. We do not expect that every project will use every work product or will follow every bit of advice. Sometimes your needs are pretty simple, but you can make use of some of these ideas as you embark on your own portal adventure. Stay tuned for the article on the Portal Workshop.
Methodology discussions, like other topics in the consultant realm can sometimes lead to the most religious of debates. Experienced practitioners often have a favorite-- usually some variation of a well-known process that they have derived through countless experiences of their own. This, however, is not always the case. Many times there is no real process in place, or at least none that can actually lend support to a project.
Most of us believe that there must be some type of method or process in place for a project to be successful. While this is generally true, the size and scope of the project may allow you to be successful with smaller projects even when your processes hinder more than assist your effort. There are several excellent and well-documented methods in general use to choose from, and many organizations have adopted one or more of these approaches. However, where teams often fall short, is actually implementing or following the process as it was intended. Lack of training, no expert support, or turnover of new team members, can reduce the effectiveness of even the best-defined process.
Consequently, we are strong believers of using some methodology in your portal projects. However, while working in the field with customers we have found so many aberrations on implementing methodologies that we have tried to classify them so you can identify (hopefully early on your project) where your project may have problems, and you can take corrective action accordingly.
Method Category 1: The Ad-hoc or No Method: This team has nothing but an idea and a deadline. While not doomed to complete failure, expect a lot of missteps and communication problems during the lifecycle of this project. The team talks lazily of requirements and design, but often every member or sub team has its own idea of what to do, when it should be done, and what work products to deliver (or not). Generally documentation is an afterthought, if it is thought of at all.
Method Category 2: The Stone Idol Approach. This team has a highly praised method or process within their organization that no one on the team really knows or understands. Many of these teams have industry standard certifications or high-level rankings in a well-known process, but as organizational changes occur, training subsides, and experience or leadership disappears, they fail to understand or follow the standards set within their own organization. To many internal teams, "The Process" consists merely of bureaucratic forms that have to be filled out at regular intervals.
Method Category 3: Adopt the Newest Favorite Approach. At the beginning of a project the team attempts to adopt a well-known methodology. Sometimes the team is handed a dictate by an over-eager manager that the team will adopt or follow some well-known process. While this is great long-term strategy, it almost never works in practice on a project with a tight schedule and budget. Sometimes things fall short due to lack of proper training or experience in the process. Often, time and budget constraints force the team to cut corners and the method (which was never fully adopted) falls apart completely.
Method Category 4: The Bureaucratic Method. This is pretty rare and is usually found only in large organizations. This team has a very well defined process that puts limits on the team as they move forward. Templates, forms, committees, and review boards can slow down even the most eager of teams. Team members are usually well trained, and have experience in how the process works, and understand the hoops to be jumped through at different times. Sometimes there is work to be done to modify the process or work products to fit for a portal project. As a new team member there is usually a lot to learn about the process. This approach will almost always slow the project down.
As you read through some of these descriptions, you might have recognized a few traits within your own organization or project. More than likely, it will be difficult for you to fix all the process problems and still deliver your portal on time, however by providing you with some knowledge and support, you can succeed in your project, regardless of which category you fall into.
Even teams that don’t fall into the above categories may have issues. Often within a project, team members are thrown together from different areas and locations to staff the team. This can be the case both with outside consultant teams, as well as internally staffed projects. When staffing a project or putting together a plan for bringing resources together, experience and expertise in technical or business areas are often at the top of the list. However experience or approach in a particular method is often never asked or discussed during interviews.
Even if everyone on the team, or the organization has been well trained on the specifics of a defined process, individual experience does not always lend itself well to a new collective. In other words the same process may be used or followed differently by different members of the team, which can lead to confusion at best, but more likely, chaos.
One suggested approach to working through some of these problems mentioned here is the use of a "Method Adoption Workshop". You can use this approach to ensure that some continuity between the team members or different teams is achieved. You need to make sure that proper time and training is given to all the team members, and insure that a few hours of training at the start are not forgotten during the heat of a critical deliverable. This is true with any method that is adopted, either at an organizational or project level.
- Meet the Expert: Skyler Thomas on WebSphere Portal applications answers questions about developing portals.
WebSphere Portal in Action: Read Joey Bernal's blog on developerWorks.
developerWorks WebSphere Portal zone: Find more resources to help you develop portals and portlets.
Demystifying Extreme Programming: "XP distilled" revisited, Part 1: Get an overview of Extreme Programming
Agile: Get information about agile programming.
How to create effective taxonomy: Jie-Hong Morrison discusses aspects of creating a taxonomy.
Get products and technologies
Rational Application Developer V6. : Download a trial version from developerWorks. Includes the portal tools and a test runtime copy of portal that you can use to develop a prototype.
Anthony (Joey) Bernal is an Executive IT Specialist with IBM Software Services for Lotus, and a member of the WebSphere Portal practice. He has an extensive background in the design and development of portal and Web applications. He is the author and co-author of several books, including Application Architecture for WebSphere; Programming Portlets 2nd Edition; Programming Portlets, the IBM Portal Solutions Guide for Practitioners; and from a previous life, Professional Site Server 3.0. He also contributes to his popular blog, Portal in Action.
Ian Uriarte is an Advisory Software Engineer with IBM Software Group, specializing in Lotus Workplace Industry Solutions. He is a hands-on solution architect with very good people and teaming skills as well as technology skills. He has extensive technical experience with IBM technologies and has worked on IBM WebSphere Portal since its inception. He is also an amateur guitarist and spends most of his free time volunteering for community development nonprofit organizations.