Many architects may recall a point early in their careers when they discovered that not everything a 3rd party vendor has promised about their product’s capability did actually prove to be true…
Indeed, we need to protect our client interests and our own as much as 3rd party vendors will want to protect theirs.
If we restrict ourselves to a vendor-dimensional world, there are two glorious moments in which one can join a particular project:
- Right at the very beginning when everything is yet to be done (including vendor selection).
- At any point after that
“My product can also sing and dance”
If you are lucky enough to be involved in the vendor selection process, you have to be ready for the fact that some vendors may promise a bit more than what their product can deliver (i.e. “my product can also sing and dance”). As a result, you have a duty to ask the difficult questions that the Business may not know how to articulate.
A product can almost always be tweaked (in some way or another) to “do the job” functionally speaking. However, when it comes to the technical details, it can become an operational nightmare for clients.
Some key questions in this area will be:
- Do you support my platform? – most of people will ask this question, and the answer is positive most of the times.
- What are the benchmarks of your system on my platform? – if the previous was a half truth, this will be a very blurry answer.
- What percentage of your customers run on these platforms? – and if your platform is not one of the larger segments of the “cheese chart”, ask why, and why, and why… sometimes you may even considering changing your platform…
I’m sure we asked about this
..and… get all of these in writing. Jointly writing things down is important, since not only will your memory fade (“I’m sure we asked about this …”), but so will the vendors. Compatibility issues, performance limitations, lack of support, etc are commonly discovered during implementation and it is crucial that evidence has been captured about what it was agreed the product could or couldn’t do.
“let’s work together on the issues”
If you make it to the second scenario (i.e. after the vendor selection). Vendors will most of the times be very open about the limitations of their platform and their line will now be more like “let’s work together on the issues”. While this is the right attitude and approach to delivering the client’s requirements, you need to be mindful that this is not just an excuse for the 3rd party vendor to sell its professional
services.
Ideally, you would have an experienced team with the right product skills. However, this is not always possible. I have found the following steps very useful to follow:
- Get the vendor to guide you through an early PoC (Proof of concept).
- Get the vendor to design the Production architecture with you, based on their best practice advice and get them to sign it off. Always question this solution (in writing, all in writing!), but remember that if anybody knows about their product it ought to be them.
- Give your client full visibility of design and timelines agreed upon. Make sure everybody understands who is waiting on who and what your issues are.
- Always ask the vendor’s for help when you need it. i.e. don’t try to reinvent the wheel or rely on Google too much if you are paying for expensive professional services.
Good relationships with 3rd party vendors are key to successful deliveries. For this to happen, both parties need to understand each other’s strengths and see each other as valuable allies. These relationships will only become sour when significant problems with the products are unearthed that are the results of
design/implementation decisions not taken consensually with the vendor or when the product capabilities do not fully match the product specifications provided during the vendor selection phase.
Remember: Everything in writing, EVERYTHING. Deleting emails is shooting your own foot.
