Shopping for software? Read this article first

Selecting the software which meets the requirements of your organisation and its business objectives could become a challenging task considering the number of available solutions. A hasty, uneducated choice could lead to various problems in your organisation. Some of which may be:

 

Selecting the right software is, therefore, critical and it requires careful evaluation and selection guidelines. 

 

Many organisations go about it the same way. 

 

They assemble a project team consisting of managers or employees from the IT department, they brief them of the functional needs and give them a free hand to evaluate options available on the market and choose the one that meets the technical requirements. Or the process is reversed and the need comes from employees.

 

Is this the right way?

 

As mentioned in Capterra’s Software Buying Guide, certain procedures should be finalised before the actual evaluation is carried out. The guide suggests that the organisation should begin with interviewing some staff members, addressing corporate vision, assessing existing systems’ limitations and features and looking at present policies and procedures. 

 

 

Jacob Morgan from the Future of Work supported this way of thinking by saying in his interview for our blog “Gathering feedback from the employees and from IT, should be a joined, unified effort. The managers should gather feedback on what their employees would like to use and why they would like to use it, instead of telling the employees what they should be using.”

 

In his interview for our blog, Dave Snowden, a well-known name in the field of knowledge management, added: “Technology is developing so fast now, users don’t know how to ask for it. If you ask direct questions you’ll get the wrong answers. Generally, people don’t know what they need until they discover that there’s a better way of doing things and then they want something different”.

 

What’s the solution? 

 

 

Creating a comprehensive and prioritised list of the problems that you are trying to solve, the present workflow, and where the process breaks down will help to prioritise issues in implementing key use cases. Only then can you focus on the types of applications that can address these use cases and where the break down today. 

 

For example use cases may include:

When looking at these use cases and where the breakdowns occur will start the process to identify the functionalities of an IT support solution that can help solve process breakdowns to reach the objectives faster, with more accuracy and in a repeatable, yet agile manner. 

 

To illustrate the different approaches, one result from a functional perspective might be “we need a Wiki”. The action from this approach would be to find the “best” Wiki that offers specific features. An alternative approach might be we need a smart content management solution to scale across global teams so that they can find things relevant to their specific work are or client need. Wiki’s are good at structuring indexes of information within a specific structure, but not well suited to scale into content management solutions that are needed for company-wide knowledge sharing, for example.

 

It is clear to see why, then although the “best” wiki may have been selected for this use case why the project was not successful. 

 

There are mixed opinions on how the key use cases should be identified, there are, however, a few key strategies that have good success rates:

 

All of this is the first step to take the most important one, understanding the use case. Once you gather all necessary data and formulate your requirements, you might want to read our article “Working With a Software Vendor - What Should you Expect?”. Don’t settle for less than that.