January 21, 2021
Hot Topics:

Top 10 Portal Projects Killers

  • By Scott Nelson
  • Send Email »
  • More Articles »

5. Random or Pure Agile Approaches

Many Agile practices are well suited for portal development. Some will cause the very problems that Agile methodologies are meant to solve. One such practice is that all developers work on all code. Although it is important that knowledge islands be avoided by making certain at least two developers can work on the same functional area, portals by nature contain features that are best owned by those who are specialized. A rich user experience is difficult (if not impossible) to achieve if every developer is expected to understand the presentation as much as the control. Really talented portlet developers often do not have the 5,000 foot view necessary to manage the placement and navigation of the portlets they develop. Writing test classes first makes perfect sense for isolated components but will lead either to useless test cases or very slow time to market if applied to every feature within a portal. Because of all the moving pieces in a portal, allowing any developer to run integration builds will lead to frequent build failures and delays while the cause is traced down. Having only a few people run the builds who understand how all the different pieces are supposed to interact and making sure that each developer communicates the needs of their work to these build masters will provide the productivity results that are one of the key goals of Agile methodologies.

6. Politics

If death and taxes are inevitable parts of life, bugs and politics are inevitable to software projects. Even though neither can be avoided, the impact of politics can be minimized by coming to a consensus of the portal goals and selecting a person or group to act as an unbiased party that will arbitrate conflicts and manage timelines.

7. Combining SOA and Portal Initiatives

Ask any of the current portal vendors and they will tell you that portals are the web presentation layer of a solid SOA strategy. Althoug this is absolutely true, it is no coincidence that vendors remind you of this constantly because most (if not all) portal software vendors also have SOA infrastructure applications. And, it is definitely an improvement to both SOA and portal ROI to take advantage of any bundling discounts this can lead to. But bundling the SOA and portal implementation as projects within your organization can spell disaster. Politics (mentioned earlier) will become involved. The constant communication of dependencies can lead to delays that will eat up the budget saved in the software bundling. There will be conflicting directives as the groups that manage the two technologies are rarely the same. The only way around the delays are compromises that will lead dissatisfaction to users, developers, managers, or all three.

The two technologies do compliment each other, and the important thing is to work at creating a synergy that gives the advantages and avoids the conflicts. The two groups should communicate their plans and needs to each other and develop with future integration in mind. Waiting for a service or expecting a service to be deployed to dovetail with portal release cycles can lead to delays and rushed re-work.

8. Misallocated Outsourcing

Most projects these days require some outsourcing for cost effectiveness. When outsourcing portal design and development tasks, the right mix will improve ROI and time to market. The wrong mix will achieve the opposite and then some. This mix will depend entirely on your individual organization and there is no simple solution, only some simple advice. If IT development needs to be done within a short period of time, either outsource all of it to one provider, bring in experts to work onsite with your team, or keep it in house. Once you have established a pattern of how your portlets are designed and integrated, you can start dividing the tasks, but not until then. If you outsource your UI design, make sure that the UI vendor has deep experience with the portal framework you are using. Finally, re-evaluate what to outsource and what to keep in house continuously as the portal and your needs evolve.

9. One Stop Shopping

Not all portal frameworks are equal. This isn't to say any particular one is better than another (author's opinion aside). What this means is that different frameworks provide different features or similar features in different ways. The decision to buy a portal framework is based on not wanting to have to deal with all of myriad pieces that are part of a portal individually. Trying to pick a framework that will do absolutely everything you need they way you need it is a good way to either lose time to market while evaluating, ROI on cost, or usability when all features are found but some number are poorly done. It makes sense (and saves dollars) to try to get the most in one place possible, so long as you remain flexible to consider integrating multiple pieces are creating some custom features to achieve all of your specific portal goals.

10. Looking Inward for Direction

The purpose of portals is to aggregate access to applications. Even though this will definitely (if done well) result in a ROI for IT, it all becomes meaningless if no one uses (or, if forced to, likes to use) using the applications from the portal. Even if the initial launch of the portal is a smashing success, losing touch with the users will simply lead to a delayed failure. Pushing out more and more applications without discussing with users what applications they need, how they want to be able to use them, and how they use them in combination with other applications will lead to a portal where the number of users (or satisfied users with a captive audience) will decrease with each release.

Avoid growing your portal into a deployed failure by actively soliciting user input, comment, suggestions, and requests. Most importantly, if they say something doesn't work for them, remember that they are always right and the only solution is to find another way to satisfy them or seek out a different user base—whichever one doesn't kill your portal project.

About the Author

Scott Nelson is a Senior Principal Portal Consultant with 12 years of experience designing, developing, and maintaining portals for manufacturing, pharmaceutical, financial services, and real estate companies for use by employees, customers, vendors, franchisees, and executive management.

Page 2 of 2

This article was originally published on June 24, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date