Software Package Selection Framework
Software Package Selection Framework
All organizations are faced with the challenge of introducing a commercial off-the-shelf (COTS) software package to support its current and future business needs, yet management does not have the expertise nor experience to apply a proper criteria in order to ensure the optimal selection of such a software solution. There are some key considerations that the organization must keep in mind when undertaking a software selection initiative:
• Corporate Goals & Objectives: What are your growth goals? Efficiency goals? Speed to market goals? Regulatory requirements?
• Current Requirements: What do you need right now? How much configuration versus customization is required?
• Future Requirements: What future requirements do you anticipate? Does the vendor provide a roadmap, what is the frequency of releases? What are the costs, risks, and impacts of transitioning away from this technology? How much influence do you have over the roadmap?
• Functional Software Requirements: Do you have defined business processes to which you must map system functions? What are the functional needs of your company and will these govern the software features that are most important to you? Does your specific industry dictate functional and/or regulatory requirements? Be mindful of all the functions that occur in an average business day, and aim to review all the areas on the list even if your current processes are currently being done “outside of the system” on spreadsheets or whiteboards.
• Underlying Technology & Future Scalability: Is the solution compatible with the underlying technology and infrastructure? Is the solution scalable in regards to functional footprint and geographic expansion?
• Ease of Implementation: What platform does it require and is your IT capable of implementing and supporting it? How difficult is it to integrate with existing systems and applications? Is it scalable in terms of existing IT infrastructure? Are there single points of failure, and what recovery mechanisms are available?
• Supportability: What training is provided? Consulting? Documentation? Community? How stable is the vendor? If the vendor is also intended to be an integration partner, how aligned are you technologically and culturally?
• Budget & Resources: How much will it cost to implement (license, hosting, customization), maintain, upgrade, modify? What resources are required to deliver the solution?
• Ability to Deliver: If customization or extensive configuration is required, will this be facilitated through standard APIs or manual customization? What testing capabilities and automation are provided? How difficult is it to automate installation, configuration setup, and builds? Is version control provided, and can it be integrated with your existing configuration management system?
• Trusted Partner: Who will implement the software solution? Who will manage the project? Who will support it when needs and/or processes change? The choice of people, both internal and external, is probably the most critical to the success of a software implementation project.
IT Architects provides a service to conduct a complete and robust software package selection process using a framework which takes into account the key considerations above, as well as additional non-obvious considerations that must be addressed in order to ensure that a viable and future-proof software package is selected for your organization. The following identifies the software selection principles that are followed by IT Architects in helping an organization make an optimal software selection decision:
• Minimize Customization. Heavy customization results in additional cost and effort of future upgrades. This requires your organization to modify its business processes to align with the package rather than vice versa. Generally, you should not be considering packages for strategic business processes and/or capabilities, unless a system of differentiation is required that cannot be sourced otherwise. Thus, the organization must be very clear about and enforce boundaries to prevent package features creeping into strategic areas. Once organizations introduce customization, the importance of being able to setup automated testing (as well as other development features) grows. IT Architects’ rule of thumb is: If a COTS solution requires at least 25% customization, it’s cheaper in the long-run to build a custom solution.
• Use Scripted Customization Scenarios (if Customization is Required). Scripted customization scenarios may be even more important than scripted demos. In a customization situation, you want to assess the modifiability of a package in a consistent way by providing several customization scenarios and seeing how vendors are able to respond.
• Use Out-of-the-Box and Only Configure to Support Business Processes (which Cannot be Changed). Configuration, especially if extensive, should not necessarily be treated with any less rigor than custom development. Customization or extensive configuration highlights the need for alignment to existing business processes which are unique to the organization.
• Adhere to Organizational Mandate. Base software solution selection on organizational mandate whether it be regulatory/policy direction, emerging technology direction, alignment to industry practices, future change adaptability, integration into existing IT landscape, testability, modifiability, etc. Especially with typical COTS packages such as CRM, ERP, financials, the main options tend to have feature parity which means you should generally focus on other aspects.
• Reduce Commitment (Rather than Attempt to Commit to a Perfectly Correct Decision). If the package does not require as much commitment (e.g., specific cloud, hosted service, third-party outsource, etc), the organization should maintain options to change its mind later and doesn’t need to worry as much about making an optimal decision up front. The factors that increase commitment are primarily the size of the initial investment and the cost of migrating data. The size of the initial investment is about sunk cost fallacy which makes it a psychological/political factor, not an economic one. Thus, it’s not always a matter of picking the right technology, but picking the technology which is cheapest to move away from.
IT Architects has undertaken many mission-critical software solution selection engagements, and provides a proven software package selection framework and expertise to: 1) Analyze industry trends, 2) Engage the client’s workforce, 3) Prepare system roadmaps based on business requirements and changes that are to be achieved, 4) Validate & evaluate vendors through reviews of current customers they serve, 5) Guide the client in managing and embracing change, and 6) Monitor and streamline the software solution once it goes into production.