Software Selection Process: 12-Week Plan From Requirements to Contract

9 min read ยท 2026-10-25

A software selection process is the structured way a team chooses business software: define the problem and requirements, scan the market, shortlist vendors, compare them with scripted demos and a scoring model, check security and references, then negotiate and sign. Done well, it gives you a decision you can defend to leadership and a team that supports it on day one.

The plan below covers 12 weeks for a mid-sized purchase such as a CRM, an HR system, a project management platform or a ticketing tool. It works for an IT lead, a project manager, a department head or a consultant running the selection. It names who owns each step, the milestone that ends each phase, how to score vendors fairly and how to present the recommendation to the people who sign.

The roadmap at a glance

Goal: By week 12, a signed contract with the chosen vendor, backed by a documented scoring decision, approved requirements, completed security and reference checks, and an implementation kickoff date. Duration: 12 weeks

  1. Business case and team (Weeks 1-2)

    Agree on why you need new software, who decides, and what success looks like.

    • Write a one-page problem statement with the sponsor: what is broken today, who it affects and what it costs in time or risk.
    • Name the selection team: sponsor, project lead, business process owners, IT architect, security, procurement and finance.
    • Set the decision rule: who recommends, who approves and how ties are broken.
    • Agree on the budget range and target go-live window with finance and the sponsor.

    Milestone: A signed charter with problem statement, team, decision rule, budget range and timeline.

  2. Requirements (Weeks 2-4)

    Capture what the software must do, based on real processes rather than wish lists.

    • Map the current process for the top workflows with the people who do the work.
    • Write requirements as user stories or scenarios, such as a support agent merges two duplicate tickets.
    • Tag each requirement as must-have, important or nice-to-have, and keep must-haves short.
    • Add non-functional needs: integrations, security, data residency, accessibility, scale, support hours.
    • Review the list with every department that will use the tool.

    Milestone: An approved requirements list with priorities, signed off by the business process owners and IT.

  3. Market scan and shortlist (Weeks 4-5)

    Narrow a long list of vendors to the few worth a full evaluation.

    • Build a long list from peers, analyst research, review sites and your existing vendors.
    • Screen out vendors that miss any must-have, your deployment model or your budget range.
    • Hold short discovery calls with the remaining vendors to confirm fit.
    • Agree on a shortlist of three or four vendors with the selection team.

    Milestone: A shortlist of three or four vendors with a written reason for every vendor removed.

  4. RFP and scripted demos (Weeks 5-8)

    Compare shortlisted vendors on the same scenarios and the same questions.

    • Send an RFP or request for information with your requirements, scenarios, integration needs and pricing format.
    • Write demo scripts from your top scenarios and send them to vendors ahead of time.
    • Run each demo with the same team, the same script and the same scoring sheet.
    • Ask for a hands-on trial or sandbox for the two finalists, with real users testing real tasks.

    Milestone: Every shortlisted vendor scored on the same scripts and sheet, and two finalists agreed by the selection team.

  5. Due diligence (Weeks 8-10)

    Check that the finalists can deliver what they showed, safely and over time.

    • Call at least two references per finalist, ideally companies of your size and industry.
    • Run a security and privacy review with your security team, using their standard questionnaire and the vendor's reports.
    • Ask IT to confirm integration feasibility with your core systems and identity provider.
    • Get a detailed implementation plan and team from each finalist, including partner involvement.
    • Have finance build a total cost of ownership view covering licenses, implementation, training and internal time.

    Milestone: Reference, security, integration and cost reviews complete for both finalists, with risks logged.

  6. Decision and contract (Weeks 10-12)

    Make the final decision, negotiate terms and prepare the implementation kickoff.

    • Present the recommendation to the sponsor and approvers with scores, risks and costs.
    • Negotiate with procurement and legal: terms, service levels, data exit, renewal caps and implementation scope.
    • Tell the losing vendors and thank them, then sign the contract.
    • Book the implementation kickoff and hand the requirements and scoring notes to the project team.

    Milestone: Contract signed, the decision documented and an implementation kickoff date confirmed.

Build a scoring model before you see demos

The most common reason a selection goes wrong is that the team falls for the best demo instead of the best fit. Fix the scoring model before the first demo, so nobody can bend the criteria to match a favorite. Weight a few categories, score each vendor on a scale such as 1 to 5, and write a short reason for every score.

Score independently first, then meet to discuss differences. If one person scores a vendor 5 and another scores it 2, the gap usually hides a requirement the team understood differently. Treat must-haves as pass or fail outside the weighted score: a vendor that misses one is out, however well it scores elsewhere.

  • Fit to key scenarios: how well the software handles your top workflows in the scripted demo and trial.
  • Usability: how easily real users completed tasks during the hands-on trial.
  • Integration and technical fit: connection to your core systems, identity provider and data platform.
  • Security and compliance: results of your security review, including the reports the vendor can share.
  • Vendor strength and support: references, implementation approach, support model and product roadmap.
  • Total cost of ownership: licenses, implementation, training and internal effort over several years.

Example: selecting a service desk tool for a 600-person company

Picture a company whose IT and HR teams handle requests by email and spreadsheets. Requests get lost, nobody knows response times, and leadership wants one service desk tool for both teams. The IT service manager runs the selection with an HR operations lead. Here is how the 12 weeks could look.

The trial changed the outcome. The vendor that gave the most polished demo scored lower in the trial because HR agents struggled to build request forms without IT help. The scoring sheet captured that, so the final decision was easy to explain.

  • Weeks 1-2: charter signed by the CIO and HR director, budget range agreed. Owner: IT service manager.
  • Weeks 2-4: 40 requirements from IT and HR workflows, 12 must-haves, approved by both teams. Owner: IT service manager and HR operations lead.
  • Weeks 4-5: long list of ten vendors, four shortlisted after screening and discovery calls. Owner: selection team.
  • Weeks 5-8: RFP sent, scripted demos on five scenarios, two-week trial with eight agents for two finalists. Owner: selection team.
  • Weeks 8-10: references, security review, integration check with the identity provider and HR system, cost model. Owner: security lead, IT architect and finance.
  • Weeks 10-12: recommendation approved by the CIO and HR director, contract signed with renewal caps and data export terms. Owner: procurement and legal.

Who owns what

A selection crosses departments, so write a RACI at the start and put it in the charter. The project lead runs the process. The business owns the requirements and the choice of fit. IT, security, procurement and legal each hold a veto in their own area.

Keep the scoring team small and stable. If new people join late and score only some vendors, the comparison is no longer fair. Invite a wider group of end users to the trial instead, and feed their feedback into the usability score.

  • Executive sponsor: approves the charter, budget and final decision.
  • Project lead: runs the timeline, RFP, demos, scoring and documentation.
  • Business process owners: own requirements and scenario scoring.
  • IT architect: owns integration and technical fit.
  • Security and privacy: own the security review and data protection questions.
  • Procurement, legal and finance: own commercial terms, contract review and total cost of ownership.

How to run demos that tell you something

A vendor-led demo shows the product at its best. A scripted demo shows how it handles your work. Send each vendor your top five to eight scenarios a week or two ahead, with sample data if you can. Ask them to show each scenario live, in order, and to say clearly when something needs custom work or a partner.

Keep the same audience, timing and scoring sheet for every vendor, and score right after each session while it is fresh. Leave the last part of each demo for your questions, especially about administration, reporting and what happens at renewal. Then run a hands-on trial for the finalists, because watching a demo is not the same as doing the work yourself.

How to present the recommendation

The approvers want a clear recommendation, the reasons behind it and the risks. Use one summary slide with the finalists as columns and the scoring categories as rows, the weighted totals at the bottom, and the recommendation highlighted. Add a second slide with the total cost of ownership and the main risks with their mitigations.

Show the process, too, briefly: the requirements, the long list and shortlist, the scripts and the trial. That proves the decision was fair and protects it from late objections. End with the decision you need and the implementation start date, and keep the full scoring sheets and reference notes in the appendix.

How to adapt it to the size of the purchase

For a small tool used by one team, compress the process into four to six weeks. Keep the problem statement, a short requirements list, two or three vendors, a trial and a quick security check. Skip the formal RFP and use a simple scoring sheet.

For a large platform such as an ERP or a core banking system, expect a longer process with more stakeholders, formal procurement rules and often an outside advisor. Add a proof of concept with real data, deeper financial checks on the vendor and a review of the implementation partner. In the public sector or regulated industries, follow your procurement rules and confirm the required steps with your procurement and compliance teams before you set dates.

Common mistakes to avoid

  • Starting with vendor demos before writing requirements lets the best salesperson set your criteria, so write and approve requirements before you contact vendors.
  • Writing hundreds of must-haves makes every vendor look the same, so keep must-haves short and focus scoring on your top scenarios.
  • Letting vendors run their own demos hides the gaps, so send scripted scenarios ahead of time and score every vendor on the same sheet.
  • Leaving security and IT out until the end can kill the chosen vendor at the last minute, so include them from the requirements phase.
  • Comparing only license prices misses most of the real cost, so build a total cost of ownership view with implementation, training and internal time.
  • Signing without data exit and renewal terms leaves you exposed later, so negotiate data export, renewal caps and service levels before you sign.

Frequently asked questions

What are the steps in a software selection process?

The usual steps are a business case and team, requirements, market scan and shortlist, RFP and scripted demos, due diligence, and decision and contract. Each step ends with a milestone that someone signs off. Many teams add a hands-on trial for the finalists.

How long does software selection take?

A mid-sized purchase often takes around two to four months. Small tools for one team can be chosen in a few weeks, while large platforms like ERP systems often take longer because of more stakeholders and procurement rules. Set the timeline in the charter and track it like a project.

Who should be involved in selecting software?

Include an executive sponsor, a project lead, business process owners, an IT architect, security and privacy, and procurement, legal and finance. Bring end users into the trial to test usability. Keep the core scoring team small and the same for every vendor.

How do you score software vendors?

Agree on weighted categories before the first demo, such as fit to key scenarios, usability, integration, security, vendor strength and total cost. Treat must-haves as pass or fail. Score each vendor independently on the same scale, then discuss gaps as a team.

What is the difference between an RFI and an RFP?

A request for information gathers general details from many vendors to help build a shortlist. A request for proposal asks shortlisted vendors for a detailed response to your requirements, scenarios and pricing format. Smaller selections often skip the RFI and send a short RFP to the shortlist.

Generate this roadmap with AI