The world's best IT vendor!
Throughout the years, I've met many prospects, and in many instances, customers complained about their current or past IT vendors. At the same time, friends have sought my advice on finding the right vendor or staff to build an IT solution since so many options were available.
The question is: "Do you want the best IT vendor in the world, or the best IT vendor that suits your needs?"
There are numerous IT vendors available on the internet, through various channels such as referrals, G2, and UpWork, among others. One vendor may quote you $500k to build an IT solution, while another may quote $5k. I acknowledge that there are many bad consultants or consultancy firms out there that treat you like an ATM machine. I hope that my article can assist you in making scientific or rational judgments. Feel free to leave comments if you agree or disagree.
I've been in the IT industry for over 15 years. I started my career as a consultant in one of the largest IT firms and worked on the client side for 5-6 years. In the last 5 years, I've been working at ASCENDING, which provides IT cloud consulting services.
Is it worth reading?
I've served and worked in both enterprises and SMBs, and that's why I can relate to both sides. Qualifying an IT vendor for enterprises and SMBs is a different ball game. I'd rather focus/help on SMBs since enterprises have more resources and a unique procurement process.
If you're from a startup or SMB or an IT director with your hiring process in the enterprises, keep reading :) I hope my lesson and experience can assist you.
Trial (POC) before you buy
This is probably the most crucial advice for you. Purchasing any service is a very subjective decision. You could be influenced by online marketing, sales outreach, and referrals. Here's my advice to you or even ASCENDING's prospect or client: "Why don't you sign a two-week trial or proof of concept (POC) contract before signing a large contract?"
As a decision-maker, you need to be able to scope out the POC and identify the successful outcome. I know it's more work for you, but don't be lazy. That could eventually save you lots of time and money down the road.
Even if we identify the POC, we still have to choose THE vendor to work on the POC. I'm trying to help you make a rational decision rather than going with your own instincts or the lowest price. I believe there are four main factors. I would prioritize them, but you're free to adjust the weight depending on your situation.
Let's revisit the classic question of how to compare a quote of $500k versus $5k for the same project. Offering ridiculously low prices is not uncommon in our industry. We have seen many software vendors offer free services for the first six months or one year to enterprise customers to lock them in for the next five years. However, free can sometimes be the most expensive solution.
So how do we compare a $5k quote to a $500k quote? I often provide a simple but effective perspective to my clients and let them do the math. Let's take an example:
Suppose a customer plans to hire a US East Coast software company to build a data solution, which would take about 200 hours to complete. If your vendor did not provide a time estimate, you should ask for one.
It's fairly easy to find the prevailing wage for a mid-level data engineer on the East Coast online, such as on Glassdoor. Then, simply multiply that by the hours, and suddenly you have a ballpark estimate of the cost. We also need to account for the fact that the solution provider needs a margin, and short-term contractors are always more expensive than long-term contractors. Now the example formula would be:
$80/hr* 200hrs * 1.35=$21600
The same customer can compare a quote from an India offshore vendor who quotes 400 hours to complete the same data solution. We will discuss onsite and offshore resource pros and cons in another blog, but you get an idea of how to assess the cost of the project.
If you receive a quote of $5000, you know it's too good to be true. Our instinct tries to convince us to go for the lowest offer, but you would never renovate your kitchen with a person quoting you $150 while all the other shops are quoting you around $15000. The same rule applies to software engineering. As a matter of fact, I use that rule to hire plumbers or handymen for my house.
Finding a vendor or contractor who is a good fit for your needs can be challenging if you don't know technology. There are other ways around it, such as researching extensively on the topic or asking ChatGPT, etc. The best way is always to have one or two technical people on your team or ask a friend to vet for you. You never want to hire an IT shop that can do everything; the reality is they can't do anything. You also don't want to hire a digital agency to build a data solution for you, which might look nice initially but will not end well. Just like you wouldn't hire a plumber to replace your roof, and vice versa.
It is the most critical and challenging part of choosing the right vendor. I will dedicate a blog to explaining it from both sides. Even if you have no idea how to vet the vendor technically, you should at least ask for past work, case studies, technical blogs/vlogs.
When you order furniture online, you not only care about the quality and price but also the delivery service. You want to make sure there is no scratch or major defect on your furniture by the time it arrives at your home. However, I don't see many buyers caring about the delivery process during the vetting process.
Transparency is essential. If your vendor only contacts you on the launch day, your project is likely to be unsuccessful. There are a few basic traits you should look out for as a buyer:
Status/Progress Updates: Status updates keep you informed about where the project is at. It allows you not only to understand the schedule but also to ensure the engineer is doing what you ask for.
Resolution for Major Technical Challenges: Even though you are not a coding expert, you should still understand why the vendor chose to solve critical technical challenges in a particular way. By understanding the pros and cons, you could potentially help to solve future problems.
Deliverables: Assume you have launched the solution successfully, and everyone on the team is excited. Don't underestimate the importance of deliverables. I have seen so many SMB stakeholders come to us without source code, architecture diagrams, operation playbooks, etc. When they are looking for somebody to fix production bugs or enhance the system, it would be extremely difficult for somebody to take on. Thus it would cost more money. Without defining the deliverables, your product/service is a passing fad.
I would rather consider customer care as project care. It's hard to know if the engineers care about what they do from a short conversation. There is a big difference between getting things done and getting them done right from the engineers' perspective. When you hire a plumber to build a water pipe system, you would consider the system working for the next 50 years, not just 5 years. That's why I highly recommend going for a POC, talking to the team daily, and understanding how they solve each problem on a daily basis.
I hope the breakdown allows you to make more rational decisions when hiring engineers. Provide a spreadsheet for your team to score each factor. It shouldn't be a decision coming out of a joyful conversation or a slick presentation. I hope you find the right team for your project.
Solution Architect @ASCENDING