IT consulting is an outside review of a company's problem that ends with a decision and a plan: what to change, in what order, by whom and at what cost. A consultant does not install systems or fix servers; the question they answer is which solution the business needs and whether it needs one at all.
Key takeaways
IT consulting is a paid review of someone else's problem that produces a decision: what the company's set of systems should be, what to change in them and in what order. Unlike a contractor, the consultant answers for the quality of the decision rather than for working code.
They are called in when the question is phrased in business terms and the answer has to be technical: sales will not scale, a report takes three days to assemble by hand, two systems hold different stock figures. The answer may turn out to be development, configuration of software already bought, or a change of rules with no code at all.
The word itself causes the confusion: contractors, software vendors and in-house specialists all call themselves consultants. The difference lies in what you are buying.
The scope is assembled around the client's question rather than from a universal list. Five areas turn up most often, and each closes its own question and leaves its own document behind.
| Area | Question it closes | What the company keeps |
|---|---|---|
| Business process review | Where the company loses time and money in daily work | A process map and a list of losses with figures — covered in our article on the business audit |
| IT infrastructure survey | The state of servers, networks, backups, access rights and licences | A list of findings by severity — covered in our article on the IT infrastructure audit |
| Requirements and specification | What exactly the future system must do and how it will be accepted | A technical specification with acceptance criteria — covered in our article on the technical specification for an IT project |
| Architecture and work queue | How the systems connect and what to change in which order | A systems diagram, the sources of truth, the order of stages |
| Budget estimate | What each step costs and what it gives the business | An estimate per stage and the items that need no development |
Diagrams and documents are worth keeping in commonly used notation rather than in home-made drawings: the process map in BPMN 2.0 from the OMG consortium, the architecture roadmap along the lines of the open TOGAF standard from The Open Group. Then the document is readable by someone other than its author, and the next team does not start from scratch.
The project moves from the question to the facts and from the facts to options. The order of steps barely changes; only the depth of each does.
The result has to survive a simple test: you can make a decision and release money on it. A report with no figures and no options is a retelling of conversations. Check the contents against this list.
All four deal with the same systems but sell different things: advice, stability, implementation or day-to-day management. Confusing them is a common reason both sides end up unhappy.
| Criterion | IT consulting | Technical support | Systems integrator | In-house IT director |
|---|---|---|---|---|
| What you buy | A decision and a costed plan | Working systems under contract | Implementation of a specific product | Permanent management of IT from inside |
| When you need it | Before a product is chosen and a budget spent | Once the systems are running | Once the decision is made | Once IT has become a full-time daily job |
| How it is measured | Quality of the decision and accuracy of the estimate | Response time and number of incidents | Launch on time and on budget | Business results over a year |
| Main risk | A report nobody ever applies | Paying for silence with no reporting | A solution shaped by what the integrator sells | An inside view with nothing to compare it against |
Consulting ranges from a single conversation to accompanying a project throughout implementation. The choice depends on how clear the question already is.
Most consultants on the market are teams that go on to do the development. Advice like that always carries an interest: recommend what you know how to build. The problem is not the combination itself but staying quiet about it.
Important Syntra Systems is a development company, and we say so before the review starts. That is why our reports mark separately the items that close with configuration, rules and a shift of responsibility — in other words, without our development and without a budget for it.
Four questions are enough to test a consultant.
Access to data is a separate question. A consultant sees exports containing customers and employees, and the law on personal data (No. ZRU-547 of 02.07.2019) obliges everyone who obtains access to personal data not to disclose it, and requires protective measures from the owner, the operator and any third party alike. So the non-disclosure agreement is signed before the exports are handed over, and anonymised data is usually enough for the review.
A consultant's work ends with a chosen option, a plan and an estimate. What follows is different work: a contract with a supplier, stages, development and acceptance. One team can do both, but then the price of the review is stated as a separate line — otherwise there is no way to tell what the company actually paid for.
If the question sounds like "our email is down" or "we need to replace a server", no review is needed at all: that is work for support or an administrator. The signs that it is time to call a consultant, the typical tasks by industry and the work alongside an in-house IT team are covered in a separate article on who needs IT consulting and when to call.
There is no separate priced "IT consulting" service on our site, and we are not going to invent one. The review of a problem sits inside work you can order at the price shown on the service page.
We start with the question rather than the product: first we work out which loss a change closes, and only then talk about a system. After a review like that, part of the findings close with rules and with settings in software already paid for, and we say so plainly even when it shrinks the amount of work for us.
The documents stay with you: the process map, the list of findings, the technical specification and the budget estimate are handed over in editable form and work for a conversation with any contractor.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
An audit answers the question of what exists and what condition it is in: it describes the infrastructure and finds problems. Consulting answers what to do about it: it weighs options, prices them and puts the work in order. An audit often becomes the first stage of a consulting project, but on its own it produces no decision.
Consulting ends with a plan and a price, and implementation is quoted separately — you don't have to order it from the same contractor. Our closest format is an AI audit at $400, which delivers an automation plan with a sequence of steps and a budget for each. We hand the documents over in editable form, so you can take them to any contractor.
The manager who decides contested questions, one person per process, and the in-house IT specialist if there is one. Without the manager the project turns into a description of the current state: nobody is there to choose an option and name the owners of the changes.
Anonymised exports are usually enough: the structure and the volumes are visible while customers' personal data never leaves the company. Where access to live data is genuinely needed, it is granted personally and at the minimum scope, and the non-disclosure agreement is signed before the handover rather than after.
Start with the part that needs no budget: rules of work, a shift of responsibility, settings in systems already paid for. A good report marks those items separately. The rest stays as a queue with estimates and does not go stale until the company's processes change.
The key condition is having someone inside the company who has seen how things work elsewhere and is willing to ask colleagues uncomfortable questions. Without that, an in-house review suffers from an inside view — familiar workarounds stop being noticed, and there's nothing to compare against.
