How to evaluate IT consultants in Uganda — 7 questions that separate good from bad

Most Ugandan businesses hire an IT consultant the same way they would hire any other supplier: they ask a few people for recommendations, receive a proposal or two, compare the prices, and choose the cheapest option that appears credible. This approach produces consultant relationships that average 18 months before the client starts looking again — usually after a failed implementation, a system that was never adopted, or a set of recommendations that turned out to be vendor talking points. The alternative is not complicated. Seven questions, asked directly and listened to honestly, will identify whether an IT consultant has genuine competence in the specific problem you need solved.

Why the cheapest proposal is almost always the wrong choice

In most procurement categories, a lower price for equivalent goods is a straightforward win. Software and ICT consulting are different, because the output is not a commodity — it is a complex, bespoke service whose quality is nearly impossible to assess before delivery. This creates a market where underqualified providers can appear credible until the project is underway and the problems surface.

The consultants who submit the lowest proposals in Uganda typically fall into one of four patterns: they have underestimated the scope and will return for additional fees once they are locked in; they intend to deliver a minimal version of what was promised and dispute anything beyond that; they are relying on junior staff or uncontracted freelancers who have no accountability to the client; or they have a vendor arrangement that means their recommendation is already decided before they have heard a word about your business.

None of these patterns produce good outcomes for the client. A failed technology project in Uganda does not just cost the contract price — it costs the staff time spent on a non-functional system, the reputational damage of missed deadlines, the cost of procuring a replacement, and often several months of operational disruption. The price of getting this wrong consistently exceeds the money saved by choosing the cheapest option.

The 7 questions to ask every IT consultant in Uganda

These questions are designed to be asked directly in a first meeting or a formal proposal process. They are not trick questions — a competent consultant will welcome them. A consultant who deflects, hedges, or becomes evasive when asked these questions has told you something important.

Question 1: Have you worked inside the type of organisation I am running?

Industry-specific experience matters more than general technical competence. A consultant who has implemented ERP systems for manufacturing companies in Kampala understands the workflow patterns, the reporting requirements, the regulatory context, and the human dynamics that make or break an implementation in that environment. A consultant without that experience will learn on your project — at your expense. A good answer names specific organisations, describes the challenges encountered, and explains what was learned. A red flag is a vague reference to "similar work" without specifics, or a pivot to technical credentials rather than business outcomes.

Question 2: What is your relationship with the vendors you recommend?

Many IT consultants in Uganda receive referral fees, commissions, or reseller margins from the software and hardware vendors they recommend. This is not automatically disqualifying — but it must be disclosed. A consultant who recommends a particular ERP platform while receiving 20% of the licence fee from that vendor has a conflict of interest that should be declared and factored into your evaluation. A good answer is direct and complete: "We are a certified reseller for X and receive Y% referral commission. We also recommend competitors where they are a better fit, which you can verify by speaking with these clients." A red flag is any evasion, denial, or pivot to the quality of the recommended product rather than a straight answer about the financial relationship.

Question 3: Can you show me the last two systems you implemented — and speak to the clients using them?

Portfolio claims are easy to make and hard to verify without direct contact. Asking specifically for the last two implementations — not the best two — reduces the ability to cherry-pick. And asking to speak with the clients, not just see screenshots, tests whether the relationship is real and whether the outcomes were positive enough that the client is willing to recommend the consultant. A good answer produces names, contact details, and a willingness to facilitate the introduction. A red flag is any reason why speaking directly with past clients is difficult, inappropriate, or impossible.

Question 4: What happens when the project hits a problem?

Every non-trivial technology project encounters problems. The question is not whether problems will arise but how the consultant handles them. Ask for a specific example of a project that ran into difficulty and walk through exactly what happened: when was the problem identified, how was the client informed, what options were presented, and what was the outcome? A good answer describes a situation with genuine difficulty, honest communication to the client, a structured response, and a resolved outcome. A red flag is the claim that projects do not hit problems, or an answer that attributes all past difficulties to client behaviour without acknowledging any consultant responsibility.

Question 5: Who will actually be doing the work?

The consultant you meet in the sales process is not always the consultant who will be assigned to your project. Some firms win contracts with their most senior people and deliver with their most junior. Ask directly: which members of your team will be assigned to this project, what are their roles, and can I meet them before signing? Also ask whether any of the work will be subcontracted — and if so, to whom, and what is the quality assurance process. A good answer is transparent about the team structure, provides names and experience levels, and offers an introduction. A red flag is vagueness about team composition, resistance to pre-signing introductions, or undisclosed subcontracting arrangements.

Question 6: What does success look like, and how will we measure it?

This question separates consultants who are oriented toward outcomes from those who are oriented toward deliverables. Delivering a functional system is a deliverable. Achieving a 30% reduction in procurement processing time is an outcome. The best consultants in Uganda frame their work in terms of the business problem being solved, not just the technical artefact being produced. Ask the consultant to define, in measurable terms, what success looks like for your specific project — and how you will both know if you have achieved it. A good answer is specific and business-oriented, tied to your actual operations. A red flag is a definition of success that is entirely within the consultant's control (system delivered on time, features implemented) with no reference to whether the system actually solves your problem.

Question 7: What are the total costs — including implementation, training, licensing, and ongoing maintenance?

The quoted project fee is rarely the total cost. Ask the consultant to walk you through every cost category over a three-year period: the initial build or implementation, any software licensing fees (annual or per-user), the cost of staff training, post-launch support and maintenance, and any infrastructure costs (hosting, hardware, connectivity). A good answer produces a structured breakdown that acknowledges each category, even if some cannot be precisely estimated at the proposal stage. A red flag is a total cost figure presented without a breakdown, or a dismissal of ongoing costs as "minimal" without explanation.

Red flags that appear professional

Some of the most damaging consultant relationships in Uganda begin with presentations that appear highly professional. Polished decks, impressive-sounding credentials, and confident delivery can mask the absence of genuine competence or honest intent. These are the red flags that are easiest to miss precisely because they wear professional clothing.

Credentials without track record. Certificates, industry memberships, and vendor accreditations are genuine signals of baseline competence — but they are not evidence of delivery. A consultant with six certifications and no verifiable completed projects in Uganda is less useful to you than one with no certifications and five successful local implementations. Always weight the portfolio over the certificate wall.

Vendor-recommended consultants. When a software vendor recommends a specific consulting firm to implement their product, the recommendation is almost certainly coloured by a commercial relationship between the two parties. This does not make the recommended firm incompetent, but it means the vendor's recommendation should not be your primary selection criterion. Conduct your own evaluation using these seven questions regardless of who recommended the consultant.

Excessive disclaimers in the statement of work. A statement of work that contains more text about what the consultant is not responsible for than about what they are delivering is a signal of defensive contracting rather than confident professional engagement. A consultant who trusts their own work does not need to hedge every clause.

Vague scoping language. Phrases like "we will configure the system to meet your needs," "all standard features will be included," and "we will work iteratively to deliver what you require" are not scope definitions — they are scope deferrals. Any language that substitutes flexibility for specificity is an invitation to a later dispute about what was actually agreed.

Our ICT consulting practice in Uganda is built on the opposite of these patterns: fixed scope, transparent pricing, no vendor commissions, and verifiable references from completed projects. We welcome all seven of these questions and can answer each one with specifics. If you are evaluating consultants for an upcoming project, start with a conversation — no commitment required.