The concept of a portal is not a new one, nor is the wide array of technologies that supports portal implementation. Despite these facts, many enterprises struggle with the same basic issues Why do I need to implement a portal? What is its real business value? How will it scale over time?
While the answers to these questions differ for every organization, the reason they remain unanswered is generally the same. It is all too common that an organization views portal development as purely a technology exercise the implementation of a set of software that is looking for a problem to solve.
Perhaps portal vendor X has done a good job of selling a set of features for their software, perhaps the CIO likes to stay on the bleeding edge or perhaps an enterprising young developer spends her free time building prototypes using the latest technology.
This is all well and good, but successful enterprise portal development needs to take a different, more comprehensive approach.
First, it is important to define what a portal is and what it can become. At a high level, a portal is a single point of access to an organization’s information, knowledge, applications and data for employees, customers, vendors and intermediaries.
Given this definition, an organization must define its overall business requirements (i.e., why do we need a portal?), and then determine how a portal can help meet those requirements. For example, is the portal implementation focused on internal work force efficiencies, or is it focused on generating new revenue streams from an existing client base?
Regardless of business objectives, this exercise will create a set of benchmarks that can ultimately measure the portal’s success and ROI, and help frame a prioritization plan to scale the portal over time.
User and functional requirements
Next, an organization must clearly articulate its user and functional requirements, which in turn will define user segments (i.e., who will use the portal?) and user needs (i.e., what will the portal do?). This exercise helps ensure buy-in and adoption from the portal’s users, necessary for successful implementation.
It is only after these requirements have been defined that the technical requirements discussion should truly begin. Rarely, if ever, should this be a blue-sky decision, unbounded by existing technology parameters.
Most major portal software packages are robust enough to meet basic functional and integration requirements (e.g., collaboration, document management, work flow and personalization), so platform decisions will rely primarily on existing corporate standards and specific portal requirements as defined in the previous exercises. It is important that business and user requirements drive technology decisions and not vice versa.
One final consideration, one often ignored during portal implementation initiatives, is the new system’s operational requirements (i.e., how will we run, maintain and enhance the portal over time?). This exercise helps determine processes for adding functionality to the portal, adding integration points, and/or expanding the portal’s focus to include more internal or external constituents.
Without defining these processes early, the portal can evolve into a motley collection of visual interfaces, content areas, data structures and integration points, thus defeating the efficiencies that were part of its original goals.
By clearly defining business and user objectives, and by allowing these objectives to drive the technology and operational decisions that govern portal implementation, an organization will maximize the benefit of their portal development and implementation.
Matt Henry is director of sales at CIBER’s Philadelphia office. Reach him at (610) 993-8100 x237, or at email@example.com.