Software 101: Steps to Consider Software Selection
A key element of digitizing is selecting software, the right software. The right software underpins successful digitization on multiple levels, including improving engagement, easing communication, and increasing efficiency. In fact, the right software may be downright essential to not just the success of individual projects, but also to delivering on key digital business objectives.
But, to keep things focused, let’s solely consider the impact on projects. Software can be used for ten years or more and serve as the foundation of basic business processes, leading to a substantial overall total cost of ownership (TCO). By extension, the time spent choosing the right product can have huge ROI and long-term positive effects.
But, while buying durable products is more straightforward due to the expected range and depth of use, software can have additional considerations that complicate the buying process, just a couple to consider are different cross-departmental needs and changing requirements over time. To address these and other needs while delivering the most ROI, what’s needed is a well-defined software evaluation process combined with best practices for documenting results.
Steps to Consider
The first step is to identify challenges to software selection. Here are a few of the most typical:
The software market is large and the needs of each organization are different. Competing services and needs can make it difficult to understand costs throughout the software evaluation process.
Focus at the Wrong Level
While it’s true that you may use enterprise software for over a decade, that doesn’t mean that you should weigh long-term strategic considerations over solving issues at hand. The problem with the word “strategic” is that it is too often an umbrella term for fuzzy objectives 5 to 10 years out that will prevent your software selection team from running the detailed analyses that are necessary now.
Conducting the software evaluation process at the organizational rather than the individual level can lead to inter-departmental political issues. A few factors that frequently complicate decision-making are the personal preferences of project leaders or other influencer stakeholders, legacy software vendors or system integrators, and, of course, time or budget constraints in the selection process itself.
Pick the Right Team to Evaluate the Software
Once you understand the challenges of software selection that are unique to your organization, the next step is selecting the right team to mitigate those challenges and evaluate the software. One stakeholder won’t be enough; the selection committee should include representatives from different user and IT groups. In addition, we recommend an unbiased neutral participant–a high-level sponsor or external consultant–who can address the conflicting needs of end-users and IT groups and find the right balance between them.
Definition of Goals and Strategy
At the start of the selection process, the project team should define the strategy and goals of the software. It is most important to identify the key selection criteria, the approach to data collection and evaluation, the roles and responsibilities of stakeholders, and, finally, the timeline and budget. It should be clear to the entire committee how success or failure will be measured on both the technical and business level and specifications should be outlined for both.
Analysis of Requirements
The next step is to identify the requirements of the software. One of the benefits of opening up this process to the entire selection committee is that it is an excellent way to involve key players and generate buy-in for adoption of the eventual software. A list of criteria can include architecture, data sources, administration, information delivery, user interface, report development, performance, user-defined content, analysis and planning, available integrations, cost, and technical or customer support.
Taken a step further, selection committee leaders can access each department’s criteria holistically and come up with a master key to weigh each item. This will lead to the development of “must-have” and “nice-to-have” features that can ultimately be approved by the whole team. Of course, as the software selection process continues, the criteria will likely change. As long as the criteria change before and not after the implementation has begun, some change is acceptable if it represents a growing understanding of the business problem and software solution.
The software evaluation process typically has three different steps: first, a general screening of the market to identify possible vendors, second a shortlist of 3-5 products based on criteria and requirement matching, and finally a test implementation of the chosen product. Depending on the complexity level of the software and the size of the software evaluation team, we predict that each step will at least double the time of the previous test. So, for a less complex software, the market screening may take one week, the shortlist process, 2 weeks, and the test implementation, one full month.
Once project goals have been defined and requirements identified and weighted, the actual evaluation of the product can begin. Most software markets are complex, with several hundred vendors in the mix, and each of them constantly innovating to improve their product. On average, each vendor has 2-3 products in their portfolio geared at either different types of companies, different use-cases, different geographies, or all of the above, not to mention varied pricing structures.
The first phase of the software evaluation will likely involve a mix of digital sleuthing, pulling up saved resources, and picking the brains of peers to understand good candidates. The market screening can be more decentralized, with each software selection team member either drawing up candidates themselves or, better yet, soliciting their own team for a list.
Next, the selection committee can start to assess which software products should be shortlisted. Selection members and their respective departments can weigh the software candidates against the entire requirements list or, if time is short, they can weigh products according to the criteria most relevant to them. Either way, how much each criterion will be individually weighed by the committee should be known project wide. Once the committee has its feedback, the project manager can winnow the options down to three to five.
The last step, of course, is to evaluate the final contenders and test them in a proof of concept against all of the essential criteria. If the product is lower down in the complexity level, it may be possible to run a test implementation of two to three products. If the product is more complex and requires custom development, it may only be possible to test implement one product. Regardless, each department that will be interfacing with the product will be responsible for documenting results, all of which will be part of a final examination process to determine if the product meets the needs of the organization now and has the potential to grow with it down the line.
Software selection is a difficult but worthwhile process for any organization undergoing digital transformation. For most businesses, software is the easiest, most attainable way to start digitizing and this process can be repeated infinitely for software that may only impact one department all the way up to software that spans the entire business. As businesses grow, so will the budget, stakes, and the size of the selection committee itself, but hopefully, by then the organization should be experienced with selecting software that meets its needs.
Jonathan Toler is a digital product and innovation leader with over 17 years of industry experience at both Fortune 500 and early stage startups. He is the Head of Product & Innovation at Kloeckner Metals were he is tasked with researching and implementing new technologies and processes that will transform Kloeckner into a digital metals company.
Previous to Kloeckner, Jonathan led product management teams at Owners.com, Bridgevine, Triton Digital, and Autotrader.com. He has previously spoken at ProductCamp Atlanta,, Open Mobile Summit, and B2B Online.
Jonathan holds an MBA and BBA in Finance from Kennesaw State University and is a Certified Scrum Product Owner.