Businesses buy new software all the time: someone will come across a new software tool that they think will improve operations, recapture productivity, or boost revenue.

While cultivating this forward thinking mindset in employees is important for all companies, often there is not much thought given to how to purchase this software.

Does it make sense to buy the first interesting tool that someone comes across? Most likely, not at all. To ensure that organizations have a cohesive approach to purchasing and introducing new tools, companies should standardize their software procurement process.

Reconciling the needs from throughout the enterprise in a structured software procurement process is key.

A standard procurement process ensures alignment between the business, business units, and individual staff. Reconciling the needs from throughout the enterprise in a structured software procurement process is key.

While most small businesses will not have dedicated project management resources compared to larger companies who do, there are three major considerations that every business can review before purchasing new software.

What need is this software solving?

Understanding business needs is the most important part of the software procurement cycle. Seems obvious, right? In fact, this is the part of the software procurement process that is most missed.

Organizations answer this question through a needs analysis. To access a company’s needs, look at existing and projected future pain points and identify opportunities for improvement.

This process can be as informal as bringing mid-level managers together and writing ideas on a whiteboard, or as formal as hiring an external consulting firm.

There is no one-size-fits-all approach for a needs analysis. A common place to start is with mid-level managers

How formal should the needs assessment be? It entirely depends on each company. There is no one-size-fits-all approach for a needs analysis. A common place to start is with mid-level managers, as they are normally in the best position to understand the pain points of the organization.

From an operational perspective, managers are in regular communication with front-line employees and company executives. They are informed on what is actually happening in each department and the organization’s priorities.

Regardless of the people involved in the software needs analysis, common questions to ask include:

• What are the problems we are experiencing?
• How are we currently solving the problems today?
• How would a better way of solving this problem help the organization?
• What would this alternative solution do?

After answering these questions, put together a list of software requirements. The purpose of these requirements is to review all the possible software solutions without bias or preference for one over another. The goal is to acquire the best solution which meets the most business requirements, not automatically select the first solution that came to a company’s attention.

Who’s job(s) will change because of the software?

There is such a thing as too niche of a problem. If the pain point affects too few people or an ancillary part of operations, then perhaps the problem is not best solved with software.

With niche issues, additional training or simple process improvements are often enough to alleviate most, if not all, of the friction causing the problem. How niche is too niche?

Use the 5% rule - if the problem affects over 5% of personnel or operations, then the problem is significant enough to consider software as a solution.

This question serves a dual purpose: identifying the people that should be involved in the decision process and the staff that will eventually be using the new system.

After determining whether the problem is too niche, the next step is to determine what processes or jobs will change because of the new process.

This question serves a dual purpose: identifying the people that should be involved in the decision process and the staff that will eventually be using the new system. These staff are known as stakeholders as they have a stake in the outcome of the software procurement process.

It is important to narrow the list of stakeholders down to a working team of around five staff. For larger projects that affect more of the company, the number of staff involved can increase.

The downside of too many stakeholders is that it will be difficult to reach consensus in a timely manner - more voices equals more opinions. With the stakeholders assembled, the company can now conduct the needs assessment and build the requirements list to evaluate the software on.

How will the software pay for itself?

To spend the time and resources buying new software, a business justifiably needs to see a return on their investment (ROI). How will the software pay for itself? Software can recoup the initial investment (including procurement and licensing cost) through several different ways.

The first way software recoups its investment is by allowing the business to make more money. Either by offering new services, or offering existing services in a novel way, this return is the easiest to measure and justify.

The second way software shows a return is with a productivity increase. Perhaps before, your salespeople could call 100 people a day? With the new software, they can now call 200! While productivity increases can contribute to increasing a company’s revenue, it does not always. Improving productivity with software allows staff to do what they normally do, but faster or with higher accuracy - both key in an increasingly digital economy.

This is not an exhaustive list of ways that software can provide ROI, but rather a starting point for a business. The most important takeaway is that the software has to provide a return. As each business is unique, this can vary. But how a company measures ROI does not. Set actionable goals and KPIs to ensure that the organization is seeing the return that management expects.

Software is always an investment and needs to be thought of as such. Beyond the obvious licensing costs, businesses should also consider procurement costs by calculating the number of people involved along with the hours they will spend.

Buying software does not have to be an ordeal; on the contrary, it should be a straightforward and relatively painless process that businesses engage in with some regularity. With a little bit of planning and a clear understanding of internal needs, key stakeholders, and ROI, your company’s next software procurement will be a resounding success.