IT advisor and project supervisor: the bridge between the client and the vendor

A client without an in-house IT team faces two things alone: needs they can't name, and vendors who speak a language seemingly designed to confuse them. My job sits between the two — translating both ways and making sure what gets bought is what the business actually needs.

IT advisor and vendor broker

The typical Colombian SMB has no IT department. There's a manager, an administrator, an accountant and operations. When something technical crosses their desk — a vendor offering an US$ 8,000 system, an ISP charging for "premium support", a consultant proposing migration to cloud — the client sits alone, evaluating something they don't understand, against someone whose job is to sell to them.

That's where the role of the independent advisor enters: someone who doesn't sell the same as the vendor, doesn't take commission for the sale, and whose only interest is for the client to end up with what they need at the right price.

The first problem: the client knows they have a problem but can't name it

The phrases I hear in a first meeting typically sound like:

  • "The internet is slow" (when the bottleneck is the internal WiFi, not the ISP).
  • "I need a system" (without having defined which process to systematize or for what).
  • "I want everything in the cloud" (without any idea of monthly cost or legal risk with personal data).
  • "Employees are wasting time" (without real metrics on what).
  • "I was told I need cybersecurity" (without doing a risk analysis).

These are symptoms, not diagnoses. The first job of the advisor is to turn symptom into concrete problem: walk the real process, measure what can be measured, separate what the client thinks they need from what they actually need.

The second problem: needs the client doesn't even know they have

This is more delicate. There's an entire class of problems a client without IT doesn't detect until incident time:

  • Endpoint antivirus. "I have Windows Defender" — but no central monitoring, no patching policy, no EDR. The first encrypted attack reveals the gap.
  • Data backup. "Everything's on an external drive" — but plugged into the very server that would get infected, no integrity checks, no restore tests. We covered this here.
  • OS optimization. Windows machines full of bloatware, unnecessary services, saturated startup. Result: employees losing 15 minutes daily waiting for Outlook.
  • User and permission management. Everyone admin everywhere; shared folders set to "everyone / full control"; ex-employees with active accounts months after leaving. Attack surface and data loss potential is huge.
  • Poorly segmented networks. Security camera, accountant's PC, guest WiFi and billing system all on the same VLAN — one infection compromises all.
  • Manual processes screaming for automation. Word templates edited by hand, data copied from one system to another, monthly reports built from scratch in Excel when a one-hour script could generate them identical every time.

The client lives with these problems because "it's always been done this way". The advisor spots them because they've seen what happens when one of those gaps becomes a real incident at another client.

The third problem: dealing with vendors who speak another language

When a client sits across from an ERP rep, a camera integrator, an enterprise ISP or a "digital transformation" consultant, they often hear things like:

"Multi-tenant SaaS with horizontal scaling and 99.99% SLA includes a Kubernetes-based orchestration layer with SSO via SAML 2.0 and ISO 27001 compliance. The per-seat license is annual with discount on 3-year commitment."

The client nods, signs, and 6 months later discovers they're paying for users who don't use the system, that "SSO" requires another additional product, that "compliance" doesn't apply to their actual flow, and that the contract locks them in 3 years with no exit clause.

The independent advisor does three things in that conversation:

  1. Translates. "Multi-tenant SaaS" = "your data shares servers with other customers". "99.99% SLA" = "they guarantee less than 53 minutes of downtime per year, and beyond that you get credit, not cash". "Per-seat" = "you pay per user assigned, used or not".
  2. Questions. Do you really need SAML SSO, or is MFA enough for 12 users? Is ISO 27001 required by any of your customers or is it marketing? Does the 3-year commitment include updates or are they separate?
  3. Negotiates. Demand the proposal in writing, require an exit clause, separate optional from mandatory, compare with at least one market alternative.

Project supervision: standing between the parties during execution

Advising before signing is one step. Project supervision is the next: being present during contract execution to ensure the vendor delivers what was promised.

This includes:

  • Validating technical deliverables. That the installed network meets the contracted category, that delivered servers have the invoiced specs, that developed software meets signed requirements.
  • Verifying timelines. That schedule milestones are met or contract penalties are enforced.
  • Detecting scope creep. When the vendor starts billing for things that were in original scope, or reduces scope without reducing price.
  • Formal acceptance. Delivery records with verified checklists, not "sign here, it's done".
  • Documentation. That the client ends with manuals, credentials, support contracts and the info needed to not depend 100% on the vendor going forward.

This is what a project supervisor does in civil works, and what should be standard for any technology project above a certain size. In practice, 80% of SMBs don't have it — and that's why they end up paying for projects that don't work or that lock them into a single vendor for life.

Why it has to be someone independent

If the same vendor selling the system also "audits" it, the conflict of interest is obvious. So the advisor / supervisor must be:

  • No sales commission from the vendor. The vendor must not pay me a cent for recommending them.
  • No competing product against what's being evaluated. If the client is considering a CRM and I sell another, I'm not the neutral advisor.
  • Paid by the client and answering only to the client. No opaque alliances.
  • Technical capacity to validate. Questioning isn't enough — must be able to review, measure, test.

The value the client notices at month 3

The client doesn't notice the advisor's value immediately. They notice it:

  • When the invoice matches the quote, not the "adjusted" one.
  • When the vendor delivers what was contracted, not "the equivalent".
  • When a scope change comes with a signed addendum and clear cost, not a closing surprise.
  • When they can request quotes from other vendors without feeling in the dark.
  • When they understand what they signed and why.

And, above all, when that advisor saves them double or triple their cost — in avoided overruns, badly-closed contracts not signed, and failed projects caught in time.

My promise

I don't sell overpriced or unnecessary components. I take no vendor commission. When I recommend something, it's because your actual use justifies it. And when your vendor delivers something, I review it with the rigor of someone who'll also receive the calls if anything fails.

Need an advisor on your next project?

If you have a software, infrastructure or IT services quote and want a technical second opinion before signing, or need someone to supervise a project already in flight, tell me what you're evaluating. First review is free.