Yesterday Perficient’s portal experts held a webinar entitled “12 Things You Should NOT Do on a Portal Project”. The webinar was highly entertaining. You can view the entire webinar here.
Considering the growth of social media, collaborative care, and patient engagement in healthcare, I felt it was important to recap the 12 things not to do so that healthcare organizations do not fall into these traps.
#1 My Missing Homepage The portal team started out with a story of an insurance organization that was juggling multiple portal projects. In this particular case, the developers of a latter portal project co-opted the homepage of the earlier portal projects. This caused the homepage on earlier portals to disappear completely. When juggling these portal projects, it is a good idea to set up a shared taxonomy so that this confusion does not occur.
#2 The Business Asked for it! Each organization sees itself as unique. Therefore, when considering their portal needs they end up building custom applications, which are often much more resource intense. There are many “portal in a box” solutions available on the market. Oftentimes, these out of the box solutions can be used to meet 95% of the business requirements you are looking for. By starting with an out of the box solution, you can then add custom components where needed. Your portal project will become far less resource intense as a result.
#3 Methodology for Methodologies Sake This one actually captures what I say time and time again: start with the business problem. IT geeks love technology for technology’s sake. However, it’s not very rational to implement expensive technology solutions simply because they are cool (although they most certainly are). If you don’t lose sight of what is important, then the end result of Health IT will be highly functional for the end user.
#4 The Never-Ending Strategy It is good to start with a portal strategy. The strategy sets the overall direction and approach for your project. According to our pros, the strategy should prioritize the direction of architecture, content, governance, security, development, search, etc. This can be put together within a 2-4 week roadmap. A bad or overly complex strategy will actually slow down or inhibit the launch of your portal. Focus on solving the business problem; don’t become a slave to strategy.
#5 I Built it But Now I Can’t Support It Technology projects can be complicated. A portal project requires knowledge workers with skills in architecture, security, training, web technology, etc. Some organizations choose to cut costs through minimizing the number of people resources they use to build or support their portal. This can often be a recipe for disaster. The problems that surface can end up multiplying the cost of the portal project well above the savings found through cutting corners.
#6 We Can Get a Big ROI from Portal Our portal experts highlighted a story of a company that wanted to cut time from their processes in order to increase ROI. However, they implemented a portal project that actually added time to their processes and gave them a negative ROI of $2.3 million/year as a result! The main issues were: 1) lack of strong technical resources that understood portals and 2) their portal solution lacked user experience capabilities. Mitigating these issues would have informed developers of how end users would use the system, which then directs implementation.
#7 Is Best of Breed Always Best There is a time and place for both best of breed portal or the one vendor stack portal. Stop debating and consider your needs. Sometimes best of breed is best. Sometimes the one vendor stack portal is actually best to meet your unique portal needs. Match your requirements with the available options, and you will be fine.
#8 When Developers Can’t Develop Sometimes a portal administrator puts up a wall to developers. As such, any time developers need to make a change they need to work through this portal administrator, which creates a bottleneck. This is particularly the case when the portal administrator isn’t the best person for the solution at hand. There is oftentimes creates stand offs between portal administrators and development teams during a portal project. Decision making silos occur, and the parties lack insight into what the other is doing. Everyone should work as a team.
#9 When Not to Use a Portal There are times when portal is not the correct solution. Sometimes a “side-by-side” approach is best. Side-by-side is an approach were portal and other complex applications live side-by-side. Don’t use an overly complicated portal as a full interface when a side-by-side solution would be best.
#10 When Web 2.0 is 2.Much Once upon a time there was a company whose implementor decided everything should be done using Ajax. This didn’t work out for them since their portlet simply served content. According to our portal experts, any portlet that only servers content should never be implemented with Ajax.
#11 Infinite Loops on the Homepage Portal implementation team members can lay awake at night hoping their server doesn’t crash under the weight of resource overload. The key to a restful night’s sleep in this case is testing. You should perform a series of tests to catch any and all possible errors that could cause a rogue portlet to bring your entire site down.
#12 Building My Own MVC Our portal experts told the terrifying story of an architect who felt that Java Server Faces, Spring MVC and Struts were not good enough so he designed and built a custom Model View Controller (MVC) framework for development in WebSphere Portal. All went well until he left the company. You do not want a single source of failure. As such, it is best to first look at what is available when development needs come up.
