Communicating Your Requirements to Technology Partners
All organizations rely on technology as an enabler for mission fulfilment, and most organizations do not have the core competency to develop that technology themselves. Therefore, organizations must rely on partnerships with technology vendors. Even technology companies have technology partners! So, how do you find the right match for you? One very effective way to ensure you are choosing the right partner is to take care in how you communicate your requirements.
Sometimes you realize you need a particular technology and you begin a search for it. Other times, a potential technology partner contacts you about their offering when you haven’t yet realized you may have a need for it, or it isn’t a priority for you yet. Either way, it’s helpful to be able to communicate clearly so that you quickly determine if it is worth your time to pursue further conversation with the vendor.
Partner up
A good partner match is one in which your requirements are met or exceeded by the technology partner’s capabilities. You have a much greater advantage in understanding the former than the latter. Especially with a comprehensive enterprise system, it’s really difficult to fully grasp its capabilities until you are using it for awhile. In most cases, you have to buy it before you can use it for awhile. What if you buy it and then discover it doesn’t meet your needs? This is a legitimate concern, particularly when investing in an enterprise system that has the potential to transform the way you operate. However, this concern should not prevent you from making that investment. Rather, the concern should fuel your motivation to do proper due diligence.
The first thing you need to know about a potential vendor is whether or not you will be able to customize their software to meet your requirements. If not, you need to determine whether you are willing and able to fit your organization into the existing software. Sometimes, this will be sufficient for your needs. Typically this is the case with stand-alone systems that have narrow functionality to serve a specific purpose. With enterprise software, however, you want it to be customizable - at least to some extent - because many of your organizational processes and/or your data will be managed in the system. You will need the flexibility to make changes that enable you to adjust to strategic shifts, changing regulations, new ways to provide service, an unexpected global pandemic, etc.
The remainder of this article will assume you are in discussion with a technology partner who offers customization of their software to meet your needs.
Take inventory
First, take inventory of all the technologies you currently use. I recommend doing this even if you are not actively searching for new software. Vendors will likely want to know what system you are using for this and what system you are using for that. At Continual Care Solutions, this information is important in our screening process because as a provider of enterprise software, we can replace, complement, or augment many of your existing systems. When you share the systems you are using, it helps us to formulate a specific recommendation for you to consider.
As you take inventory, be sure to broaden your definition of “system”. If you aren’t logging in to a software application to execute a process, you’re probably tracking your process on a spreadsheet or in paper files. For example, in talking with prospective customers, we learned that many were tracking their compliance processes via spreadsheets. This was the case for me in my former Compliance Officer role. At the time, I hadn’t even considered that spreadsheets were a system that could be replaced by an application, because I didn’t know such an application existed. And at the time, it didn’t exist at Continual Care Solutions either. However, identifying this as a common need in human services organizations, we decided to build that functionality into our imPowr software.
State what you need
Avoid the temptation to edit your processes as you are communicating them. It’s best to describe them as they are, without attempting to reinvent or improve on the fly. Once you’ve described how it works now, explain what it needs to do.
What it needs to do = your requirements.
Examples:
We need to generate a report monthly that lists all clients served by age, race, ethnicity, gender, and income level.
We need a process that notifies the compliance officer every time a new complaint is submitted.
We have to restrict client data access to authorized staff only.
We want to have a way for our board members to access information themselves, rather than us having to email them documentation before every meeting.
Ideally, you supply all of your must-have requirements to the vendor in preparation for their software demonstration. Then, they can show you exactly how the software meets the requirements within its existing functionality or can meet the requirements with customization.
In addition to your requirements, share your pain points. What frustrates you about your current processes? What do you wish you could do now with your existing technology that you can’t? Are you spending hours chasing people down for data to prepare reports that take more hours to develop and analyze? What strategic opportunities are you missing out on because you are immersed in day-to-day busy work?
You might be thinking right now, “Why should we do all this work when they are the ones trying to sell us something?” First, and most practically, you don’t want to waste time – yours or theirs. You want to ensure this technology partner and their software are the right match for you. If you provide the information in advance, the demonstration can be conducted more efficiently and effectively. At the very least, be prepared to relay your requirements and pain points during the demo. Most vendors will still be able to navigate your requests on the fly. As the person conducting the demo, I’m ok either way but prefer having the requirements in advance so I can plan the most logical path that will be easiest for the audience to follow, include relevant, nice-to-have features that complement the must-haves, and show how pain points can be addressed.
Collaborate and iterate
Now, let’s skip ahead, assuming you’ve chosen to contract with the technology partner, and let’s return to the list of example requirements above. Notice that none of the above statements are dictating how it needs to be done. This is an important distinction. You supply the what, the vendor suggests the how based on the what, leveraging the software’s capabilities in the most optimal way. Then, during the design review, you collaboratively discuss the proposed solution and tweak as needed until you are satisfied with the end result. Behind the scenes at Continual Care Solutions, we also follow this process when the Project Manager translates customer requirements to the Software Developer. The Project Managers describe the what, and the Software Developers return with a design that shows the proposed how.
Our requirements analysis approach depends on whether the process is regulated or not. For regulated processes such as incident management, we base workflows on the exact requirements of regulators who govern that process, as communicated to us by the agencies who were required to follow it. In this scenario, it is helpful to have the source documentation from the regulator that explains the requirements. When we scrutinize specific workflows, we can refer back to the source to confirm we are designing a compliant process.
For unregulated processes, we have more freedom to work with our customers to design an ideal workflow. On our end, we translate requirements into functionality in imPowr. Your responsibility is to explain exactly how the process is followed (or not followed, as the case may be) along with any points of frustration and/or previously identified opportunities for improvement. Then, we collaboratively challenge the existing process to look for ways to streamline further, leveraging best practices from our customer base and previous experience of our leadership team and staff.
In addition to describing the what, provide any forms and other supporting documentation that are used to document or execute your process. When I am in the Project Manager role, I find it very useful to see for myself what is required. For example, you are likely submitting reports to vendors or regulators who require the information in a certain format. It’s way easier for both of us if you supply me with an example of a completed report, rather than try to explain to me verbally what is required. Doing the latter has risk in that it is easy to forget a detail that may seem inconsequential but may actually be quite significant when it comes to customizing the software.
Be open
In general, more is more when it comes to communicating your requirements to technology partners. The more information you share, the more confident you can be that you made the right decision to engage in the partnership, and the more effective and rewarding the partnership will be.
Would you like to explore a potential partnership with Continual Care Solutions? Request a demo here.