|
Description
Web publishing is surely very different from collaboration, and both are altogether very different from ebusiness. Yet all of these are frequently labeled "portal projects." Even though we recognize the major differences among these types of projects, many organizations unsuccessfully attempt to use just one single portal product for all of them. To make matters worse, albeit not surprisingly, most vendors and even many consultants have a hard time telling buyers when a portal product is an unlikely fit for a specific project.
In my research I've identified seven very different portal scenarios, which I use to describe fundamentally different types of portal projects. While the scenarios may overlap slightly, they can lead to a deeper understanding of the marketplace in 2007. When interviewing organizations with successful projects across these scenarios, I noticed a few shared characteristics. It became clear that there is hard work involved in portal success, but also an imminent danger that the portal will become little more than just a pretty face. Interestingly, most of the typical, critical project challenges are virtually unrelated to technology and the choice of specific portal product.
In this article I'll try to untangle what can be a confusing market. I'll then move onto looking at portal functionality, differences in portal projects, and finally offer a few words of wisdom.
SPEAK THE SAME LANGUAGE
Before you move too fast into all the details in your project, make sure that your entire team is speaking the same language. In this young industry, many terms are often used with a variety of definitions. A portlet may seem to be a universal concept, but there are indeed significant differences among portal products. Important terms such as "collaboration," "workflow," and "design" may have very different meanings among project members.
A practical approach to defining terms is to ask a key project player to create a brief glossary with definitions of key terms early on in the process. This must be a living document, where terms can be added or modified as the organization learns. The document could be kept as a part of the project office with other relevant documents (e.g., requirements, project plan, etc.). Consider using a wiki here.
Once a glossary is established, it... |
More articles from EContent
A case of global understanding.(case study), September 01, 2007
Attention corporations: hire a journalist.(after thought)(Public relat..., September 01, 2007
Looking for additional articles?
Click here
to search our database of over 3 million articles.
|
%20%20&position=1)