Welcome to Sagg Networks
In 1995 a group of consultants at E & Y were helping their clients select software. They found that many companies were looking for software, but there were few resources to help them in a truly objective and unbiased manner.
How to do software rationalization right
Use software rationalization to prevent the cost of maintaining existing applications from stifling strategic software initiatives.Current Job Listings
From a high-level perspective IT budgets have two parts: maintenance and strategic initiatives. Maintenance tends to grow at the expense of strategic initiatives and, left unchecked, ultimately stifles innovation. In mid to large IT organizations, this has resulted in the emergence of Application Portfolio Management or APM. APM is a disciplined approach to aligning enterprise applications to maximize business value while minimizing lifecycle ownership costs.
A lack of APM results in uncontrolled application growth, which is sometimes called application sprawl. See Appendix 1 for typical causes of application sprawl and Appendix 2 for the resulting problems. Note that APM is a continuous process and not an objective. The essentials of APM are:
This article focuses on the review and analysis of applications, which culminates in software rationalization projects. It covers cloud and off-the-shelf software, and applications developed in-house.
A simple way to identify applications in need of rationalization is to plot them on the quadrant chart below in terms of ownership costs and business value. See Appendix 3 for examples of direct and indirect ownership costs. Applications in the bottom left quadrant are prime candidates for rationalization.
Application Review Quadrant Chart
In each case, estimate the ROI of the replacement, which is the basis of the business case for undertaking a software rationalization project. Start with the highest ROI projects because they will bring the greatest return for the effort.
The software rationalization project
The core of a software rationalization project measures how well applications meet the needs of the organization, which means developing a comprehensive requirements profile that accurately captures those needs. Existing or potential new applications are measured against this frame of reference.
These is requirements list
For the purposes of this article, a requirement is defined as an organizational need expressed in a quantifiable way. For any given type of software, most organizations have very similar requirements. What makes each organization unique is how important the individual requirements are to them.
[ Become a Microsoft Office 365 administrator in record time with this quick start course from PluralSight. ]
There are three main parts to building a comprehensive list of requirements:
When developing software it is not possible to collect all requirements, but when buying software it is. Requirements are the foundation for selecting best-fit software, and those requirements need to be well written and in enough detail.
Functional requirements specify what the application must do, and most people start here. Reverse engineer features from existing applications into requirements to capture current functionality. Ask users where these existing applications could be improved and capture their answers as requirements.
Next, look at potential replacement applications. Be sure to include the market leaders in the appropriate software category, which does not necessarily mean “big name” products. When considering mid-level systems, include the mid-level market leaders. Reverse engineer the features of those products into requirements, a critical step in developing a comprehensive requirements list because it captures unknown requirements and the latest advances in the market. It ensures existing applications are compared with the best the market has to offer.
Other requirement types
Many other requirement types should be considered when rationalizing software. Sometimes these are called non-functional requirements. Examples are:
Note: some of the above examples apply only to cloud or vendor hosted applications.
Rate requirements for importance
Requirements must be rated for importance to the organization. For the purposes of traceability (sometimes called a traceability matrix), be sure to record who wants each requirement, why they want it and how important it is to them. Employees rate requirements in their areas, for example, the Finance team rates financial requirements, the IT team rates security and usability requirements, and so on.
When rating requirements for importance, consider how important each requirement is now, and how important it will be in the next 3 to 5 years. Organizational subject matter experts provide invaluable input here. If there are no people with experience in specific areas, it pays to use outside help. For example, if software-licensing costs will run into tens of millions of dollars hire a licensing specialist to help develop those requirements and negotiate the deal.
The output of this process is a comprehensive requirements profile that accurately and adequately captures the needs of the organization. Current and potential replacement software will be rated against this reference standard.
Rate applications against the requirements profile
Once the requirements profile is complete, the next step is to evaluate current and potential replacement applications against that profile. This evaluation objectively measures how well those applications meet organizational needs. Knowledgeable users should rate current applications because they know these applications and their limitations.
RFPs and RFIs
Ratings for potential replacement applications are usually done by the vendors in the form of an RFI (or RFP). One of the challenges is getting vendors to respond. One way to improve responses is to reduce the amount of work the vendor needs to do, for example by using two rounds of RFIs. With the first round, send out only showstopper requirements; usually this is about 10% of the total number. Since there is much less work, more vendors will respond. Shortlist based on the RFI responses and send out the full RFI to only the top 6 or so vendors from the first round.
Scoring RFIs or RFPs
When vendors return completed RFIs, the potential applications must be scored. A useful technique is to normalize scores: If an application fully meets every requirement, then that application would score 100%. The advantage of normalized scores is that they provide an intuitive measure of how well applications meet organizational needs.
The Fit Score is defined as the Normalized Score above but excludes requirements against which the application is not rated. By definition, the Fit Score equals the Normalized Score when an application is rated against all requirements.
The Fit Score distils and entire evaluation into one number that is used to rank applications. The advantage of the Fit Score is that applications can be compared before they are fully evaluated. By observing Fit Score trends when about 50 percent of the requirements have been rated, applications that clearly will not make the shortlist can be dropped from the evaluation.
The Gap Analysis is where current and potential new applications are evaluated against the requirements profile, and ranked by Fit Score. While it is unnecessary to fully rate every application in the evaluation, potential winning candidates should be rated against all showstopper and critical requirements, and against about 90 percent of all requirements in total. Once the gap analysis is complete and applications are ranked by Fit Score things start to get interesting.
The Fit Score objectively measures how well applications meet the requirements profile, and allows them to be compared and ranked. For example, take a post-merger scenario where an organization is deciding between two existing CRM applications, or if both CRM applications should be replaced by a market leader like Salesforce.
Some vendors can be “over optimistic” when responding to RFIs. If a new application is selected to replace an existing application, that vendor’s RFI response should be audited.
If the process outlined here was followed, applications with high ownership costs and low value were selected for potential rationalization. A comprehensive list of requirements was developed. Employees rated them for importance to create a requirements profile, an objective standard unique to the organization for that type of application.
In the gap analysis, current and potential replacement applications were evaluated against the requirements profile. The results of each application evaluation were distilled into one number, the Fit Score, which was used to measure how well applications meet organizational needs.
A data-driven analysis identified the best-fit application for the organization’s particular needs. The question of which existing applications should be kept, or if an entirely new application should be bought, has been rationally and objectively answered.