I’m not that technical, but I’m frustrated that the problem with harmful URLs doesn’t seem to want to go away. Microsoft’s very own Jon Udell started 2008 with a very well written comment on .aspx considered harmful, but .aspx is still the standard default used in most SharePoint 2007-driven public websites.
Over at CMS Watch, I did follow up on Udells comment with a posting on Location matters: URLs should be short, meaningful and permanent.
Read more
I’ve been tracking Swedish CMS vendor EPiServer since late 2005. Many milestones later the company has now expanded far outside beyond its home shores, but unlike other ambitious and growing vendors, they have so far resisted the usual European temptation to attempt venturing into the US market. Quite unlike local competitor Sitecore, which have built a very visible presence in the US over the last few years.
In recent news from EPiServer they announced the release of the second edition of EPiServer CMS 5 in early October 2008. CMS 5 R2 has several improvements for editors and also a few more business user reports. Moreover, in October, EPiServer World reached 5,000 registered members, which is quite impressive for a CMS vendor community.
As a Microsoft ASP .NET 3.0-based Web Content Management system, EPiServer CMS seems to have been able to successfully fight off the immense interest in SharePoint 2007, even for public websites. Now 2 years after the release of MOSS 2007, my impression is that even Microsoft has recognised that their portal product has some shortcomings, and until Microsoft significantly improves the product, there is still a large market for website vendors like EPiServer.
Still, if you are considering EPiServer CMS for your projects, I would recommend that you set aside adequate time to select the right implementation partner, in particular if you are based outside Sweden, where competent help may be harder to find. Some European countries, like Austria and Switzerland, still don’t have any local EPiServer partners according to the listing of partners. If you are in a country without a local EPiServer office, interesting things have sometimes been known to happen when you talk to system integrators that have proposed EPiServer. Some might pull in help from HQ in Sweden, while others may work with another regional office.
Finally, I recommend taking a closer look at the detailed EPiServer evaluation in the Web CMS Report from CMS Watch.
By Janus Boye
While Web CMS vendor Sitecore has been busy promoting the new user interface in its recently released Version 6, the company has attracted quite a bit of criticism from existing customers for the new version's lack of an easy upgrade path.
In a recent blog posting by Sitecore's VP of Technical Marketing, Lars Nielsen, he discusses their upgrade strategy and explains the company's choice between delaying the release of Sitecore 6 or let the database conversion tool follow afterwards. Similar to many other vendors in this situation, e.g., Microsoft, Sitecore decided to get the new product out the door and worry about upgrades later.
The definition of immediately afterwards may extend beyond the 2 months that have transpired since V6 came out, but I see that Sitecore themselves have still not upgraded their very own website. According to Sitecore, an alpha release of the upgrade tool is expected this week, but there is no news on when customers can expect a final release.
Regardless of vendor, upgrades are never straightforward, and you typically want to wait until the vendor has gone through the pain itself before teaching them the ropes. In this case, though, it is telling that Sitecore has focused more on pleasing new prospective customers and less critical analysts alike with exciting new demos rather than supporting its faithful customers.
If the past is any guide, do remember to budget and plan any upgrade carefully.
By Janus Boye
In a refreshing blog entry from last week, Microsoft evangelist Jon Udell considered .aspx harmful. Udell boils it down to futureproofing and style.
We've been writing about the importance of URL's since 2005 (e.g. Portal Software: Passing Fad or Real Value?, State of the Art for Enterprise Portals) and in The Web CMS Report and The Enterprise Portals Report we cover the URL structure for each and every vendor.
Interestingly almost every vendor criticizes what we write about them when it comes to URL conventions, with a few open source vendors as the exception. Either the vendors with harmful URLs assert that it is a non-issue or they keep repeating that their professional services team can easily implement redirects or rewrites or other hacks to create shorter, better URLs. Rarely do they remember that if you do create redirects those too also need to managed.
With lack of understanding from the vendors, many enterprises find themselves tied to both vendors and technology. An unfortunate example is Italian car manufacturer FIAT, which uses BroadVision on their website with a URL that looks like this:
http://www.fiat.com/cgi-bin/pbrand.dll/FIAT_COM/home.jsp?BV_UseBVCookie=no
The URL is fascinating reading: You'll find the BroadVision cookie flag at the end, after JSP technology mixed with a DLL and CGI (!) earlier on. I've seen longer URLs, but the problem here is certainly both futureproofing and style, as Udell points out. I would add security to the list of problems, since a transparently programmatic URL is easier to hack.
Not only should you ensure that your site has short, meaningful and permanent URLs, but as buyers you should also try to influence the vendors so that they understand the issue. This matter is relevant to every single project, so customization should not be required. This should be out-of-the-box!
Further reading: Take a look at a 10-year old article from Web inventor Tim Berners-Lee: Cool URIs don't change.
By Janus Boye
Portal software technology has been around since 1998, and while portal implementations still often suffer from many shortcomings, the industry has also come a long way.
As our understanding of portal technology has evolved we've elaborated a set of common, sometimes decisive, portal scenarios that describe different business problems. These scenarios, however, range widely from the simple to the more complex.
While we favor scenario-based analysis, it still begs a question: can we generalize more broadly about features and attributes that are universally essential to successful portal projects? Have we learned enough to identify a current "state of the art" in portal functionality across all types of enterprise scenarios? I think so.
Many vendors call their products "enterprise portals," but our research finds that in reality, different tools do better and worse across these different scenarios -- and also vary substantially in complexity and cost. As such, scenarios are essential to help you focus on your concrete needs and project goals.
Nevertheless, portals are mature enough that we can start talking about baseline capabilities and practices. As part of my ongoing research with technology buyers for the new Portal Project Starter Kit, I've identified a set of features and attributes that any enterprise portal in 2007 should be able to boast. These range across the different services a portal offers, its technical aspects, as well as important vendor intangibles. Any portal project worth its salt will benefit.
I'll divide state of the art into the same dimensions that we employ in our evaluation reports:
Services
Technology
Intangibles
Every portal vendor will say that everything below is possible with their platform. That's because portals are, if nothing else, web application development platforms. Given enough time, money, and risk aversion, you can get them to behave almost any way you want.
The key thing is what a product wants to do natively. Each vendor with a mature offering should be able to provide these capabilities out of the box, without you having to customize the product first.
This is the web after all, even if the portal is running on your intranet. Good URL practices translate into better search results and ranking, easier use in printed media and e-mails, as well as fewer problems with broken links when technology changes. And technology always changes.
You may want to plug in a third-party workflow provider or replace the incumbent search engine. You should be able to do this easily, without worrying about complex integration.
Self-evidently useful for departmental project teams, simple collaboration should be included in any portal product. Collaboration tools cover a wide range of functionality, from discussion groups, wikis, project areas, and even the concept of presence.
This means your content and data can be organized according to your own requirements, effectively enabling you to leverage existing investments in information architecture.
This removes developer bottlenecks and empowers the business folks to change the navigation as they see fit. Also, the portal should allow designers to break out of the simple document-directory-based navigation paradigm.
Just like using the popular Google search engine, your search should not be confined to a subset of content, but rather work across all the content that resides in the portal.
Security, identity management, and ease of log-on are always important, but most organizations have already made significant investments in this area, with many having dedicated resources doing nothing else than managing user directories (e.g., Active Directory or LDAP). The portal should be able to leverage this, as well as any existing security infrastructure in place, while enabling the user to avoid logging in twice.
At some point you may decide to change the application server or middleware running underneath your portal. This change should not affect your portal. Refrain from writing proprietary or vendor-specific code and you should easily be able to switch platforms. This is particularly germane in the Java world.
Developers can be a talented, but high maintenance participant in your portal project. Letting them use their favorite tool for development surely makes them more productive.
First impressions matter and this should be a good one. A fast installation accomplished in a couple of hours can help the project move along to the real work of helping the business.
Moving code and configuration changes among different environments such as staging and production should be possible in a simple, controlled manner. An important detail here is that you can deploy changes and also roll-them back again, without having to deploy everything from scratch. Modifications made in one environment should not have to be redone in another environment, but rather a simple deployment should suffice, ideally without restarting the portal or appserver.
Without writing code, business users should be able to expose application data throughout the portal. This could be customer information leveraged by the sales team or inventory data used in the logistics department. Application data is valuable and a portal should provide a simple magnifying glass into the organization. (Of course, true application integration is another matter.)
When you grow your portal installation you should be able to benefit from economies of scale, so that each added server or cluster member should provide synergies towards a faster user experience.
All vendors and open source communities brag about the depth of available, 3rd-party portlets. Reusing and sharing components is already a great idea, but without community ratings it can be prohibitively difficult to assess the quality and usefulness of available portlet code.
Whether formalized in a user group or using an informal network, community support is a fast and effective way to get answers to your questions. Moreover, location still matters. Local consultants that can support and guide you can make a decisive contribution to your implementation.
Vendors may say, "don't worry about URLs and communities, since our wonderful standards support guarantees your investment."
Sure, unlike most other adjacent technologies (such as content management), the portal marketplace boasts many relevant technology standards. However, I encourage you to look beyond industry standards and leave it to the vendors to fight about who has the best implementation of JSR 168, BPEL, EJB, SOAP, and so forth. Don't get me wrong -- these standards matter and are helpful -- but you should look at the market from a broader business and technical perspective.
I intentionally do not crown vendors for each area covered. Different vendors perform well in different areas. So instead of discussing vendors here, I encourage you to start your analysis by identifying which scenarios you need to cover, and then moving on to researching enterprise portal vendors.
Use "state of the art" as your baseline and revisit it regularly during implementation. Your portal might get a stamp of approval from the toughest judges of all -- your colleagues.
Good luck with your projects!
By Janus Boye
Nobody likes it, but too many IT projects cannot deliver on budget. Frequently additional funds need to be allocated to meet the agreed deliverables and even then, features are often slashed in the final weeks to meet the budget or deadline.
Many articles have been written on reasons why IT projects in general are often more expensive than expected. See for example:
"Average IT project still overruns its budget by about 43 percent" (Network Computing)
Nicholas Carr: Spend Less on IT (Harvard Business Review)
"It seems as if government IT projects are doomed to fail" (InformationWeek)
Common reasons? You'll recognize the litany: weak project management, bad planning, communication shortfalls, excessive focus on technology at the expense of business processes, and organizational problems.
Of course, these shortfalls also apply to CMS projects. But in this article I'll focus on the origins of CMS-specific cost overruns. I believe at the root of these overruns lies a few common myths:
"It is just a website / intranet / portal project – how hard can it be?"
"Our recent search and imaging projects went smoothly, so why shouldn't this one?"
"We know .NET, so we can easily implement any .NET-based CMS."
"The CMS has WYSIWYG editing, so our smart colleagues in the communications department don't need to be trained how to use the system."
"Our application developers understand our network and security infrastructure."
Still today many senior level executives do not think a website or intranet is something special. To them, applying a CMS is just another project. It's about getting started, getting it over with, and then moving on to another project.
Many executives have family members, often younger ones, who publish their own personal website or blog and happily talk about how easy it is to maintain. When consultants and experts then arrive and claim that it is not so easy after all, it seems strange and hard to understand.
Introducing a content management system is far from an easy process. It causes many changes throughout the organization and affects nearly every department. A new CMS typically needs to be integrated with the existing IT landscape and even with "out-of-the-box" tools, implementation times rarely come in under 6 months.
Other additional important aspects are also often underestimated. These include:
Hardware requirements. This applies especially to content delivery (i.e. consumption) environments, which are often under-equipped, especially for dynamic page generation. And of course, the machines used by your content contributors need to perform speedily for famously impatient editors. In most enterprises it's not easy to procure additional or more powerful hardware at the last minute. Moreover, more hardware typically means more software licensing as well.
Additional modules might actually be needed after the initial deal is struck. CMS vendor salespeople are just as candid or opaque as other software salespeople. They'll do what it takes to close the deal, and they may ink a contract without telling you that additional modules will be required for your project. Sometimes these modules can be both expensive to buy and complex to implement.
There are constant requirements to patch, upgrade, revise, and improve almost any content management system. Your initial deployment rarely makes people happy; expect to really hit the mark on version 2 or 3. This leads to consistent implementation costs over the lifetime of the system, which is one of the biggest hidden expenses, and potentially a major resource drain.
Varied IT support is needed. Integration with the existing IT landscape entails content and application integration, but also working within the existing network and security infrastructure. To do this well, you need diverse IT talents on your CMS team, including system and network administrators. Particularly in a major enterprise, experienced application developers alone will rarely cut it.
The discipline is new and complex. Content management -- especially Web content management -- is a relatively new discipline with a wide variety of approaches for solving basic problems. Vendor techniques and established operational patterns are much more diverse than in, say, the document imaging community, where technical and organizational norms have ruled for some time now. As Enterprise Search Report readers know, search technologies are also deceptively complicated, but amazingly easy to test: just install, index, and show query results. The results are good, or not. No CMS project of any meaningful size ever works that way.
The lack of norms and patterns cited above gets compounded by inexperience. In most CMS projects almost nobody on the project team -- from IT to management -- has actually implemented such a tool before. Here's where an outside integrator can certainly lend expertise, but your implementation partner might solely have experience with another vendor, or an older and quite different version of the vendor's product you chose. As readers of The CMS Report know, even dot-releases can bring major changes.
This is the background for one of my old rule of thumbs: A system integrator rarely makes a profit until the 3rd project with the same version from the same vendor. Changes introduced in new versions -- or a loyal customer selecting a CMS that its favored SI does not know -- often causes the faithful partner to make an overambitious proposal, forcing them to charge high rates on any change request to break even on the project.
It is thus a potentially expensive proposition to become among the first customers deploying a new version. Nicholas Carr asks whether that "IT matters," since it does not offer any competitive advantages; I'll simply just say that there is a first-mover disadvantage in fast-evolving technology markets, most notably CMS.
I've written previously on selecting the right implementation partner. For this article I'll just say: make sure your partner has good references, with at least 3 of them using the same version as yours from the same vendor.
Many systems integrators are very technically skilled, with strong competences in Microsoft technologies, Java, or the LAMP platform. Same probably goes for your own IT group. Don't be naïve and think that this translates into a capacity to successfully implement any Microsoft, Java, or LAMP-based CMS without significant problems. The reality is unfortunately not that simple, since developers still need to learn how the system works with specific content types, its interfaces and methods, and in many cases also a proprietary development environment.
Training matters. The majority of enterprise employees might be familiar with completing simple tasks inside a browser, but rarely so for editing text and images over the web. Your marketing and communication people may be used to writing for paper, but not for the online medium. The fact that most content management systems are rarely as easy as they seemed in the sales demo compounds the problem.
On the one side the vendor claims that very little training is required. On the other side your loyal colleagues are frustrated. They are doing the best they can, but it is very hard for them to grok a CMS and how it works. To get the new tasks, capabilities, and responsibilities properly anchored you'll need a significant investment in training. Most vendor documentation is not really geared towards business managers, and you have customized your CMS in any case.
Inasmuch as getting up to speed takes time for contributors, it's quite risky to get started with the training just a week before going live. This is late in the process to discover that the training needs were underestimated. You may cross the finish line with a couple of technology-enthusiastic colleagues, but after a while these staffers will become your new webmaster bottleneck. More funding will be required to develop and organize effective training sessions if you want to decentralize some of the tasks.
Remember that the necessary organizational changes can’t be "trained" and will take time to settle. You should also realize that the most significant aspect of the training, in particular for your non-technical business users, is not tied to a specific tool, but rather in getting them used to writing suitable text for the Web, applying metadata, and generally understanding how to use the new medium.
Indeed, many enterprises face a rude shock when the 2nd year of their CMS project finds costs approximating the 1st year expenses. Experience from more mature markets (e.g. ERP, CRM) suggests that the majority of costs occur after an initial systems deployment. Be realistic, exchange experience with other companies, and avoid the surprise.
Methods such as Total Cost of Ownership (TCO) or Return on Investment (ROI) might be employed by your vendor or your implementation partner to justify the significant expense here. These models, simplistic or advanced, may not take into account all cost factors, and as such, a narrow focus on TCO or ROI can get you into all sorts of trouble if you use them as justification and then blow your budget.
Instead I urge you to focus on the value drivers in the project. What is the value for the organization to have a well run website? What is the value of higher quality content or better online customer service? What drives this value and how can it be optimized?
Costs are important, and a smart manager will estimate them properly and contain them carefully, but a visionary manager will take a wider focus on value.
by Janus Boye
In a recent Harvard Business Review article called "Your Company's Secret Change Agents" , the authors suggest a bottom-up approach to creating lasting organizational change.
Of course, content management, intranet or really any digital project can change organizations dramatically.
Typically "champions" are educated and trained with the intention that they should be change agents for the rest of the organization.
The authors argue that
"too often, these individuals generate unconstructive dependency from their teams."
I would agree with this, having often seen a "them and us" mentality in projects.
Instead the authors suggest to make the group the guru.
As they say:
"Because the innovators are members of the community who are 'just like us,' disbelief and resistance are easier to overcome."
By Janus Boye
We have been here before. A few years ago vendors were touting personalization software. A major buzzword of the dot-com age, personalization would ostensibly solve a series of business problems and enable a new IT paradigm. Many personalization projects failed due to lack of adoption, long implementation times, problems with the technology, lack of clearly defined business goals, integration and testing difficulties, and cost overruns.
Today many companies are experiencing the exact same difficulties with a new breed of enterprise software called portal software. Nearly every major software vendor has created an enterprise portal solution, which in many ways has replaced their personalization hype. Certainly the CMS market is young and immature, but I would also caution buyers that the market for portal solutions is younger and much more immature.
In fact, I question the whole concept of portal software. Based on a series of issues I have found with portal applications while working on CMS projects during the last few years, I am not convinced this is an investment each and every company should consider.
A few years ago the term "portal" emerged in connection with major websites such as AltaVista, Google, MSN and Yahoo!. A portal offered a single entry-point to content and functionality. In today’s world we have portal software, which is roughly an attempt to recreate Yahoo! within the enterprise.
But you should consider the question: What does a portal really mean for my enterprise? Your answer will vary depending on your company. More importantly ask yourself: What is the difference between a Web site and a Portal? In this article I would like to challenge the commonly-held notion that you need portal software to create a widely functional Web site.
In my view there are primarily two benefits that portal software can bring:
Enabling business users to visually arrange design elements (via pluggable portlets).
Portal vendors have taken steps towards the holy grail of enabling non technical business users to dynamically arrange and rearrange informational elements on a page. In practice, however, there is little evidence that portal users routinely modify default interfaces, and the overall design of content pages tends to resemble a stack of cards, which can be more or less usable depending on circumstances.
Enterprise Content Integration.
Portal software can certainly be useful in an intranet where the company wants to present a unified interface to many back office systems and provide a single sign-on to those systems. In my view this is probably the best use for portal software today. The important thing to remember, though, is that you are unifying the interface, and perhaps creating a crude "dashboard," but not actually unifying the underlying logic and content models unless you invest in more costly and difficult application integration.
Nevertheless, for true content integration across multiple repositories and applications, most experienced developers will also prefer to work with portal software rather than a CMS. Portal vendors -- either themselves or through close partners -- bring stronger integration facilities with superior options for rapid development and deployment.
Fortunately, today technical standards are emerging that are relevant for integration. JSR-170, from the Java community process, specifies a standard API to access content repositories via Java 2, independently of implementation. JSR-168 is also relevant as it aims to enable interoperability between portlets and portals. Unfortunately few vendors support these, and for the Microsoft-based world there are still no good answers. Both were designed by committees so contains the basic minimum set of functions supported by each major vendor. In my experience, to make use of all the really useful portlet features that a portal vendor can offer, you will end up with a non-standard portlet.
The problems with today’s portal solutions come in different flavors; business and technical.
Generally the market for these solution is immature. While portal vendors might have used various tricks to make the version number seem high, prepare yourself for challenges with unproven technology. New versions may or may not be backward compatible, service packs might require significant recoding, and do not expect the technical documentation to be entirely correct and updated. Of course, licensees say many of the same things about CMS products, but generally, portal tools are newer still.
Here is a brief overview of more weaknesses, starting with potential business shortcomings.
Costs.
Most portal software is based on an application server (either MS-based or J2EE). As application server pricing has plummeted, vendors have tried to reclaim what was lost with increasingly higher licenses on portal software. Pricing for commercial portal software is typically done either per CPU or per user. Keep in mind when you sign a software contract, that implementation costs for a portal project are typically at least 4 – 5 times the initial license fee.
Usability.
Out-of-the-box most business users will be intimidated by the user interface offered. If you speak to existing portal users they will most likely call their portal software a nice demo, but very cumbersome to work with. Arranging and placing portlets on major sites can be a very time consuming effort. As the site structure grows, the navigation load time can increase dramatically. This is a problem web content management systems experienced years ago, but most have solved today. If you add a new menu item or rearrange the navigation you might be forced to place the portlets from scratch again. Most portal interfaces were far from designed for business users but instead IT staff.
Consider the screen above (click for larger version), an out-of-the-box installation of Sun Portal with FatWire Content Server. Users require significant training before they are comfortable working in this super user environment.
Among other problems, the occasional business user will find it very hard remembering what all the button and functions do. Of course, businesspeople may have the same difficulty using the applications (like this CMS) in a stand-alone environment, but in the latter case there is at least some context and the opportunity for in-line explanatory text that the squeezed portlet environment typically does not afford.
Bookmarks.
With freedom to rearrange the design of the page, freely move portlets around, many portal users have realized that this comes at the expense of working bookmarks. This means that after brief time, visitors cannot expect their bookmarks to work, as the portlet they bookmarked might have been moved or might contain something new and entirely unexpected. Effectively the only page you can reliably bookmark is the frontpage. Any bookmarks below this level may not provide the expected result, unless you during the implementation spend time constructing the URL in a way so that bookmarks work. The problem with this implementation effort is that it runs counter to the provided flexibility to freely rearrange and reuse portlets. And unless you invest time on it, all pages will also have the same title, which makes it even harder to work with bookmarks.
Performance.
Working with portlets typically requires thousand lines of code to be executed quite often, while the end result may be just a few lines of HTML. This puts strain on servers and requires projects to invest considerable time in caching and performance tuning. . Many firms acquire expensive high-end hardware to run portal software. It is a fact that most content is not dynamic and as such there is no need to deliver it dynamically. Do consider mixed publishing (dynamic and static) as an option to reduce the hardware investments needed.
Obtuse URLs.
This is related to the bookmarking problem above. It seems like most vendors do not care about human-readable URLs. Well, humans do. Portal software is notorious for incredibly long URLs. This has several drawbacks, not the least of which is search engine optimization on public sites. Consider this URL from the BEA WebLogic-driven TDC Kabel TV, or this IBM Websphere Portal Server URL from the Copenhagen Stock Exchange.
Portal vendors have discovered the importance of content management and tackled it with different approaches. Initially most portal software was entirely without any content management functionality. This is no longer the case, as vendors like Plumtree cried out for "no empty portals," and licensees came to see the need for a concurrent CMS investment.
To get a larger piece of the overall pie, portal vendors have developed strong alliances with major CMS vendors coupled with either 1) acquiring a CMS package (done by IBM, Plumtree, Broadvision, and Microsoft), or 2) building their own CMS (e.g., Oracle and to some extent BEA).
For the business user, working with CMS and portal software typically means working with 2 different interfaces. Yes, these can be integrated into one, but in my experience this can be quite difficult and therefore few licensees actually do this.
For a web editor this must lead to the question: Why is a CMS not enough? You can draw a line between the two, as many have done, by saying that the CMS is responsible for managing content and the portal for delivery. This leaves an important grey-zone for the business user: Where do we place navigation, site structure and preview? How do we ensure that the non-technical business user can control the navigation and preview content with the actual site layout?
A really nice CMS feature is the ability to edit text directly on the site -- either through in-context or pure in-line editing. When put together with a portal solution, this is extremely tough to implement, as you then will need a way to write changes from the portal to update the CMS. What this means for many users, is that a key CMS out-of-the-box feature can not be used. There are techniques that a CMS vendor can use such as “preview this page in the portal” or using a preview version of the portal in the same editorial environment as the CMS. With the use of portlets to delivering the content to the end-user, this still makes the content manager’s job difficult as she will never be able to preview all the combinations that an end-user might select and this means the content manager can never answer a basic question; “how is this going to look on the page?”
In fact most site visitors do not require portal functionality. This is especially true for public Internet sites. I have been in many presentations where I have been asked about providing the end-user with a “My Yahoo” type experience. When I ask how many customers they surveyed to get this requirement the answer is usually “what survey?”
The last time I came across this was for a local government council office. Most visitors of local government sites don’t want to rearrange their own pages and portlets. They just want to know when the next garbage collection will be or what times the local swimming pool opens. If my local council proposed offering me a portal, I would tell them to spend the money on a decent search engine. Forget about the personalized portal experience – just show me the right content and show it to me quickly.
Most vendors now speak to the Intranet use case, or the holy grail of an "Enterprise Information Portal," or EIP. Consider, though, the top features repeatedly requested on corporate Intranets:
enterprisewide search
employee directory
common guides and handbooks
instructions and other HR information for new employees
links to commonly-used internal applications
Do you really need portal software to accomplish these? Maybe you should start by creating a small-p portal deploying a simple website on top of any existing Intranet sites, and invest in big-P portal software only after you have put in place successful processes for publishing and aggregating high-value, highly-sought information. You may find you don't need portal software at all.
In any case, don't use the crush of a software deployment as an excuse for getting organized about the information needs of your employees -- you'll probably just fail on all counts.
This is because building and maintaining any Web site or intranet requires work. Writing quality content requires even more ongoing work. Using portal software is not a silver bullet. It is complicated and will require major efforts to get up and running and to maintain. Presented with proper alternatives the business case would most likely benefit immensely from reconsidering the requirement for portal software.
About | Blog | Contact | Impact | Newsletter