How To Recognize Key SaaS Software Differences

Software Depth and Functionality

Software depth is generally one of the most influential decision making criteria used during a software selection process. Software depth is usually measured in terms of feature sets or functionality and the overall feeling is the more the better (not necessarily accurate). Properly done, applying software capabilities to business requirements can provide great assurance for a smooth implementation and ultimate ROI. However, improperly done, will often result in implementations which bear surprises and challenges.

Over two decades we have very clearly witnessed that the top three main software selection pitfalls related to business application software functionality reviews are not taking the time to objectively understand all needed software functionality, treating all functionality as equal and ignoring the functionality after it has been identified.

The first scenario is often a precursor to the all too famous and frequently cited implementation failure rate. In this situation, organizations bypass the formal collection, analysis and understanding of their organizational requirements and fail to properly match those requirements to each potential software vendor solution. This often occurs as organizations want to bypass the Request For Proposal (RFP) because it’s a time consuming exercise, and besides, a few select staff on the selection decision team feel they know all the necessary requirements. It’s usually a given that organizations that fail to document and measure their requirements against the market leading software solutions also fail to use an objective decision making model when choosing a solution. This often results in the best sales person or the best software demonstration winning the software sale opportunity. It then results in after-the-fact software gap identification, missing software functionality, troubled user adoption and other contributors to a rough implementation.

The second scenario of documenting necessary functional requirements, however, treating them all as equal makes it very difficult to separate the forest from the trees. For example, it’s likely that a business requirement to break down the sales forecast by sales stage, territory and lead source is not necessarily equal in importance to a requirement to be able track each contacts dog’s name (nothing against dogs here and no animals were harmed in the creation of this article). Failing to apply a measurable scale in order to weight each functional requirement will cloud the most meaningful requirements among a sea of nice to have items.

The third scenario is one of completing software functionality identification, weighting and scoring, however, then ignoring the results after a vendor short list has been identified. This is often the case where the RFP is little more than a feel good exercise and the real criteria to choose the final system will be the software demonstration or other unsubstantiated subjective criteria. Properly done, completed RFP responses should provide a comparative vendor ranking applicable to your most important criteria, permit you to identify what the vendors do not accommodate well and then allow you to explore the more difficult items during a software demonstration. Simply doing the RFP to generate a vendor short list and then permitting canned demo’s does little to gauge a software product’s utilization in your environment.

SaaS business software solutions have not yet had the decades of time to mature as their client/server predecessors. Therefore, the level of functionality and capability among the systems varies greatly. Taking a methodical approach to aligning business requirements to software capabilities will prevent missteps, achieve the most trouble-free implementation and realize the maximum ROI.

Continue on to review SaaS hosted software delivery differences