3 Tips to Find the Best Tech Solutions for Your Organization
Strategies for Prioritizing Your Technology Solution Shopping List
“Our technology will solve all of your problems,” said every salesman since the beginning of time.
It’s dangerously easy to believe that new tools and new technologies can solve your team’s unique problems. All the marketing and all the hype begs you to believe that the newest tech can be the next killer fix.
Having been tasked with solving the problem, what’s the first step to resolution? Of course, the temptation exists to press the “That Was Easy” button and buy the shiny new technology, hoping that it’s mere presence alone will banish the aforementioned prickly issues to the shadow realm. Of course, the engineers now tasked with implementing the new technology and bringing the toolset into your existing processes let out a collective groan.
Having been victim to higher management’s “the new tool will fix it” mindset, we can say with some confidence that simply purchasing a promising tool is at best a 50/50 solution. 50% of the time, the tool will help, and the other 50% of the time the new tool languishes in a dusty corner, gathering cobwebs and a vague aura of financial regret.
This blog will help address some strategies for gathering information to prioritize your technology shopping list.
Below are three tips on how to build your shopping list:
- Get the real requirements. Involve the individuals that are directly affected by the issue throughout the problem-solving process.
- State the problem without using brand names or tech.Willfully remove specific technologies, companies, brands, or buzzwords from your problem statement.
- Make a balanced transition plan. Take into consideration the current state and future state without including a specific technology solution.
Let’s explore a little further.
When you’re looking to change the way a group or team does its work and processes, then having feedback from individuals in that group can be invaluable. Those individuals may be able to give you feedback or elaborate specifics on the problem. This can drastically help you scope what capabilities you need from your solution and help rule out technologies.
As you interact with the individuals, they may be tempted to give you specific examples of technologies they believe may solve the problem. Try to revector the conversation to focusing in on what specific actions and capabilities technology is assisting in. This can help you make sure that you are looking at tools to meet your requirements versus making your team’s needs fit what a tool offers.
Let’s look at an example where someone states a specific technology as the solution to a problem: “I need Slack for communication.” This is too vague. What specifically does Slack provide that makes it a winner over its competitors? Management could decide to go ahead and buy Slack because that’s what was proposed as a communication solution. If they had conversations with the team members, they could find out that the communication issue really is a lack of screen sharing and video capability. Slack focuses on chat and would not be the proper communication solution. On the flip side, maybe management decides Microsoft Teams would be a cheaper and better solution. In this case, maybe a conversation would have revealed that the issue is with chatting with external customers. Microsoft Teams does not have an easy chat feature for individuals outside of your organization. Therefore, it can be helpful to use your interactions with the individuals closest to the problem to define the problem and solution required without tying it to a specific technology. A better example of the earlier solution would be: “I need a way to communicate quickly via chat with internal co-workers, customers, and external partners. As a communication hub, it would be nice if it could integrate with our other technology tools.”
Lastly, let’s talk about a balanced transition plan. Some technology solutions could have a significant learning curve. You also need to account for how the technology solution will change your existing processes and how integrating the solution may disrupt current operations. Again, this is where having those conversations with those directly involved with the problem can give insight into the current process, and what the future process would look like. Being able to envision the future state can help determine if you need to have a phased approach for minimal disruption to current output. You’ll also get insight if there is going to be resistance to the changes, or if it’ll be embraced. This is important! If a technology solution is purchased but those who are being asked to use it reject it, then you spent money on something to sit unused. Some things need phased in for acceptance and time to prove that the solution provided increases productivity.
All three of these tips can be done in varying degrees. You can provide full-blown surveys with working groups, or you can chat around the water cooler when gathering information for your technology solution shopping list.
If you’re looking for a way to back up your willfully technology-agnostic fact-finding process, you can whip out the ancient tome of the Agile Manifesto. Our advice here, at its core, all feeds back to the Agile Manifesto’s core value, “individuals and interactions over processes and tools.”
Exacting methodology or agile orthodoxy isn’t required here. In short, as long as you talk to the individuals whose problem you’re trying to solve and keep them in the loop when discussing the solution, you’ll be better armed to find technology solutions that support your teams, not hinder them.
About the Authors
Callan Andreacchi is the Deputy Director of Agile Technology at BigBear.ai. She started as a Cybersecurity Consultant and transitioned to Cybersecurity Systems Engineering. During her time building Defensive Cyber Systems she discovered that the traditional way of building was too slow to keep up with adversaries. She’s embraced agile and DevSecOps methodologies to lead engineering and development teams to keep up with the bad guys.
Ian Ellett is a DevOps Engineering Lead for the Agile Technologies team at BigBear.ai. He followed an odd path to his current position. He started out as a Technical Writer, accepted a position as a software tester, and has been sneaking into increasingly technical roles ever since. He is a certified DevSecOps pipeline enthusiast and a continual advocate for automating everything that can possibly be automated.
