Here is a story of how a major hotel chain instantly got a huge ROI on portal… in the wrong direction!
What Happened
A major hotel chain had a metric that for every second they could cut from call handle time netted $108,000 a year in savings. It is easy to see how converting the aging reservations application to portal could save significant dollars. The existing app was an X-Windows desktop app and when it was converted to portal, call handle time went up 22 seconds for an instant ROI of negative 2.3 million dollars per year!
What Should Have Happened
There were 2 main things that went wrong on this project, either of which would doom any project to a colossal failure.
- They did not have strong technical resources who understood portal technology.
- There was no user experience aspect of the project to understood how reservations agents would use the system and how it could best be implemented in portal.
Regarding 1) a team of java developers were just given portal to do a straight port of the capabilities and screens of the existing reservations application. There was no strong technical leadership to insure that the technology was being used properly and to its fullest extent. As an example, one java class alone was over 2000 lines long. Additionally, the McCabe Cyclomatic Complexity (which measures the unique possible code execution paths) had several classes with values of over 20,000. A Cyclomatic Complexity greater than 50 is generally considered untestable. As a futher example, one class had 13 levels of nesting. This is essentially impossible to follow.
Regarding 2) porting a desktop application almost verbatim to the web will never work. It is critical to always understand how users will use and interact with a system. Formal usability design and testing should have been undertaken on this project at the start. This would have allowed interaction designers to understand and test how reservations agents needed to use the system and design an application which would best suit their needs. This design can start with pencil and paper and does not need to wait until a final product is available for testing. In fact, starting earlier engages users better as they feel they are involved in the design process and not simply testing a finished product. Correcting mistakes at this stage of the project is significantly cheaper (by tens or hundreds of thousands of dollars) than waiting until the end. And lastly, when undertaking a user experience design like I am suggesting, do not forget to always involve a portal architect who completely understands all of the capabilities offered by portal. The role of the architect is not to influence the design but to instead validate that it can be implemented in portal. Additionally, the architect will be able to communicate portal capabilities to the user experience team (such as personalization, themes/skins, localization, WCM, etc) that they might not have known were at their disposal, letting them incorporate the desired features into the design.
Ultimately this customer wound up doing a formal user experience analysis and design as well as bringing in highly skilled portal resources; however this was at a greatly increased financial and timeline cost over what it would have been at the start.
Previous Installments
- Where’s My Homepage?!?
- The Business Asked for It
- Methodology for Methodology’s Sake
- The Never Ending Strategy
- I Built It But Now I Can’t Support It
Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth. More Info / Register
Pingback: demotivator