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:
  • Not being able to support a key business process
  • Supporting a process inefficiently 
  • Complications in daily operations
  • Unhappy employees
  • Unsatisfied customers
  • Poor performance
  • Loss of sales
 
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:
  • Finding internal experts
  • Identifying answers to frequently asked questions
  • Identifying approved procedures and policies
  • Reducing technical client support resolution time
  • Share knowledge across the research team
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:
  • Interviewing end-users to find out what their needs are. This can be done by using questionnaires, face-to-face interviews or focus-group discussions.
  • Analysing the legacy systems already in place and determining how they are used, and where they break down to deliver results
  • Identify strategic use cases for mission critical operations, and where they fail
 
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. 

Comments

Leave a comment

1 + 0 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.

© 2024 Copyright TallyFox Social Technologies AG, Zurich, Switzerland | TallyFox complies to Swiss law and the Swiss Data Protection Act