So you're thinking about adding a new primary software for your team or organization. Perhaps there's a pain point that you believe technology can solve. Perhaps your current software isn't meeting your needs and your team is pressuring you for an upgrade. Maybe colleagues at similar organizations are telling you about a shiny new software they've just implemented because that's what all the cool kid are doing.
Whatever the case, there is a plethora of considerations to take into account before pulling the trigger on a new solution. Managers may be balancing pressure from team members to add or upgrade software with mandates from the top to reduce costs or ensure profitability.
While we at TechSpeak help you address many concerns during the research process, the following are five essential questions to consider as you weigh possible software options. These questions are most relevant to large software implementations, but can be helpful for any solution you are thinking of pursuing.
#1 - What are the strategic goals of your organization?
First articulating the goals and vision of your organization provides needed context to any decision, and new software is no different. Does the decision to make this change align the vision with and enhance your team's ability to contribute to those goals? Considering potential changes to current systems in the context of this question can give immediate perspective to a potential purchase and to the following questions.
#2 - What are the problems to be solved?
Or, as the late Clayton Christensen frames it, what job do you need this product or service to perform for you and your team? This may seem like an obvious question, but too often companies consider and even implement software solutions that don't address core pain points or that—even worse—create others that are just as costly. It may even be that new software is not in fact the solution (see Question 3).
Pain points arise on all sides—data collection, data management, user experience, costs, efficiency, time management, red tape, procedures, etc.—and for this reason, it's imperative that you understand from where the problems really stem in order to know which (if any) software is optimal. Otherwise you'll be mismatching solutions with perceived problems and creating unnecessary additional costs. Beware the enticing pull of shiny software for the sake of shiny software.
#3 - What are the other possible solutions?
Are there suitable substitutes for the proposed solution that are less costly, just as effective, or both? While price should not be the primary decision-making factor, it is a factor, and you want to know that the value you receive from any solution will generate benefits—financial and otherwise. If possible, generate a cost-benefit analysis similar to what you might do for capital expenditures elsewhere. Quantifying results will enable you to understand the real benefits from a proposed solution. Will it save time or reduce costs? If so, where and how much? Will revenue increase as a result? If so, how much? Will employee well-being be impacted in a positive way? If so, can you measure the results?
Once you've measured those costs and benefits, you can compare them to the costs and benefits of other solutions. Can existing systems (software, policies, procedures, etc.) be adjusted or better utilized to solve the core problem(s)? Would additional training or personnel adjustments be just as beneficial? Are there other products that haven't been considered—perhaps less comprehensive products that solve the core problem but don't have all the extra (and costly) add-ons?
Note: this question is best answered when you know the answers to Questions 1 and 2.
#4 - How will this software interact with or affect existing systems?
This question is generally much less relevant for smaller software decisions—a simple time management program that a few of your team members download is unlikely to have repercussions across systems. However, introducing a new CRM will potentially necessitate proper integration across existing systems, such as automated billing, SIS, etc.
Because of this ripple effect, be sure to consult with those who have stewardship over or administrative responsibility for these other systems. Be very clear about what you expect this system to do and how you need it to interact with existing software. Then ask for feedback, questions, and concerns. As subject matter experts over their area and systems, they will likely ask questions that you have not yet considered.
For that reason, feel free to ask this question at any point in the process, and be very intentional about who you talk to. This will differ across organizations. While not everyone will offer the most valuable information to help you make this buying decision, getting context from multiple sources can be extremely helpful as you consider the positive and negative repercussions of an implementation.
#5 - What resources will you need to implement?
Part of the cost-benefit analysis includes initial outflow of cash and other resources. Are you fully aware of what that outlay looks like? Large software implementation in particular can be costly, especially if you're paying a third party to help implement, so understanding that amount will enable you better judge the value of the solution.
Keep in mind that the financial costs are just a piece of the larger set of resources needed for successful implementation. Do you have the right technical expertise and manpower on the team to set it up yourself, or will you need to outsource those needs? Likewise, what are your time constraints, and where do they come from? For example, do you want to be up and running for the next quarter or sales cycle? Perhaps your current solution's contract is coming up for renewal and you're rethinking the decision to renew. Whatever the case, fully understanding your financial and timeline needs will help frame your approach.
Bonus Question - Who is in favor of and who is against the change, and why?
Successfully navigating the logistics and finances of an implementation is vital, but at the end of the day your software will be used by people. Pain points for some may not be pain points for others. There may be deeply entrenched loyalties to existing processes or systems within your team, even as other team members anxiously push for change.
Effective change management and user training will help mitigate such challenges, but will only be as successful as you are aware of their need. Are users simply unfamiliar with the new system and therefore resistant? (My experience has been that, if the new software appropriately addresses the old pain points and users understand how, effective training does a great job of alleviating this concern.) Or are there others who understand well enough, but just prefer the system that has been working for them for years and don't see adequate reason to fix what ain't broke?
Whatever the case, if you understand the dynamics of your team and how they will respond to the transition, you'll be that much more prepared for a successful implementation.
Contact us for individualized guidance through this process.
Коментарі