“Hello… Hi!, Hello? Is everyone on the call from our side? Did anyone send Jerry the invite? What about forwarding the provided API documentation and architecture slides? No? Oh, that was in my inbox… Okay… Let me shoot out a quick email to see if that team is available, right now…”
Sound familiar?
—
When it comes to software vendor review and validation, the process is very much a mirror of any vendor’s own sales funnel processes. You have various introductions that start, hopefully, with the project’s main contact, which the vendor’s account executive is banking on also being the person who approves the budget and signs the checks. The one-sheet is shared and the website reviewed. One hour demos are scheduled and fulfilled. Sometimes twice. Perhaps contract negotiations have even slid into the conversation, to which the account executive is really floored to ink this soon, and catapult you off to an implementation team for putting together all the details, post-sale. However, there’s a bridge that one must pass, and that bridge is Jerry.
For the purpose of this example, Jerry is going to exist in our blog world as a human of all hats when it comes to software and tech. Jerry is woman. Jerry is man. Jerry may be IT management, approving all things technical, and supports your internal infrastructure, including all of those laptops (IT Manager). Jerry is project-focused, and perhaps manages a developer team that your company is fortunate enough to have on the ready (IT Project Manager). Instead, Jerry may just code all of your business services as a single-human team, and fully understands the requirements of “the stack” (Developer). Jerry might also be a functional expert as well, who’s knowledge-set specializes in what you are shopping for in your next software platform (Expert): Learning Management Systems? GIS mapping? Mobile Device Management? Business Intelligence and Analytics? Identity Management System and Active Directory? CRM? HRIS? Billing? Autocad? Pro Tools? All of this to say, Jerry, or Jerry’s team, will be on a call at some point, and will become either a gateway (good) or bottleneck (bad, very bad) because their expertise is required for the proposed system(s) being considered, and in some cases, though becoming less and less in the SaaS (Software as a Service) world, Jerry will inherit the project and support it until Jerry has had enough and moves on. Then, in search of another Jerry you will be.
1. Keep Your Tech Team(s) Informed Early
“IT” can decide the ultimate fate of any related project. Business-minded colleagues with long term project focus might assume it better to position their tech team(s) as an in-and-out, one-stop meeting, for validating a solution. Worse, as someone to creep behind, unnoticed, until after contract signing and project kick-off.
Jerry will react to this behavior. Taking the offense, purposefully strong-arming your efforts, or, for Jerry’s and your entire company’s well-being, rightly adding days to weeks to a pre-sales evaluation period so that general awareness can be garnered for what is being proposed, a scope can be identified, solutions validated, implementation timelines confirmed, and the very start of any required resource planning. This brings us to…
2. Align Internally on the Proposed Solution with a Decided Pathway Forward
Nothing will throw more of a wrench into expedited discovery, validation, and the budget approval processes than when internal alignment is not met. This part is less directly associated with Jerry and the tech team, but they are still very much one part of the whole. Every department, and not just those involved directly with the project, should have a plan as to where their efforts fit in, and how it affects existing and to-be-implemented platform systems. We’re talking specifically about inter-platform integrations here and knowing which are involved, which are considered “points of record”, and let’s not forget, the direction of data flow in and out of all required systems.
The point of failure here is when you wait until a scheduled vendor/consultation call to then begin including and discussing your plans with your internal teams. The other party sits, muted, with nothing to contribute because they are not in a place to make decisions around internal directions, or much less, your budget processes. Do not use 3rd party meetings as a first time meeting of your own internal teams. Schedule those prior, and you will allow your vendors and consultants to use your time effectively while offering solutions to maximize your mutually-aligned business goals and processes.
3. Understand Your Company’s Purpose and Your Purpose Within Your Company
This one is simple. Whatever your role might be inside of your company, when it comes to implementing new software platforms and solutions, be sure to focus on your team’s requirements and allow other team managers to focus on their own with the goal of aligning with a total solution in the end. Just because a project starts with one team doesn’t mean that it has to come solely from that initial team. Implementing new workflows can have an effect on many internal and/or external processes, even those that are not so obvious, and touching teams that you may have never considered to include.
Specialization exists for a reason inside of most successful companies, and it’s difficult for any one team, let alone one human, to have a complete understanding of every need. Let your other teams know that such a project exists and that new tools might be on the horizon so that others can opt-in to the process if they see a fit.
—
“Good morning, everyone. We are all here and accounted for. Let’s allow time for quick introductions from all head members of our organization’s teams who are focused on leading this project. Then, we will summarize our vision so that you can present us with your best options.”
Yes! Now, we’re moving forward.
